Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.54 as permitted sender)
	client-ip=209.85.192.54; envelope-from=etotheipi@gmail.com;
	helo=mail-qg0-f54.google.com; 
Message-ID: <535C1EBB.5070402@gmail.com>
Date: Sat, 26 Apr 2014 17:01:47 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CABQSq2Q98K5zbUbQAqSE4OYez2QuOaWTt+9n5iZmSR2boynf_Q@mail.gmail.com>	<CANEZrP3EGNsOgHm0P6fiU1P7OSgTd=pBYooPBrLQGMKPT9b8Qg@mail.gmail.com>	<CABQSq2Sgb+JahuL+PTBa6y4OmupUVrg=TQqpQBVJDG96DSj1hA@mail.gmail.com>
	<CANEZrP2_TX8HMOkVRcucfrF7bDoQBTegDwZbRN4932UzZYZ3gg@mail.gmail.com>
In-Reply-To: <CANEZrP2_TX8HMOkVRcucfrF7bDoQBTegDwZbRN4932UzZYZ3gg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------050104090905060704030801"
Subject: Re: [Bitcoin-development] New BIP32 structure for P2SH multisig
	wallets
Precedence: list

This is a multi-part message in MIME format.
--------------050104090905060704030801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


On 04/26/2014 04:33 PM, Mike Hearn wrote:
>
>     Let's assume we use one shared branch for everyone. Then two
>     cosigners could need a new receiving address at the same time, and
>     get the next unused address on that branch.
>
> This is the part I struggle to understand. There is no shared branch
> because each user/cosigner has their own unique seed and thus unique
> key hierarchy, right? What you described above could be an issue if
> all co-signers shared the same seed but then the scheme wouldn't work.
>
Consider two people with phones, using 2-of-2,  using private seeds k1
and k2.  Every address generated by either party is:

2-of-2(K1/a'/b/c, K2/a'/b/c) 

So for any a, b and c you end up with a 2-of-2 address.  The
seeds/branches will not be used for single-sig receiving... it's always
a multisig 2-of-2.  In fact it behaves much like a regular wallet, you
give an a, b, and c value, and you get an address -- it's just that this
wallet always gives you a P2SH multisig address.

The problem is that if you follow BIP32 in the the most obvious way,
both devices will generate receiving addresses along the last index, 
i.e.   K/a'/b/0, K/a'/b/1, K/a'/b/2,...  If I am at one store and my
wife at another, we might both give out 2-of-2(K1/a'/b/382, K2/a'/b/382)
at the same time not realizing the other one has distributed that
address.  There's not a good way to coordinate the devices well enough
to avoid it.  But we don't have to.

The solution is to use two separate branches -- both phones will
follow/watch both branches, but each only only distributes payment
addresses from one such branch.

The original proposal here suggested adding a level to the tree using
the "cosigner index" as a branch point for doing this...  I recommended
simply having 2*N values for "b", so that each participant has a
receiving line and change line, that won't conflict with other devices. 
However, all devices will still watch all 2*N branches to know the total
balance of the wallet, and will use UTXOs from those branches when
constructing spending transactions/proposals.

--------------050104090905060704030801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 04/26/2014 04:33 PM, Mike Hearn
      wrote:<br>
    </div>
    <blockquote
cite="mid:CANEZrP2_TX8HMOkVRcucfrF7bDoQBTegDwZbRN4932UzZYZ3gg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <p dir="ltr">Let's assume we use one shared branch for
                everyone. Then two cosigners could need a new receiving
                address at the same time, and get the next unused
                address on that branch.</p>
            </blockquote>
            <div>This is the part I struggle to understand. There is no
              shared branch because each user/cosigner has their own
              unique seed and thus unique key hierarchy, right? What you
              described above could be an issue if all co-signers shared
              the same seed but then the scheme wouldn't work.</div>
          </div>
        </div>
      </div>
      <br>
    </blockquote>
    Consider two people with phones, using 2-of-2,&nbsp; using private seeds
    k1 and k2.&nbsp; Every address generated by either party is:<br>
    <br>
    2-of-2(K1/a'/b/c, K2/a'/b/c)&nbsp; <br>
    <br>
    So for any a, b and c you end up with a 2-of-2 address.&nbsp; The
    seeds/branches will not be used for single-sig receiving... it's
    always a multisig 2-of-2.&nbsp; In fact it behaves much like a regular
    wallet, you give an a, b, and c value, and you get an address --
    it's just that this wallet always gives you a P2SH multisig address.<br>
    <br>
    The problem is that if you follow BIP32 in the the most obvious way,
    both devices will generate receiving addresses along the last
    index,&nbsp; i.e.&nbsp;&nbsp; K/a'/b/0, K/a'/b/1, K/a'/b/2,...&nbsp; If I am at one
    store and my wife at another, we might both give out
    2-of-2(K1/a'/b/382, K2/a'/b/382) at the same time not realizing the
    other one has distributed that address.&nbsp; There's not a good way to
    coordinate the devices well enough to avoid it.&nbsp; But we don't have
    to.<br>
    <br>
    The solution is to use two separate branches -- both phones will
    follow/watch both branches, but each only only distributes payment
    addresses from one such branch.<br>
    <br>
    The original proposal here suggested adding a level to the tree
    using the "cosigner index" as a branch point for doing this...&nbsp; I
    recommended simply having 2*N values for "b", so that each
    participant has a receiving line and change line, that won't
    conflict with other devices.&nbsp; However, all devices will still watch
    all 2*N branches to know the total balance of the wallet, and will
    use UTXOs from those branches when constructing spending
    transactions/proposals.<br>
  </body>
</html>

--------------050104090905060704030801--