path: root/47/961cdb3ff53e2681a091c543297ef202a6139f

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 <tamas@bitsofproof.com>) 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 <tamas@bitsofproof.com>
In-Reply-To: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
Date: Thu, 27 Mar 2014 08:09:06 +0100
Message-Id: <F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
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 <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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.
>=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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">We =
had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), =
Jan Moller,&nbsp;Andreas&nbsp;&nbsp;Petersson (Mycelium), Thomas V =
(Electrum), Tamas Blummer, Tamas Bartfai (Bits of Proof)<div>at the =
Inside Bitcoin Conference in Berlin.</div><div><br></div><div>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,</div><div>where =
hierarchy will certainly map to organisational hierarchy or cost =
centres.<br><div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">
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</div><div apple-content-edited=3D"true">cetral directory is not =
needed.</div><div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true"><span style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
display: inline !important; float: none; ">Regards,</span><br =
style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
-webkit-auto; text-indent: 0px; text-transform: none; white-space: =
normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; "><br style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
"><span style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
medium; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
-webkit-auto; text-indent: 0px; text-transform: none; white-space: =
normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; display: inline !important; float: none; =
">Tamas Blummer</span><br style=3D"color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: medium; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span =
style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
-webkit-auto; text-indent: 0px; text-transform: none; white-space: =
normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; display: inline !important; float: none; =
"><a href=3D"http://bitsofproof.com">http://bitsofproof.com</a></span>
</div>
<br><div><div>On 26.03.2014, at 21:49, Mike Hearn &lt;<a =
href=3D"mailto:mike@plan99.net">mike@plan99.net</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
dir=3D"ltr">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.<div><br></div>
<div>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:</div><div>
<br></div><div><span =
style=3D"font-family:arial,sans-serif;font-size:13px">&nbsp; =
/m/cointype/reserved'/account'</span><span =
style=3D"font-family:arial,sans-serif;font-size:13px">/change/n</span><br>=
</div><div><span =
style=3D"font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span =
style=3D"font-family:arial,sans-serif;font-size:13px">The extra levels =
require some explanation:</span></div><div><ul><li><font face=3D"arial, =
sans-serif">cointype: &nbsp;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.<br>
<br>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.<br>
<br></font></li><li><font face=3D"arial, sans-serif">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?<br>
<br></font></li><li><font face=3D"arial, sans-serif">account is for =
keeping essentially wallets-within-a-wallet to avoid mixing of coins. If =
you want that.<br><br></font></li><li><font face=3D"arial, =
sans-serif">change is 0 for receiving addresses, 1 for change =
addresses.<br>
<br></font></li><li><font face=3D"arial, sans-serif">n is the actual key =
index</font></li></ul><div><font face=3D"arial, sans-serif">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.</font></div>
</div><div><font face=3D"arial, sans-serif"><br></font></div><div><font =
face=3D"arial, sans-serif">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.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font =
face=3D"arial, sans-serif">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.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div></div>
=
--------------------------------------------------------------------------=
----<br>_______________________________________________<br>Bitcoin-develop=
ment mailing list<br><a =
href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-developm=
ent@lists.sourceforge.net</a><br>https://lists.sourceforge.net/lists/listi=
nfo/bitcoin-development<br></blockquote></div><br></div></body></html>=

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