From: Alan Reiner <etotheipi@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets
Date: Sat, 26 Apr 2014 17:01:47 -0400 [thread overview]
Message-ID: <535C1EBB.5070402@gmail.com> (raw)
In-Reply-To: <CANEZrP2_TX8HMOkVRcucfrF7bDoQBTegDwZbRN4932UzZYZ3gg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3122 bytes --]
next prev parent reply other threads:[~2014-04-26 21:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 22:27 Manuel Araoz
2014-04-26 3:02 ` Alan Reiner
2014-04-26 9:43 ` Mike Hearn
2014-04-26 10:08 ` Thomas Voegtlin
2014-04-28 1:37 ` Jeff Garzik
2014-04-26 11:36 ` Manuel Araoz
2014-04-26 20:33 ` Mike Hearn
2014-04-26 21:01 ` Alan Reiner [this message]
2014-04-26 21:57 ` Mike Hearn
2015-10-03 12:42 ` [bitcoin-dev] [Bitcoin-development] New BIP32 structure for P2SH multisig wallets [BIP-45] Jean-Pierre Rupp
2015-10-04 15:18 ` Jean-Pierre Rupp
2015-10-04 17:24 ` Thomas Kerin
2015-10-05 6:57 ` Matias Alejo Garcia
2015-10-05 12:18 ` Jean-Pierre Rupp
2015-10-05 12:32 ` Jonas Schnelli
2015-10-05 19:36 ` Jean-Pierre Rupp
2015-10-05 18:04 ` Matias Alejo Garcia
2015-10-05 11:43 ` Jean-Pierre Rupp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=535C1EBB.5070402@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox