-
Notifications
You must be signed in to change notification settings - Fork 38.7k
[Wallet] Add support for flexible BIP32/HD keypath-scheme #8723
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
e92366a to
bb87e2d
Compare
dcousens
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, has there been any though for adhering to the scheme of 2 accounts, 1 for receiving and 1 for change?
|
@dcousens: Yes. I have thought about the split of the two key-chains (internal/external). But the current keypool concept make it a bit more difficult. I guess it could be combined with the feature to allow public key derivation. |
src/wallet/wallet.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.
Maybe the default here should be the current scheme?
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.
The default is the current scheme IMO (DEFAULT_HD_KEYPATH_SCHEME == "m/0'/0'/k'" == current scheme)
|
Rebased. |
bb87e2d to
c587577
Compare
|
Accidentally closed, reopen. |
|
Added the 0.14 milestone label. |
|
ACK. It works as is, however, I would like to see either a separate keypath scheme for change keys, or a way of specifying both in the existing one. Of course, you'd need to actually implement the split in the wallet code. Wallet creation with an xpriv/keypathscheme would be very useful, however, it brings up the question of restoring a wallet from only those (scanning, gap policy, etc.), vs. a full wallet.dat file. |
|
Concept ACK, needs rebase. |
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
I'll try this against some other wallets after rebase, both importing and exporting.
I suspect wallet compatibility is going to be somewhat painful with SegWit, but let's deal with that in another PR.
| #connect_nodes_bi(self.nodes, 0, 1) | ||
| assert_equal(self.nodes[1].getbalance(), num_hd_adds + 1) | ||
|
|
||
| print("Testing flexible keypath scheme ...") |
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.
self.logger.info("Testing flexible keypath scheme ...")
| There hasn't been much activity lately and the patch still needs rebase, so I am closing this for now. Please let me know when you want to continue working on this, so the pull request can be re-opened. |
|
I think this should be revisited after adding descriptor support to |
This adds the startup argument
-hdkeypathwhich allows to set the BIP32 keypath scheme during the creation of a wallet.This PR would allow to use keypath-scheme after BIP44, etc. to be compatible with other wallets.
This PR does not change the keypool mechanism. Even if the keypath would allow public-key-derivation, we still derive all keys with private-key-derivation and fill up the keypool.
Though, a PR that would enable public-key-derivation would be "in a reviewable size" once this gets merged.