PsbtEx::update_desc include derivation paths for bip32 keys

[LLFourn]

I've been looking at 7.0.0-rc.2 and was seeing if we could replace all the PSBT population code in BDK with the new shiny stuff here. Some of the fields we need that don't seem to be filled in by PsbtExt::update_desc are bip32_derivation and tap_key_origins. It seems like we should be able to populate these at this point. For example, for bip32_derivation we can iterate through each key in the descriptor and if it's an XPub derive it and insert into the map. We would need to pass in a secp context for this to work. see EDIT

More than willing to do a PR on this but wanted to check this approach makes sense.

As a side comment: It looks to me like the update_desc function should extend Psbt::Input rather than putting it on the Psbt type and then having to pass in the index you want to use (the logic completely ignores the rest of the psbt).

EDIT: ok so it looks we don't need to pass in secp because we are already cheating inside by allocating a new one each time. I have no complaints about that but I think the API could just require you pass in a pre-derived descriptor (i.e. no-wildcards Descriptor<DescriptorPublicKey>). At least for BDK there is no advantage to having an API that can do the searching within a particular range for you to match against a PSBT input since you should usually know what index the scriptPubKey was derived at for any UTXO you have.

[sanket1729]

For example, for bip32_derivation we can iterate through each key in the descriptor and if it's an XPub derive it and insert into the map

Indeed, this makes a lot of sense. I think I may also have a TODO in there mentioning this.

More than willing to do a PR on this but wanted to check this approach makes sense.

This makes sense, and PRs are always welcome.

As a side comment: It looks to me like the update_desc function should extend Psbt::Input rather than putting it on the Psbt type and then having to pass in the index you want to use (the logic completely ignores the rest of the psbt).

Agreed. This can operate on Psbt::Input if other information is not necessary.