path: root/4e/b3ca87cbf6fc1e0c5625531b10014ad38bd5b1

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mike@belshe.com>) id 1WT43d-0008CF-U7
	for bitcoin-development@lists.sourceforge.net;
	Thu, 27 Mar 2014 06:44:57 +0000
X-ACL-Warn: 
Received: from mail-qc0-f169.google.com ([209.85.216.169])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WT43c-0007XP-6f
	for bitcoin-development@lists.sourceforge.net;
	Thu, 27 Mar 2014 06:44:57 +0000
Received: by mail-qc0-f169.google.com with SMTP id i17so3823187qcy.28
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 26 Mar 2014 23:44:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=RFI8P+882ysAJXPlbQb0aRUnB+oVHWB2LrMUm7M1eTQ=;
	b=QzWZm/r3O9bOr6nnhhsRMA9iYXhziACIJTM9KrwHz/Igfkr4LWYlCkdzULe0eF9oEb
	rmbwGxY4dnwxUvWL7t38vuDEzY+zNo4/eaOySsR7ORooBrgx5Uxflj57JoStbp5hKgGp
	uDB6JZzfushJWA7SnhVomFM9xF8SW9xjvA+vsl6uBfw/0Gz8+vnZ1ub1cYWgtTDcY2Qz
	N+RQDWcHQ/h+gwy6KpIi46TeoLu5vqjpOnnX6T7WyJ5OoioZcwV0uRS2cFBWa7m5l6Tn
	MYNJWxbSvUhFO4pP1zwVtUM0VWwjPLUmYvFpLWPYENVG7TBXtifuOIa7+RlzkQiFP/yY
	ntVg==
X-Gm-Message-State: ALoCoQkNhzfrBrrwP94NRdXBr2udqUGkVPAlSfDgBY2yJXq0bzXWdRAuRMBoNP6gv12eHEHGxIEs
MIME-Version: 1.0
X-Received: by 10.140.47.203 with SMTP id m69mr89776254qga.21.1395900950831;
	Wed, 26 Mar 2014 23:15:50 -0700 (PDT)
Received: by 10.96.82.104 with HTTP; Wed, 26 Mar 2014 23:15:50 -0700 (PDT)
In-Reply-To: <53337874.7010300@gmail.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
	<lgvobr$q44$1@ger.gmane.org> <53337874.7010300@gmail.com>
Date: Wed, 26 Mar 2014 23:15:50 -0700
Message-ID: <CABaLYCs0JzNaik8abLu-qeDgRZDu75_oeUGG3SgrQs02U=xvxA@mail.gmail.com>
From: Mike Belshe <mike@belshe.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c159ac50fb8004f5908468
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: 1WT43c-0007XP-6f
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 06:44:58 -0000

--001a11c159ac50fb8004f5908468
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 26, 2014 at 6:01 PM, Alan Reiner <etotheipi@gmail.com> wrote:

>  This might be tangential, but the comment about "refund" chains reminded
> me.  Armory will be implementing multi-sig/linked wallets where a each
> device has a parallel HDW branch and produces P2SH addresses.  For those
> types of wallets, I plan to allocate two chains *per signing authority*.
> If you have a shared 2-of-2 wallet split between your phone and your
> spouse's phone, your phone would distribute addresses on P2SH chain 0 and
> generate change addresses on P2SH chain 1.  Your spouse's phone would use
> chains 2 and 3.
>
> So if you and your spouse switch to a new app that supports M-of-N linked
> wallets, it should search for coin history along the first 2*N chains.
>

In general with multisig, we should probably discourage using a common root
keychain for multiple keys in the same P2SH address.  The reason is because
if you have the single, root private key, you can sign them all. This
generally goes against the point of multisig - which was trying to
introduce a system which had multiple keys required to unlock :-)

For the BitGo BIP32 implementation we are doing the following:
   - users create 2 extended keys
   - bitgo creates 1 extended key for that user
   - the user can create any number of separate branches (accounts) of P2SH
addresses from those extended keys.
   - change/public addresses are generated from the 0/1 branches
   - new addresses are generated from there.
   - each time a new change address is generated, all 3 keys in the P2SH
are rotated.  This makes it so that for any chain depth *i* of the P2SH
address, we're using the *i*th key in each keychain.  For privacy reasons,
we don't need to rotate all keys.  But I think it makes management simpler
and probably more ready for interop.

So the paths in a user's keychain look exactly like BIP32's layout:
     m/<AccountIndex>/<ExternalOrInternal>/<AddressIndex>

Another issue unique to P2SH addresses is order of the keys. There has been
talk in this list of how to sort them.  While sorting is simplifying for
interop if you never use new change addresses, I believe sorting makes
wallet management more difficult when BIP32 is introduced.

Specifically, imagine a P2SH address with keys held by Bob, Charlie, and
Dana.  If you sort the pubkeys, then with each BIP32 chain, the order of
the keys could be different.  By maintaining key order, we always know
which of the pubkeys belongs to which user without having to do any lookups.

Obviously this can all be calculated too.  But the sorting seems gratuitous
to me - it adds complexity but offers little value.  On the other hand, it
can be really handy to know that key #0 for this address is always Bob's
key, regardless of how deep the chaining goes.

Mike



