path: root/08/e8bbdb1f6d851663da7850cc48c941d91d756b

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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
	<F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com>
Date: Thu, 27 Mar 2014 10:42:19 +0100
X-Google-Sender-Auth: A-bxqYGvsFkFGIuERUb7Uhrizkc
Message-ID: <CANEZrP0t6E5tKk_jcApwa+o4-qBg9uyRnePGarZXeLDxcKS+Rg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Tamas Blummer <tamas@bitsofproof.com>
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 <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 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 <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
>
>
>

--089e0112c4bcc6ac0f04f59366da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">At this point I&#39;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&#39;m not sure we can get all wallets to b=
e fully interoperable given the flexibility inherent in BIP32 and people&#3=
9;s differing use cases.<div>
<br></div><div>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&#39;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&#39;s a bit late for that now.</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Mar 27, 2014 at 8:09 AM, Tamas Blummer <span dir=3D"ltr">&l=
t;<a href=3D"mailto:tamas@bitsofproof.com" target=3D"_blank">tamas@bitsofpr=
oof.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word">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)<div>
at the Inside Bitcoin Conference in Berlin.</div><div><br></div><div>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 &quot;standardized&quot; for the reta=
il customer but definitelly not for corporate use,</div>
<div>where hierarchy will certainly map to organisational hierarchy or cost=
 centres.<br><div><br></div><div>
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 &quot;Bit=
coin&quot;, &quot;Litecoin&quot;, &quot;Dogecoin&quot;, so collosion is unl=
ikely and</div>
<div>cetral directory is not needed.</div><div><br></div><div><span style=
=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-w=
ebkit-auto;font-style:normal;display:inline!important;font-weight:normal;fl=
oat:none;line-height:normal;text-transform:none;font-size:medium;white-spac=
e:normal;font-family:Helvetica;word-spacing:0px">Regards,</span><br style=
=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-w=
ebkit-auto;font-style:normal;font-weight:normal;line-height:normal;text-tra=
nsform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-=
spacing:0px">
<br style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text=
-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal=
;text-transform:none;font-size:medium;white-space:normal;font-family:Helvet=
ica;word-spacing:0px">
<span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;te=
xt-align:-webkit-auto;font-style:normal;display:inline!important;font-weigh=
t:normal;float:none;line-height:normal;text-transform:none;font-size:medium=
;white-space:normal;font-family:Helvetica;word-spacing:0px">Tamas Blummer</=
span><br style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal=
;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:n=
ormal;text-transform:none;font-size:medium;white-space:normal;font-family:H=
elvetica;word-spacing:0px">
<span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;te=
xt-align:-webkit-auto;font-style:normal;display:inline!important;font-weigh=
t:normal;float:none;line-height:normal;text-transform:none;font-size:medium=
;white-space:normal;font-family:Helvetica;word-spacing:0px"><a href=3D"http=
://bitsofproof.com" target=3D"_blank">http://bitsofproof.com</a></span>
</div>
<br><div><div><div class=3D"h5"><div>On 26.03.2014, at 21:49, Mike Hearn &l=
t;<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&=
gt; wrote:</div><br></div></div><blockquote type=3D"cite"><div><div class=
=3D"h5">
<div dir=3D"ltr">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.<div><br></div=
>

<div>Because I&#39;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:</div>
<div>
<br></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">=
=C2=A0 /m/cointype/reserved&#39;/account&#39;</span><span style=3D"font-fam=
ily:arial,sans-serif;font-size:13px">/change/n</span><br></div><div><span s=
tyle=3D"font-family:arial,sans-serif;font-size:13px"><br>

</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">The extra levels require some explanation:</span></div><div><ul><li><fon=
t face=3D"arial, sans-serif">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&#39;t.<br>

<br>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 &quot;raw&quot; 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 &quot;=
other stuff&quot;. I actually don&#39;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?<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 f=
or receiving addresses, 1 for change addresses.<br>

<br></font></li><li><font face=3D"arial, sans-serif">n is the actual key in=
dex</font></li></ul><div><font face=3D"arial, sans-serif">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.</font></div>

</div><div><font face=3D"arial, sans-serif"><br></font></div><div><font fac=
e=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 b=
etween what wallets support.</font></div>

<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">Pieter made the I think valid point that you can&#39;t re=
ally encode how keys are meant to be used into just an HDW hierarchy and no=
rmally you&#39;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&#39;m happy to just g=
o with the flow on this one.</font></div>

<div><font face=3D"arial, sans-serif"><br></font></div></div></div></div><d=
iv class=3D"">
---------------------------------------------------------------------------=
---<br>_______________________________________________<br>Bitcoin-developme=
nt mailing list<br><a href=3D"mailto:Bitcoin-development@lists.sourceforge.=
net" target=3D"_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br></div></blockquote></div><br></div></div></blockquote></di=
v>
<br></div>

--089e0112c4bcc6ac0f04f59366da--