7f3b0b021858cfb2fe914f3ba6b30a39e3ae05ff qa: test a PSBT has only the BIP32 derivations for a single spending path (Antoine Poinsot)
b71bd693d6ea4c1c3567194fc82be43fb70c05bb qa: don't use a static dummy origin for descriptor xpubs (Antoine Poinsot)
a81d39c81a89cdf5e70b9888cbeb3abaf290a365 commands: do not include BIP32 derivations for other spending paths (Antoine Poinsot)
Pull request description:
ACKs for top commit:
edouardparis:
ACK 7f3b0b021858cfb2fe914f3ba6b30a39e3ae05ff
Tree-SHA512: f0e132edf8d653c5575f843b1e85d995f155a2435a6e6257564dc945562df70ec2049c29d77f7580858d9e4a58290b0798f298f77c18255415c4cf26ccc07f33
When creating a PSBT, only include the BIP32 derivations in each input
for the spending path this PSBT was created for.
This is to workaround Bitbox only providing a single signature per
input. Most likely other signing devices will have this behaviour too in
the future. See
https://github.com/wizardsardine/liana/pull/706#issuecomment-1744705808.
Multiple change indexes may be present in a spend
draft transaction and can be detected instead
in the response psbt with the bip32_derivation
outputs fields.
This is a new command dedicated to the recovery usecase. For now it's
dead simple: sweep all coins that are available through the recovery
path to a given address.
Since the Spend transaction command requires some parameters, this
implements the parameter-getting logic on the JSONRPC side as well.
This allows us to implement an end-to-end functional test of the
transaction flow using an external way to broadcast it. From the input
coins creation, to the Spend transaction broadcast.
