Skip to content
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

BIP 44/49/84 Keychain support #1869

Open
msgilligan opened this issue May 29, 2019 · 5 comments

Comments

Projects
None yet
3 participants
@msgilligan
Copy link
Contributor

commented May 29, 2019

The DeterministicKeyChain class JavaDoc says that it implements BIP 32. I've been using it with BIP 44 paths (P2PKH only for now) and it seems to be working correctly, but the class could be modified/extended to better support BIP 44 (or possibly a subclass could be created) as there are some missing constants and behaviors that could be built-in.

I'd also like to see BIP 44 watching wallet and hardware wallet support.

We also need to support

  • BIP 49 - purpose 49' for P2WPKH-nested-in-P2SH transactions.
  • BIP 84 - purpose 84' for P2WPKH transactions.

@msgilligan msgilligan changed the title BIP 44 Keychain support BIP 44/49/84 Keychain support May 30, 2019

@schildbach

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

I'm not sure if DeterministicKeyChain is the right place to implement BIP44/49/84. The class should work on any path. The only assumption is the internal/external subpath separation of addresses which is currently hardcoded. And the lookahead.

Maybe we should move the *_PATH constants (but not the *_SUBPATH constants) to KeyChainGroup or to KeyChainGroupStructure?

I'm also not sure if we need to support BIP49 – I'd say we could. Personally I hope we can skip it. P2WPKH is the way to go and P2PKH works as a fallback.

Regarding BIP84 … we could start by providing a KeyChainGroupStructure implementation that uses BIP44 for P2PKH and BIP84 for P2WPKH?

@msgilligan

This comment has been minimized.

Copy link
Contributor Author

commented Jun 4, 2019

I'm not sure if DeterministicKeyChain is the right place to implement BIP44/49/84. The class should work on any path.

Agreed.

Maybe we should move the *_PATH constants (but not the *_SUBPATH constants) to KeyChainGroup or to KeyChainGroupStructure?

Yes, that sounds about right.

I'm also not sure if we need to support BIP49 – I'd say we could. Personally I hope we can skip it. P2WPKH is the way to go and P2PKH works as a fallback.

Yeah, I don't think it is very important (and I don't think I need it for anything I'm planning on doing) but we should probably provide the "purpose" constant and make sure we don't preclude anyone from using BIP 49 if they need to.

Regarding BIP84 … we could start by providing a KeyChainGroupStructure implementation that uses BIP44 for P2PKH and BIP84 for P2WPKH?

That sounds like the right approach. I also have some ideas and code for an HDPath class that replaces (but is compatible with) the current use of ImmutableList<ChildNumber> that should make the code a little more readable and maintainable.

@msgilligan

This comment has been minimized.

Copy link
Contributor Author

commented Jun 8, 2019

PR #1877 adds the HDPath class which might be a good place to put some of the *_PATH constants.

@HashEngineering

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2019

The DeterministicKeyChain class does work on other paths. Over 1 year ago, such support was added. In a fork of this project I create wallets with BIP32 and BIP44 paths to keep compatibility with wallets that only have BIP32.

Recently, I have been looking at bitcoinj 0.15 and found that the KeyChainGroupStructure class is interesting and a promising start to addressing this issue.

@msgilligan

This comment has been minimized.

Copy link
Contributor Author

commented Jun 30, 2019

the KeyChainGroupStructure class is interesting and a promising start to addressing this issue.

Yes, I have created an implementation of that interface in another project that I plan on using as the basis of a future PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.