From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WT4RA-0000MU-5w for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 07:09:16 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WT4R7-0002z3-RT for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 07:09:16 +0000 Received: from [37.143.74.116] (helo=[192.168.2.2]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WT4R0-0001sy-Nm; Thu, 27 Mar 2014 08:09:06 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_FAA1B2B0-ACAD-4F87-8D91-92D20DAF5DDF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tamas Blummer In-Reply-To: Date: Thu, 27 Mar 2014 08:09:06 +0100 Message-Id: References: To: Mike Hearn X-Mailer: Apple Mail (2.1510) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1395904153; 783062d8; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WT4R7-0002z3-RT 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 07:09:16 -0000 --Apple-Mail=_FAA1B2B0-ACAD-4F87-8D91-92D20DAF5DDF Content-Type: multipart/alternative; boundary="Apple-Mail=_8C133F48-9714-4207-A5EA-549D17896ACC" --Apple-Mail=_8C133F48-9714-4207-A5EA-549D17896ACC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. >=20 > 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: >=20 > /m/cointype/reserved'/account'/change/n >=20 > 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. >=20 > 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. >=20 > 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? >=20 > account is for keeping essentially wallets-within-a-wallet to avoid = mixing of coins. If you want that. >=20 > change is 0 for receiving addresses, 1 for change addresses. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > = --------------------------------------------------------------------------= ---- > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --Apple-Mail=_8C133F48-9714-4207-A5EA-549D17896ACC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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,

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-develop= ment mailing list
Bitcoin-developm= ent@lists.sourceforge.net
https://lists.sourceforge.net/lists/listi= nfo/bitcoin-development

= --Apple-Mail=_8C133F48-9714-4207-A5EA-549D17896ACC-- --Apple-Mail=_FAA1B2B0-ACAD-4F87-8D91-92D20DAF5DDF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTM86SAAoJEPZykcUXcTkc7w0H/2G2cy7+M/EKImkuVDHXsRt8 yvyj0ayt1RLZKWpeVisP6M8AnOWn7Seg8AEQiI/TnvWU89YI/NfA7FmE/V/zGlzw uU1EmcxEG68YLyWJkhwxCD1OPEdJtJdd1oLvl6Cvv0kUmZKwU3TGZY4cDB6zlFdc 6c5Rov8+jNToXSdmAdHJCzVcvwLxkdl9QPWNdbzWNzKEm//i7klVYbyUxOYRnoe6 MMlqrqBAO7CZK4KlkpdkbIy0+uMG7mAthd1TRTAlL9CJa8hMSAJh+LStFXSd+voi h0Fy2vygrKJxfU3c+C5NV47Shkp3dNaTfmHF5p8OCxfSDoH8V51Nm9doGGATQ/A= =WR4a -----END PGP SIGNATURE----- --Apple-Mail=_FAA1B2B0-ACAD-4F87-8D91-92D20DAF5DDF--