Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WT6pO-0005Bf-V1 for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 09:42:26 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.181 as permitted sender) client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f181.google.com; Received: from mail-ob0-f181.google.com ([209.85.214.181]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WT6pN-0005d9-Go for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 09:42:26 +0000 Received: by mail-ob0-f181.google.com with SMTP id wp4so3945540obc.40 for ; Thu, 27 Mar 2014 02:42:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.97.193 with SMTP id ec1mr658079oeb.20.1395913340134; Thu, 27 Mar 2014 02:42:20 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Thu, 27 Mar 2014 02:42:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Mar 2014 10:42:19 +0100 X-Google-Sender-Auth: A-bxqYGvsFkFGIuERUb7Uhrizkc Message-ID: From: Mike Hearn To: Tamas Blummer Content-Type: multipart/alternative; boundary=089e0112c4bcc6ac0f04f59366da X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WT6pN-0005d9-Go Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] New BIP32 structure X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 09:42:27 -0000 --089e0112c4bcc6ac0f04f59366da Content-Type: text/plain; charset=UTF-8 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 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 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 > > > --089e0112c4bcc6ac0f04f59366da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At this point I'm not sure how much further work peopl= e 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 b= e fully interoperable given the flexibility inherent in BIP32 and people= 9;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 sur= e we can really stop it anyway: not unless we make the seed a full blown da= ta structure with hints to other apps that they should refuse to load it. A= nd it's a bit late for that now.



On Thu, Mar 27, 2014 at 8:09 AM, Tamas Blummer &l= t;tamas@bitsofpr= oof.com> wrote:
We had a= similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan Moll= er,=C2=A0Andreas=C2=A0=C2=A0Petersson (Mycelium), Thomas V (Electrum), Tama= s Blummer, Tamas Bartfai (Bits of Proof)
at the Inside Bitcoin Conference in Berlin.

I reme= mber that there were different opinions on how to use a hierarchy and it di= d seem to me they could eventually be "standardized" for the reta= il 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 number= s (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bit= coin", "Litecoin", "Dogecoin", so collosion is unl= ikely and
cetral directory is not needed.

Regards,

Tamas Blummer
http://bitsofproof.com

On 26.03.2014, at 21:49, Mike Hearn &l= t;mike@plan99.net&= gt; wrote:

Myself, Thomas V (Electrum) and Marek (Trezor) got togethe= r to make sure our BIP32 wallet structures would be compatible - and I disc= overed that only I was planning to use the default structure.

Because I'm hopeful that we can get a lot of interoperability betw= een wallets with regards to importing 12-words paper wallets, we brainstorm= ed to find a structure acceptable to everyone and ended up with:

= =C2=A0 /m/cointype/reserved'/account'/change/n

The extra levels require some explanation:
  • cointype: =C2=A0This is zero for Bitcoin. This= is here to support two things, one is supporting alt coins based off the s= ame root seed. Right now nobody seemed very bothered about alt coins but so= metimes 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 c= onfusion if they don't.

    More usefully, cointype can distinguish between keys intended for thing= s like multisig outputs, e.g. for watchdog services. This means if your wal= let 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. I= t may have been intended to split out multisig outputs etc from cointype. M= arek, Thomas?

  • account is for keeping= essentially wallets-within-a-wallet to avoid mixing of coins. If you want = that.

  • change is 0 f= or receiving addresses, 1 for change addresses.

  • n is the actual key in= dex
For bitcoinj we&#= 39;re targeting a deliberately limited feature set for hdw v1 so I would ju= st 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 b= etween what wallets support.

Pieter made the I think valid point that you can't re= ally encode how keys are meant to be used into just an HDW hierarchy and no= rmally you'd need some metadata as well. However, I feel interop betwee= n wallets is more important than arriving at the most perfect possible arra= ngement, which feels a little like bikeshedding, so I'm happy to just g= o with the flow on this one.

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-developme= nt mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e0112c4bcc6ac0f04f59366da--