📅 Original date posted:2014-03-27
📝 Original message:We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas Blummer, Tamas Bartfai (Bits of Proof)
at the Inside Bitcoin Conference in Berlin.
I remember that there were different opinions on how to use a hierarchy and it did seem to me they could eventually be "standardized" for the retail customer but definitelly not for corporate use,
where hierarchy will certainly map to organisational hierarchy or cost centres.
A notable suggestion was to instead of building a directory of magic numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin", "Litecoin", "Dogecoin", so collosion is unlikely and
cetral directory is not needed.
Regards,
Tamas Blummer
http://bitsofproof.com
On 26.03.2014, at 21:49, Mike Hearn <mike at plan99.net> wrote:
> 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.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/6c47bae7/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/6c47bae7/attachment.sig>;
Tamas Blummer [ARCHIVE] /
npub1cc…ex8m8
2023-06-07 15:16:16
in reply to nevent1q…sl4v
Author Public Key
npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8Published at
2023-06-07 15:16:16Event JSON
{
"id": "34dfd9f15eaf39a5d874d7a5fdb81f09c06f31760f16a63e30b4e8436433edd8",
"pubkey": "c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7",
"created_at": 1686150976,
"kind": 1,
"tags": [
[
"e",
"d9ddea79394f356d989e65ab112610cc90e9929cf3c160da3cfe266aeba22200",
"",
"root"
],
[
"e",
"b47868c6b3eaf7ae0bf54ba2e813cc98234d4685542f302fa3be57319c865055",
"",
"reply"
],
[
"p",
"de834b230daa8e6d04c44e51929c52dfdc36dc2f4105a0b67060d9dfc30d6ccc"
]
],
"content": "📅 Original date posted:2014-03-27\n📝 Original message:We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas Blummer, Tamas Bartfai (Bits of Proof)\nat the Inside Bitcoin Conference in Berlin.\n\nI remember that there were different opinions on how to use a hierarchy and it did seem to me they could eventually be \"standardized\" for the retail customer but definitelly not for corporate use,\nwhere hierarchy will certainly map to organisational hierarchy or cost centres.\n\nA notable suggestion was to instead of building a directory of magic numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word \"Bitcoin\", \"Litecoin\", \"Dogecoin\", so collosion is unlikely and\ncetral directory is not needed.\n\nRegards,\n\nTamas Blummer\nhttp://bitsofproof.com\n\nOn 26.03.2014, at 21:49, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e 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.\n\u003e \n\u003e 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:\n\u003e \n\u003e /m/cointype/reserved'/account'/change/n\n\u003e \n\u003e The extra levels require some explanation:\n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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?\n\u003e \n\u003e account is for keeping essentially wallets-within-a-wallet to avoid mixing of coins. If you want that.\n\u003e \n\u003e change is 0 for receiving addresses, 1 for change addresses.\n\u003e \n\u003e n is the actual key index\n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/6c47bae7/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/6c47bae7/attachment.sig\u003e",
"sig": "e16757f5572309e50e9793b6c4b8cbc0e917b6fc8f2f85e8add0fe4f8cfe7fa3a26043619bda0cbf06b91f0e1bbfc389e36c9ca72a999baec99243c0f6646603"
}