Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-26 📝 Original message:Myself, Thomas V ...
📅 Original date posted:2014-03-26
📝 Original message:Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
our BIP32 wallet structures would be compatible - and I discovered that
only I was planning to use the default structure.
Because I'm hopeful that we can get a lot of interoperability between
wallets with regards to importing 12-words paper wallets, we brainstormed
to find a structure acceptable to everyone and ended up with:
/m/cointype/reserved'/account'/change/n
The extra levels require some explanation:
- cointype: This is zero for Bitcoin. This is here to support two
things, one is supporting alt coins based off the same root seed. Right now
nobody seemed very bothered about alt coins but sometimes feature requests
do come in for this. Arguably there is no need and alt coins could just use
the same keys as Bitcoin, but it may help avoid confusion if they don't.
More usefully, cointype can distinguish between keys intended for things
like multisig outputs, e.g. for watchdog services. This means if your
wallet does not know about the extra protocol layers involved in this, it
can still import the "raw" money and it will just ignore/not see the keys
used in more complex transactions.
- reserved is for "other stuff". I actually don't recall why we ended up
with this. It may have been intended to split out multisig outputs etc from
cointype. Marek, Thomas?
- account is for keeping essentially wallets-within-a-wallet to avoid
mixing of coins. If you want that.
- change is 0 for receiving addresses, 1 for change addresses.
- n is the actual key index
For bitcoinj we're targeting a deliberately limited feature set for hdw v1
so I would just set the first three values all to zero and that is a
perfectly fine way to be compatible.
The goal here is that the same seed can be written down once, and meet all
the users needs, whilst still allowing some drift between what wallets
support.
Pieter made the I think valid point that you can't really encode how keys
are meant to be used into just an HDW hierarchy and normally you'd need
some metadata as well. However, I feel interop between wallets is more
important than arriving at the most perfect possible arrangement, which
feels a little like bikeshedding, so I'm happy to just go with the flow on
this one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140326/ed7506b1/attachment.html>;
📝 Original message:Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
our BIP32 wallet structures would be compatible - and I discovered that
only I was planning to use the default structure.
Because I'm hopeful that we can get a lot of interoperability between
wallets with regards to importing 12-words paper wallets, we brainstormed
to find a structure acceptable to everyone and ended up with:
/m/cointype/reserved'/account'/change/n
The extra levels require some explanation:
- cointype: This is zero for Bitcoin. This is here to support two
things, one is supporting alt coins based off the same root seed. Right now
nobody seemed very bothered about alt coins but sometimes feature requests
do come in for this. Arguably there is no need and alt coins could just use
the same keys as Bitcoin, but it may help avoid confusion if they don't.
More usefully, cointype can distinguish between keys intended for things
like multisig outputs, e.g. for watchdog services. This means if your
wallet does not know about the extra protocol layers involved in this, it
can still import the "raw" money and it will just ignore/not see the keys
used in more complex transactions.
- reserved is for "other stuff". I actually don't recall why we ended up
with this. It may have been intended to split out multisig outputs etc from
cointype. Marek, Thomas?
- account is for keeping essentially wallets-within-a-wallet to avoid
mixing of coins. If you want that.
- change is 0 for receiving addresses, 1 for change addresses.
- n is the actual key index
For bitcoinj we're targeting a deliberately limited feature set for hdw v1
so I would just set the first three values all to zero and that is a
perfectly fine way to be compatible.
The goal here is that the same seed can be written down once, and meet all
the users needs, whilst still allowing some drift between what wallets
support.
Pieter made the I think valid point that you can't really encode how keys
are meant to be used into just an HDW hierarchy and normally you'd need
some metadata as well. However, I feel interop between wallets is more
important than arriving at the most perfect possible arrangement, which
feels a little like bikeshedding, so I'm happy to just go with the flow on
this one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140326/ed7506b1/attachment.html>;