Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-27 📝 Original message:At this point I'm not sure ...

📅 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>;