With segwit on the horizon (finally!), I think it's time to discuss
decide how segwit addresses are obtained from a wallet by hierarchical
derivation from a single seed. When I say segwit address it can be one
of P2SH-P2WPKH or P2WPKH, it doesn't matter for this discussion.
The status quo: Currently bitcoinj's Wallet class only implements the
"default account" from the BIP32 HD standard. This means all external
addresses are derived from the path m/0'/0/0..n and internal addresses
from m/0'/1/0..n. This is implemented in a rather hardcoded way in the
class DeterministicKeyChain and DeterministicHierarchy. The whole thing
is wrapper in a KeyChainGroup, which contains (historically) one
BasicKeyChain (container for individual addresses) and one or more
DeterministicKeyChains. The reason for allowing multiple
DeterministicKeyChains is because the private keys of a
DeterministicKeyChain might become unsafe. However there is always only
one DeterministicKeyChain active for address derivation.
Now imho it's pretty clear we should put segwit addresses on a different
branch in the hierarchy, to keep them separated. This would duplicate
the number of chains from 2 to 4.
The two straightforward structures look like this:
a)
m/0'/0/0..n (external non-segwit)
1/0..n (internal non-segwit)
2/0..n (external segwit)
3/0..n (internal segwit)
b)
m/0'/0/0..n (external non-segwit)
1/0..n (internal non-segwit)
m/1'/0/0..n (external segwit)
1/0..n (internal segwit)
(for this variant to be BIP43 compatible, we'd need to come up with an
additional BIP reserving that purpose number, which would likely change
the number from 1' to something else)
Also for the implementation side, I see two possibilities:
A)
Extend DeterministicKeyChain/DeterministicHierarchy to manage 4 chains
rather than just 2. An "preferredAddressType" parameter should tell the
class which type of addresses are preferred when fresh addresses are
derived. This impl could implement either of above structures a or b.
B)
Make DeterministicKeyChain only derive one or the other address type and
instead put a second, segwit capable DeterministicKeyChain into the
KeyChainGroup. It would copy the seed/root key from the existing
DeterministicKeyChain so no additional wallet backup is necessary. In
this case, we need to pay attention to the already existing key rollover
mechanism. I think choosing this impl would tie us to above structure b.
I'm currently pretty much undecided between the two structures and
implementations. I'd like to hear your opinion and maybe different ideas.
How others do it: I've also looked at how other wallets with segwit
support have decided.
Electrum - Can't mix segwit and non-segwit at all. You decide when you
create your wallet (they call it "account") but you can only use one
wallet at a time.
MyTrezor - Have come up with BIP49, supplementing BIP44. They will be
using a separate account in their wallet, which is quite similar to
above structure b.
Bitcoin Core - Although of course core supports segwit I believe their
wallet does not derive segwit addresses at all yet. I'll try to ask them
about their plans.
If you have more examples, please feel free to add. I'm very interested
in the various pros and cons of different approaches.
Side note: While we are working on HD derivation, we could also try to
make it compatible to (almost) any structure, e.g. BIP44 or the
BIP32-variant that is used by the core wallet. I always envisioned the
DeterministicHierarchy class would allow for flexible layouts, but
unfortunately it turned out it's all pretty hardcoded and non-trivial to
untangle.
--
You received this message because you are subscribed to the Google Groups
"bitcoinj" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to bitcoinj+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
