{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-27\n📝 Original message:At this point I'm not sure how much further work people want to do on this:\nI got the impression that Trezor will ship soon, and Thomas V seemed\nsatisfied too. I'm not sure we can get all wallets to be fully\ninteroperable given the flexibility inherent in BIP32 and people's\ndiffering use cases.\n\nAndreas: good point but I really hope nobody ever deletes a seed after all\nthis work we put in to make backups so easy! I'm not sure we can really\nstop it anyway: not unless we make the seed a full blown data structure\nwith hints to other apps that they should refuse to load it. And it's a bit\nlate for that now.\n\n\n\nOn Thu, Mar 27, 2014 at 8:09 AM, Tamas Blummer \u003ctamas at bitsofproof.com\u003ewrote:\n\n\u003e We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet),\n\u003e Jan Moller, Andreas  Petersson (Mycelium), Thomas V (Electrum), Tamas\n\u003e Blummer, Tamas Bartfai (Bits of Proof)\n\u003e at the Inside Bitcoin Conference in Berlin.\n\u003e\n\u003e I remember that there were different opinions on how to use a hierarchy\n\u003e and it did seem to me they could eventually be \"standardized\" for the\n\u003e retail customer but definitelly not for corporate use,\n\u003e where hierarchy will certainly map to organisational hierarchy or cost\n\u003e centres.\n\u003e\n\u003e A notable suggestion was to instead of building a directory of magic\n\u003e numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word\n\u003e \"Bitcoin\", \"Litecoin\", \"Dogecoin\", so collosion is unlikely and\n\u003e cetral directory is not needed.\n\u003e\n\u003e Regards,\n\u003e\n\u003e Tamas Blummer\n\u003e http://bitsofproof.com\n\u003e\n\u003e On 26.03.2014, at 21:49, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\n\u003e Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure\n\u003e our BIP32 wallet structures would be compatible - and I discovered that\n\u003e 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\n\u003e wallets with regards to importing 12-words paper wallets, we brainstormed\n\u003e 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\n\u003e    - cointype:  This is zero for Bitcoin. This is here to support two\n\u003e    things, one is supporting alt coins based off the same root seed. Right now\n\u003e    nobody seemed very bothered about alt coins but sometimes feature requests\n\u003e    do come in for this. Arguably there is no need and alt coins could just use\n\u003e    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\n\u003e    things like multisig outputs, e.g. for watchdog services. This means if\n\u003e    your wallet does not know about the extra protocol layers involved in this,\n\u003e    it can still import the \"raw\" money and it will just ignore/not see the\n\u003e    keys used in more complex transactions.\n\u003e\n\u003e    - reserved is for \"other stuff\". I actually don't recall why we ended\n\u003e    up with this. It may have been intended to split out multisig outputs etc\n\u003e    from cointype. Marek, Thomas?\n\u003e\n\u003e    - account is for keeping essentially wallets-within-a-wallet to avoid\n\u003e    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\n\u003e For bitcoinj we're targeting a deliberately limited feature set for hdw v1\n\u003e so I would just set the first three values all to zero and that is a\n\u003e 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\n\u003e the users needs, whilst still allowing some drift between what wallets\n\u003e support.\n\u003e\n\u003e Pieter made the I think valid point that you can't really encode how keys\n\u003e are meant to be used into just an HDW hierarchy and normally you'd need\n\u003e some metadata as well. However, I feel interop between wallets is more\n\u003e important than arriving at the most perfect possible arrangement, which\n\u003e feels a little like bikeshedding, so I'm happy to just go with the flow on\n\u003e this one.\n\u003e\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\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/29aa93a8/attachment.html\u003e"}