I have rebased our segwit branch on master. This allows us to make use of arbitrary derivation paths as this has been implemented by Nelson Melina and Giuseppe Magnotta.
On 07/21/2017 07:34 PM, Andreas Schildbach wrote: > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
