Re: [Bitcoin-development] New BIP32 structure

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 4282 bytes --]

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@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@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>

[-- Attachment #2: Type: text/html, Size: 7747 bytes --]