You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
psbt: untangle some logic in update_item_with_descriptor_helper
We have the function `update_item_with_descriptor_helper` which does a
few things: it derives a descriptor (replacing all the xpubs with actual
public keys) and updates the appropriate input or output map to map the
derived keys to their keysources.
It treats Tr outputs differently from other kinds of outputs, because
the relevant maps are different. However, in doing so, it duplicates a
bunch of work in ways that are hard to follow.
Essentially, the algorithm does three things: (a) derives all the keys
(and the descriptor), (b) optionally checks that the resulting
scriptpubkey is what we expect, and (c) updates the maps. The existing
code handles (a) separately for Tr and non-Tr descriptors.
In the Tr case, we derive all the keys using
Descriptor::<DescriptorPublicKey>::derived_descriptor which derives all
the keys and throws away the conversion. Then separately it keeps around
the un-derived descriptor, iterates through the keys, and populates the
`tap_key_origins` map by re-computing the derivation.
In the non-Tr case, we derive all the keys using the `KeySourceLookUp`
object, which does exactly the same thing as `derived_descriptor` except
that it stores its work in a BTreeMap, which is directly added to the
PSBT's `item.bip32_derivation` field.
This commit pulls out (a) into common code; it then copies all the data
out of the key map into `item.tap_key_origins` along with an empty
vector of tapleaves. It then goes through all the leaves, and for each
key that appears in each leaf, appends that leaf's hash to the vector of
tapleaves. This is still a little ineffecient but will be much cleaner
after a later commit when we improve the Taproot SpendInfo structure.
The original code dates to Lloyd's 2022 PR rust-bitcoin#339 which introduces logic to
populate these maps. That algorithm underwent significant refactoring in
response to review comments and I suspect that the duplicated logic went
unnoticed after all the refactorings.
0 commit comments