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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <manuelaraoz@gmail.com>) id 1We0uK-0002cl-ND
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 11:36:36 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.46 as permitted sender)
client-ip=209.85.216.46; envelope-from=manuelaraoz@gmail.com;
helo=mail-qa0-f46.google.com;
Received: from mail-qa0-f46.google.com ([209.85.216.46])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1We0uJ-0005lB-SP
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 11:36:36 +0000
Received: by mail-qa0-f46.google.com with SMTP id i13so4642708qae.33
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 Apr 2014 04:36:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.44.34 with SMTP id f31mr17670185qga.73.1398512190322;
Sat, 26 Apr 2014 04:36:30 -0700 (PDT)
Sender: manuelaraoz@gmail.com
Received: by 10.224.20.9 with HTTP; Sat, 26 Apr 2014 04:36:30 -0700 (PDT)
Received: by 10.224.20.9 with HTTP; Sat, 26 Apr 2014 04:36:30 -0700 (PDT)
In-Reply-To: <CANEZrP3EGNsOgHm0P6fiU1P7OSgTd=pBYooPBrLQGMKPT9b8Qg@mail.gmail.com>
References: <CABQSq2Q98K5zbUbQAqSE4OYez2QuOaWTt+9n5iZmSR2boynf_Q@mail.gmail.com>
<CANEZrP3EGNsOgHm0P6fiU1P7OSgTd=pBYooPBrLQGMKPT9b8Qg@mail.gmail.com>
Date: Sat, 26 Apr 2014 08:36:30 -0300
X-Google-Sender-Auth: etjpyh65IltMRgMPxl2poK7wGPw
Message-ID: <CABQSq2Sgb+JahuL+PTBa6y4OmupUVrg=TQqpQBVJDG96DSj1hA@mail.gmail.com>
From: Manuel Araoz <manu@bitpay.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a1139fdda51c2a804f7f07e57
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
(manuelaraoz[at]gmail.com)
-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: 1We0uJ-0005lB-SP
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 11:36:36 -0000
--001a1139fdda51c2a804f7f07e57
Content-Type: text/plain; charset=ISO-8859-1
On Apr 26, 2014 6:43 AM, "Mike Hearn" <mike@plan99.net> wrote:
>
> I'm not sure I understand why you need any special structure for this at
all. The way I'd do it is just use regular HD wallets for everyone, of the
regular form, and then swap the watching keys. Why do people need to be
given a cosigner index at all, given that they all have unique root keys
anyway?
I tried to explain that here:
The reason for using separate branches for each cosigner is we don't want
two of them generating the same address and receiving simultaneous payments
to it. The ideal case is that each address receives at most one payment,
requested by the corresponding cosigner.
To clarify, the problem the cosigner_index is trying to solve is race
conditions when receiving payments. Remember that we can't assume all
cosigners to be online at all times. 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. They then each
pass the same address to their payers, and we can get two payments to the
same address. Monitoring balances is not enough in this case because a
cosigner can never know when the others are generating a new address.
Separating branches and having each cosigner only use one branch makes this
problem go away.
--001a1139fdda51c2a804f7f07e57
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Apr 26, 2014 6:43 AM, "Mike Hearn" <<a href=3D"mailto:mike@=
plan99.net">mike@plan99.net</a>> wrote:<br>
><br>
> I'm not sure I understand why you need any special structure for t=
his at all. The way I'd do it is just use regular HD wallets for everyo=
ne, of the regular form, and then swap the watching keys. Why do people nee=
d to be given a cosigner index at all, given that they all have unique root=
keys anyway?</p>
<p dir=3D"ltr">I tried to explain that here:</p>
<p dir=3D"ltr">The reason for using separate branches for each cosigner is =
we don't want two of them generating the same address and receiving sim=
ultaneous payments to it. The ideal case is that each address receives at m=
ost one payment, requested by the corresponding cosigner.=A0</p>
<p dir=3D"ltr">To clarify, the problem the cosigner_index is trying to solv=
e is race conditions when receiving payments. Remember that we can't as=
sume all cosigners to be online at all times. Let's assume we use one s=
hared branch for everyone. Then two cosigners could need a new receiving ad=
dress at the same time, and get the next unused address on that branch. The=
y then each pass the same address to their payers, and we can get two payme=
nts to the same address. Monitoring balances is not enough in this case bec=
ause a cosigner can never know when the others are generating a new address=
. Separating branches and having each cosigner only use one branch makes th=
is problem go away.<br>
</p>
--001a1139fdda51c2a804f7f07e57--
|
