Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add key origin support to descriptors #14150
This adds support for key origin information to the descriptor parser, and exposes the resulting key path information through
There is no observable functionality from this right now, except having the
Longer term this feature helps with a potential descriptors-based walletless PSBT updater, or for importing hardware wallet xpubs (once the wallet can import descriptors).
For me this would be easier to review when combined with a practical usage, like creating a PSBT with the origin info still in it. That could just be a WIP PR as it might involve quite a few changes, since descriptors currently are only used with
referenced this pull request
Oct 17, 2018
@ryanofsky Addressed all your comments except the syntax issue, which we should probably discuss at the PR level rather than buried inside a code comment.
I agree that
After thinking a bit more about it, how do you feel about
An alternative which is somewhat easier to parse I think is
utACK 71cbcd9. Only changes since last review were suggested changes (replacing +4's, adding a few test cases and a comment).
I think I like both of the
fpr/path[key]/path syntaxes more than the current
fpr/path:key/path syntax and more than my
origin() suggestion, and I agree that the
[fpr/path]key/path version is probably more understandable.
I might also propose a more generalized syntax for adding attributes to keys like:
Which might have other uses like:
But this might be too heavyweight. Anyway, you've thought about this a lot more than I have and I think whatever syntax you like, including the current syntax, should be fine.
Could you explain how these use-cases benefit from having origin information embedded inside descriptor expressions? It seems like it might be simpler if the descriptor language only described how things should be signed, and if key information was stored (or passed) in a separate a key id -> key metadata mapping.
@ryanofsky A PSBT updater needs to add key origin information to the PSBT file, or future signers may not be able to find the key to sign with.
I really think this information needs to be part of descriptors for them to be generally useful. Just listing the public keys is useless if those using the information don't know how to find the private key corresponding to said public key. In a way, that derivation information should from our point of view be treated as part of the public information about that key.
Another argument is so that you can 'specialize' a ranged descriptor to an individual one (like what may be desirable for #14503), without losing information. With origin support you can go from
Switched to the
As far as other attributes go, I'm not sure descriptors are the right place (this may be getting philosophical, though):
My preference is keeping those two as metadata on the descriptor (together with things like gap limit/range, whether the outputs are treated as change, ...). The same could be done with key origin information, but it feels more fundamental to not lose that information.
If there are generally useful properties of keys or path elements later we can still adopt such a syntax, though; it looks pretty readable.
utACK cfc8129. Only change since last review is syntax update.
Thanks for the explanations. I can see why you wouldn't want to make birthdays a property of keys, and it's also very clear that a PBST API which takes descriptors will be a lot clumsier if key origin information has to be passed in a separate table, instead of just embedded in the descriptors.
referenced this pull request
Oct 19, 2018
This was referenced
Oct 20, 2018
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.