-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Add key origin support to descriptors #14150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
e6727aa to
e11d7ea
Compare
|
utACK e11d7ea24b7c67793ab8e84b5ad05d233f43e7da |
Sjors
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK.
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 scantxoutset.
e11d7ea to
78e5094
Compare
|
@Sjors I don't think this would be useful there. Instead we should have some new command that lets us import descriptors into the wallet. |
src/script/descriptor.cpp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2018-09-25 20:23:55 clang(pr=14150): script/descriptor.cpp:179:69: warning: implicit conversion changes signedness: 'int' to 'std::vector<unsigned int, std::allocator<unsigned int> >::value_type' (aka 'unsigned int') [-Wsign-conversion]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
95897b6 to
2782910
Compare
|
Rebased, and expanded documentation to include key origin information. |
|
Was there a problem with the last rebase? It seems like some changes that were previously made, like #14150 (comment), have been reverted. |
|
Concept ACK, will wait for the rebase to be fixed before reviewing then |
6053675 to
3fdc704
Compare
|
@ryanofsky Wow, indeed, thanks for pointing that out. I don't know how that happened. I went through all comments again, and reapplied the fixed I made earlier where necessary. I've also expanded the documentation change a bit. |
ryanofsky
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 3fdc704f06bb5618cb63c248b20447026509e00d. Left some comments below that aren't critical and you should feel free to ignore.
doc/descriptors.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This syntax is slightly weird to me because if you're looking at an expression like:
fingerprint/path1:xpub/path2
The fingerprint:path1 part only describes xpub, not xpub/path2, but there's no logical precedence of : and / operators that would lead me to see:
(fingerprint/path1:xpub)/path2
instead of:
(fingerprint/path1):(xpub/path2)
Maybe this is an unimportant aesthetic objection, but I'd almost rather there be an explicit origin function like:
origin(fingerprint/path1, xpub)/path2
or
origin(xpub, fingerprint/path1)/path2
that at least would group things together correctly.
3fdc704 to
71cbcd9
Compare
|
@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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 71cbcd9da8b31cb7cbe19001df32c8e1c46a603b. 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 and 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:
key[origin=fpr/path, device=myhardwarewallet]/path
Which might have other uses like:
key[birthday=timestamp]
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 |
71cbcd9 to
cfc8129
Compare
|
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. |
|
Oops, I reviewed 2 days ago and didn't refresh this page to see updates! |
instagibbs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
| assert_equal(self.nodes[0].scantxoutset("start", [ "combo(tprv8ZgxMBicQKsPd7Uf69XL1XwhmjHopUGep8GuEiJDZmbQz6o58LninorQAfcKZWARbtRtfnLcJ5MQ2AtHcQJCCRUcMRvmDUjyEmNUWwx8UbK/1/1/1500)"])['total_amount'], Decimal("16.384")) | ||
| assert_equal(self.nodes[0].scantxoutset("start", [ "combo(tpubD6NzVbkrYhZ4WaWSyoBvQwbpLkojyoTZPRsgXELWz3Popb3qkjcJyJUGLnL4qHHoQvao8ESaAstxYSnhyswJ76uZPStJRJCTKvosUCJZL5B/1/1/0)"])['total_amount'], Decimal("4.096")) | ||
| assert_equal(self.nodes[0].scantxoutset("start", [ "combo(tpubD6NzVbkrYhZ4WaWSyoBvQwbpLkojyoTZPRsgXELWz3Popb3qkjcJyJUGLnL4qHHoQvao8ESaAstxYSnhyswJ76uZPStJRJCTKvosUCJZL5B/1/1/1)"])['total_amount'], Decimal("8.192")) | ||
| assert_equal(self.nodes[0].scantxoutset("start", [ "combo([abcdef88/1/2'/3/4h]tpubD6NzVbkrYhZ4WaWSyoBvQwbpLkojyoTZPRsgXELWz3Popb3qkjcJyJUGLnL4qHHoQvao8ESaAstxYSnhyswJ76uZPStJRJCTKvosUCJZL5B/1/1/1)"])['total_amount'], Decimal("8.192")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could there be a comment to point out what it's doing? As a reader of the test this is basically lost in the pile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you're asking. I've added 2 lines of comment on this block of tests.
Or is it specifically about this including of the key origin in the test? It has no effect, as for now key origins are not observable anyway. So this is just testing that you can in fact specify one, and nothing breaks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant to a reader of the entire test itself, not the diff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, is what I added sufficient?
|
Addressed further comments in separate commits, will squash when ready. |
|
re-ACK |
meshcollider
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK f4a8ccb
|
utACK 91cff98264ba5c6a86ca5d18b2591f759cffe793, just documentation fixes and two variable cleanups |
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. |
91cff98 to
afa9224
Compare
|
Squashed fixups, no tree changes. |
afa9224 to
8afb166
Compare
|
Rebased afa9224b14 -> 8afb166 |
|
utACK 8afb166 |
ryanofsky
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
8afb166 Update documentation to incude origin information (Pieter Wuille) ff37459 Add tests for key origin support (Pieter Wuille) 2c6281f Add key origin support to descriptors (Pieter Wuille) Pull request description: This adds support for [key origin](https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82#key-origin-identification) information to the descriptor parser, and exposes the resulting key path information through `FlatSigningProvider`. There is no observable functionality from this right now, except having the `scantxoutset` RPC accept descriptors that include key origin information. 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). Tree-SHA512: 399828127b2e90a2f32d81ecc30a8a9261d08f4182d5d1744f05e46b25fde1bd383c54835b0820ca668e7d17353fa92c0fb2987e211ce269e0824c9395d210c2
Summary: 8afb166875 Update documentation to incude origin information (Pieter Wuille) ff37459abc Add tests for key origin support (Pieter Wuille) 2c6281f180 Add key origin support to descriptors (Pieter Wuille) Pull request description: This adds support for [key origin](https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82#key-origin-identification) information to the descriptor parser, and exposes the resulting key path information through `FlatSigningProvider`. There is no observable functionality from this right now, except having the `scantxoutset` RPC accept descriptors that include key origin information. 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). Tree-SHA512: 399828127b2e90a2f32d81ecc30a8a9261d08f4182d5d1744f05e46b25fde1bd383c54835b0820ca668e7d17353fa92c0fb2987e211ce269e0824c9395d210c2 Backport of Core [[bitcoin/bitcoin#14150 | PR14150]] Test Plan: ninja ninja check ninja check-functional Reviewers: O1 Bitcoin ABC, #bitcoin_abc, deadalnix Reviewed By: O1 Bitcoin ABC, #bitcoin_abc, deadalnix Subscribers: deadalnix Differential Revision: https://reviews.bitcoinabc.org/D6006
Summary: 8afb166875 Update documentation to incude origin information (Pieter Wuille) ff37459abc Add tests for key origin support (Pieter Wuille) 2c6281f180 Add key origin support to descriptors (Pieter Wuille) Pull request description: This adds support for [key origin](https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82#key-origin-identification) information to the descriptor parser, and exposes the resulting key path information through `FlatSigningProvider`. There is no observable functionality from this right now, except having the `scantxoutset` RPC accept descriptors that include key origin information. 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). Tree-SHA512: 399828127b2e90a2f32d81ecc30a8a9261d08f4182d5d1744f05e46b25fde1bd383c54835b0820ca668e7d17353fa92c0fb2987e211ce269e0824c9395d210c2 Backport of Core [[bitcoin/bitcoin#14150 | PR14150]] Test Plan: ninja ninja check ninja check-functional Reviewers: O1 Bitcoin ABC, #bitcoin_abc, deadalnix Reviewed By: O1 Bitcoin ABC, #bitcoin_abc, deadalnix Subscribers: deadalnix Differential Revision: https://reviews.bitcoinabc.org/D6006
This adds support for key origin information to the descriptor parser, and exposes the resulting key path information through
FlatSigningProvider.There is no observable functionality from this right now, except having the
scantxoutsetRPC accept descriptors that include key origin information.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).