Skip to content

Conversation

@jonasschnelli
Copy link
Contributor

This adds the startup argument -hdkeypath which 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.

Copy link
Contributor

@dcousens dcousens left a 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?

@jonasschnelli
Copy link
Contributor Author

@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.

Copy link
Member

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?

Copy link
Contributor Author

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)

@jonasschnelli
Copy link
Contributor Author

Rebased.
I hope we can make some progress regarding the flexibility of our HD wallet feature as well as with pub-child-key-derivation.

@jonasschnelli
Copy link
Contributor Author

Accidentally closed, reopen.

@jonasschnelli jonasschnelli reopened this Oct 20, 2016
@jonasschnelli jonasschnelli added this to the 0.14.0 milestone Nov 25, 2016
@jonasschnelli
Copy link
Contributor Author

Added the 0.14 milestone label.
IMO we should support flexible keypaths as well as wallet creation with an initial xpriv.

@jmcorgan
Copy link
Contributor

jmcorgan commented Dec 2, 2016

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.

@jtimon
Copy link
Contributor

jtimon commented Jan 10, 2017

Concept ACK, needs rebase.

Copy link
Member

@Sjors Sjors left a 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 ...")
Copy link
Member

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 ...")

@DrahtBot
Copy link
Contributor

DrahtBot commented Nov 8, 2018

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.

@Sjors
Copy link
Member

Sjors commented Nov 10, 2018

I think this should be revisited after adding descriptor support to import_multi #14491 and the ambition to turn wallets into descriptor bags. Once that's done this should be a simple matter of adding optional descriptor arguments to createwallet so users can pick whatever derivation scheme they prefer.

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Dec 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants