Descriptors: allow the multipath step to be different from <0;1>
#599
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
darosior
changed the title
<0;1>
It's supposed to represent the number of signature per "master" key, i guess. At the moment it would always be 1 because the origin changes when we queried more keys from the signing device (because we increased the account).
darosior
force-pushed
the
descriptors_any_multipath_index
branch
from
0ba1d8b
to
b3d30cf
Compare
|
Rebased. |
Since wizardsardine#575 we started using xpubs with an appended derivation path, and the analysis was assuming there wasn't any.
Ledger and wallet policies disallow having more than 2 depth after the placeholder, therefore we can't do `@1/0/<0;1>/*`, `@1/1/<0;1>/*`, .. Instead we have to do `@1/<0;1>/*`, `@1/<2;3>/*`, .. Why not? Salvatore also says the cost of deriving another depth is non-trivial on a signing device. Don't pick a fight with Salvatore, instead just let the GUI (or whatever creates the desc) use different multipath steps for keys derived from the same xpubs.
darosior
force-pushed
the
descriptors_any_multipath_index
branch
from
b3d30cf
to
605c3f6
Compare
|
Rebased to get the MSRV fix from #584. |
edouardparis
approved these changes
Aug 10, 2023
darosior
added a commit
that referenced
this pull request
Aug 11, 2023
10acc48 descriptors: fix the signatures count analysis (Antoine Poinsot) 7a33040 descriptors: make signed_pubkeys a mapping from fingerprint (Antoine Poinsot) Pull request description: Needs more testing but that should do the trick: we need to take into account the derivation path appended to the xpub in addition to the one from the origin! ACKs for top commit: darosior: ACK 10acc48 -- Edouard ACK'd the child PR at #599 (review) Tree-SHA512: 912f482c5e10ece4127ffc86620f8ec581d0a209f8e1d407fd9885a7b6d1dfb13e7d5898c75da782282b9d40f69a80ad835e5a7648ceddcfc809445cdf246efb
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ledger and wallet policies disallow having more than 2 depth after the
placeholder, therefore we can't do
@1/0/<0;1>/*,@1/1/<0;1>/*, ..Instead we have to do
@1/<0;1>/*,@1/<2;3>/*, ..Why not? Salvatore also says the cost of deriving another depth is
non-trivial on a signing device.
Don't pick a fight with Salvatore, instead just let the GUI (or whatever
creates the desc) use different multipath steps for keys derived from
the same xpubs.
Based on #584. We need to make sure we don't make the assumptions of the multipath step always being
<0;1>anywhere else the codebase.