>
> -Alan
>
>
>
>
> On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
>
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, 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 listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>  ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--001a11c159ac50fb8004f5908468
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Mar 26, 2014 at 6:01 PM, Alan Reiner <span dir=3D"ltr">&lt;=
<a href=3D"mailto:etotheipi@gmail.com" target=3D"_blank">etotheipi@gmail.co=
m</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">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    This might be tangential, but the comment about &quot;refund&quot; chai=
ns
    reminded me.=A0 Armory will be implementing multi-sig/linked wallets
    where a each device has a parallel HDW branch and produces P2SH
    addresses.=A0 For those types of wallets, I plan to allocate two
    chains <i>per signing authority</i>.=A0 If you have a shared 2-of-2
    wallet split between your phone and your spouse&#39;s phone, your phone
    would distribute addresses on P2SH chain 0 and generate change
    addresses on P2SH chain 1.=A0 Your spouse&#39;s phone would use chains =
2
    and 3. <br>
    <br>
    So if you and your spouse switch to a new app that supports M-of-N
    linked wallets, it should search for coin history along the first
    2*N chains.</div></blockquote><div><br></div><div>In general with multi=
sig, we should probably discourage using a common root keychain for multipl=
e keys in the same P2SH address. =A0The reason is because if you have the s=
ingle, root private key, you can sign them all. This generally goes against=
 the point of multisig - which was trying to introduce a system which had m=
ultiple keys required to unlock :-)</div>
<div><br></div><div>For the BitGo BIP32 implementation we are doing the fol=
lowing:</div><div>=A0 =A0- users create 2 extended keys</div><div>=A0 =A0- =
bitgo creates 1 extended key for that user</div><div>=A0 =A0- the user can =
create any number of separate branches (accounts) of P2SH addresses from th=
ose extended keys.=A0</div>
<div>=A0 =A0- change/public addresses are generated from the 0/1 branches</=
div><div>=A0 =A0- new addresses are generated from there.</div><div>=A0 =A0=
- each time a new change address is generated, all 3 keys in the P2SH are r=
otated. =A0This makes it so that for any chain depth <i>i</i> of the P2SH a=
ddress, we&#39;re using the <i>i</i>th key in each keychain. =A0For privacy=
 reasons, we don&#39;t need to rotate all keys. =A0But I think it makes man=
agement simpler and probably more ready for interop.</div>
<div><br></div><div>So the paths in a user&#39;s keychain look exactly like=
 BIP32&#39;s layout:</div><div><font face=3D"courier new, monospace">=A0 =
=A0 =A0m/&lt;AccountIndex&gt;/&lt;ExternalOrInternal&gt;/&lt;AddressIndex&g=
t;</font></div>
<div><br></div><div>Another issue unique to P2SH addresses is order of the =
keys. There has been talk in this list of how to sort them. =A0While sortin=
g is simplifying for interop if you never use new change addresses, I belie=
ve sorting makes wallet management more difficult when BIP32 is introduced.=
</div>
<div><br></div><div>Specifically, imagine a P2SH address with keys held by =
Bob, Charlie, and Dana. =A0If you sort the pubkeys, then with each BIP32 ch=
ain, the order of the keys could be different. =A0By maintaining key order,=
 we always know which of the pubkeys belongs to which user without having t=
o do any lookups.</div>
<div><br></div><div>Obviously this can all be calculated too. =A0But the so=
rting seems gratuitous to me - it adds complexity but offers little value. =
=A0On the other hand, it can be really handy to know that key #0 for this a=
ddress is always Bob&#39;s key, regardless of how deep the chaining goes.</=
div>
<div><br></div><div>Mike<br></div><div><br></div><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D=
"HOEnZb"><font color=3D"#888888"><br>

    -Alan</font></span><div><div class=3D"h5"><br>
    <br>
    <br>
    <br>
    <div>On 03/26/2014 07:37 PM, Andreas
      Schildbach wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>Thanks for starting the discussion on finding a better structure=
.

For me, the most important thing is either we&#39;re 100% interoperable or
0%. There should not be anything inbetween, as users will delete seeds
without knowing there is still money in them on another implementation.
I heard from multiple sources that using this standard some wallets will
only see a subset of the addresses/keys of some other wallets.
Implementation differences can always happen (and should addresses as
bugs), but I think its unacceptable that this source of issues is by design=
.

I suggest we agree on an even simpler least common denominator and
wallets that want to implement some feature on top of that can do but
are encouraged to pick a totally different &quot;cointype&quot;. I guess th=
at
would mean removing reserved and account.

I&#39;m still thinking it might be a good idea to have a separate chain for
&quot;refunds&quot;. Refunds will be rarely used and thus need a much slowe=
r
moving window than receiving addresses or change.


On 03/26/2014 09:49 PM, Mike Hearn wrote:
</pre>
      <blockquote type=3D"cite">
        <pre>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&#39;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&#39;/account&#39;/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&#39;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 &quot;raw&quot; money and it =
will
    just ignore/not see the keys used in more complex transactions.

  * reserved is for &quot;other stuff&quot;. I actually don&#39;t recall wh=
y 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&#39;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&#39;t really encode how
keys are meant to be used into just an HDW hierarchy and normally you&#39;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&#39;m happy to just go with th=
e
flow on this one.



---------------------------------------------------------------------------=
---



_______________________________________________
Bitcoin-development mailing list
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a>

</pre>
      </blockquote>
      <pre>----------------------------------------------------------------=
--------------
_______________________________________________
Bitcoin-development mailing list
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@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>
<br></blockquote></div><br></div></div>

--001a11c159ac50fb8004f5908468--