1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1We9jO-0000LG-L4
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 21:01:54 +0000
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;
Received: from mail-qg0-f54.google.com ([209.85.192.54])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1We9jN-0006AZ-Nt
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 21:01:54 +0000
Received: by mail-qg0-f54.google.com with SMTP id q107so4796678qgd.13
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 Apr 2014 14:01:48 -0700 (PDT)
X-Received: by 10.229.58.68 with SMTP id f4mr21931748qch.18.1398546108275;
Sat, 26 Apr 2014 14:01:48 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126]) by mx.google.com with ESMTPSA id
n105sm15128265qgd.7.2014.04.26.14.01.47
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 26 Apr 2014 14:01:47 -0700 (PDT)
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>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative;
boundary="------------050104090905060704030801"
X-Spam-Score: -0.6 (/)
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
(etotheipi[at]gmail.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.54 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1We9jN-0006AZ-Nt
Subject: Re: [Bitcoin-development] New BIP32 structure for P2SH multisig
wallets
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: Sat, 26 Apr 2014 21:01:54 -0000
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, using private seeds
k1 and k2. Every address generated by either party is:<br>
<br>
2-of-2(K1/a'/b/c, K2/a'/b/c) <br>
<br>
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.<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, 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.<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... 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.<br>
</body>
</html>
--------------050104090905060704030801--
|
