rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2014-03-27 📝 Original message:At this point I'm not sure how much further work people want to do on this: I got the impression that Trezor will ship soon, and Thomas V seemed satisfied too. I'm not sure we can get all wallets to be fully interoperable given the flexibility inherent in BIP32 and people's differing use cases. Andreas: good point but I really hope nobody ever deletes a seed after all this work we put in to make backups so easy! I'm not sure we can really stop it anyway: not unless we make the seed a full blown data structure with hints to other apps that they should refuse to load it. And it's a bit late for that now. On Thu, Mar 27, 2014 at 8:09 AM, Tamas Blummer <tamas at bitsofproof.com>wrote: > 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/29aa93a8/attachment.html>