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
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy.spilman@gmail.com>) id 1UTMuY-0007VR-2d
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Apr 2013 01:48:18 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.178 as permitted sender)
client-ip=209.85.220.178; envelope-from=jeremy.spilman@gmail.com;
helo=mail-vc0-f178.google.com;
Received: from mail-vc0-f178.google.com ([209.85.220.178])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UTMuX-0005tt-1x
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Apr 2013 01:48:18 +0000
Received: by mail-vc0-f178.google.com with SMTP id ib11so1363776vcb.9
for <bitcoin-development@lists.sourceforge.net>;
Fri, 19 Apr 2013 18:48:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.220.188.8 with SMTP id cy8mr13306156vcb.11.1366422491556;
Fri, 19 Apr 2013 18:48:11 -0700 (PDT)
Received: by 10.58.137.197 with HTTP; Fri, 19 Apr 2013 18:48:11 -0700 (PDT)
Date: Fri, 19 Apr 2013 18:48:11 -0700
Message-ID: <CA+CODZEQX_xiaJE7WtFZC2qfVfDqZAgg-ydU5Q73O-QTkXJpPw@mail.gmail.com>
From: Jeremy Spilman <jeremy.spilman@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7bfeb10a38f7d904dac10723
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
(jeremy.spilman[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: 1UTMuX-0005tt-1x
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
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, 20 Apr 2013 01:48:18 -0000
--047d7bfeb10a38f7d904dac10723
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
I=92m not sure I followed John=92s proposal fully, why would a user sign T=
X1
committing funds to the MULTISIG they may never get back? I also don=92t se=
e
the problem with getting a signed TX2 back from the AP before releasing
TX1... see the sequence below. But more importantly, we only need exactly
one replacement, so for starters we could anti-DoS by allowing only
nSequence of 0 or MAX.
If this was enabled on test-net, I would be including a link to
transactions that implement the following proposal. At the moment, the best
I can do is unit test and generate the rawtransaction output at each step =
=96
you can find source code and test output here:
https://gist.github.com/jspilman/5424310
The initial funding transaction and time-locked refund is pretty annoying
to setup, if you want to support the general case of coins from arbitrarily
sized inputs. You will have:
- 1 or more inputs from the user, 0 or 1 change outputs
- 0 or more inputs from the AP, 0 or 1 change outputs
- 1 output to =912 PK1 PK2 2 CHECKMULTISIG=92
This precludes using SIGHASH_SINGLE except for the special cases where
inputs are perfectly sized (i.e. they are created in a prior step).
0. User and AP negotiate how much to escrow, who pays the fees, and how
far in the future nLockTime will be set (how long user=92s funds will be ti=
ed
if AP doesn=92t close the channel)
1. User creates an unsigned TX1 with 1 or more inputs from user=92s
=91listunspent=92, change going back to user (if any), and a single output =
of
=91FundAmount=92 with scriptPubKey of =912 PK1 OP_0 CHECKMULTISIG=92, and s=
ends to
the AP
2. AP adds to TX1; their inputs (if any), their change (if any), replaces
OP_0 in the scriptPubKey with a PK they control, and signs SIGHASH_ALL, and
returns TX1 to User.
3. User verifies TX1 is as agreed, and signs it SIGHASH_ALL, but keeps it
to himself. User, having completed TX1, knows its TxID and can now create
TX2-Locked spending TX1 back to themselves. User sets nLockTime to the
agreed point, signs SIGHASH_ALL, and sends TX2-Locked to AP.
4. AP verifies TX2-Locked and adds their signature, and returns TX2-Locked
to User. User can now broadcast TX1 and TX2-Locked.
5. At each payment milestone, user creates TX2-Final; TX1 as input, final
nSequence, no lock time, with a single output going back to to the user,
and an amount equal to the remaining balance of the channel. User signs
with SIGHASH_SINGLE and sends to the AP.
6. AP can add an output to TX2-Final sending their portion of the coins
where ever they want, sign it SIGHASH_ALL, and broadcast it at any point,
closing the channel. AP must broadcast TX2-Final before nLockTime, but has
no guarantee the user hasn=92t offered a bribe for miners by spending
TX2-Locked with a large fee, e.g. a pissed off user spends TX2-Locked
entirely to fees just to see if they can convince miners to wait for it.
The alternative to the TX2-Locked is a 3rd party in the MULTISIG who is
trusted to close the channel at the request of either party, based on the
latest TX2-Final which was sent by the user. In this case there is no
TX2-Locked, only a single boardcast version of TX2-Final, and you do not
need transaction replacement at all.
Thanks,
--Jeremy
--047d7bfeb10a38f7d904dac10723
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-family:Calibri;color:rgb(0,0,0);font-si=
ze:12pt">
<div>I=92m not sure I followed John=92s proposal fully, why would a user si=
gn TX1=20
committing funds to the MULTISIG they may never get back? I also don=92t s=
ee the=20
problem with getting a signed TX2 back from the AP before releasing TX1... =
see=20
the sequence below. But more importantly, we only need exactly one replacem=
ent,=20
so for starters we could anti-DoS by allowing only nSequence of 0 or MAX.</=
div><div><br></div>
<div> </div>
<div>If this was enabled on test-net, I would be including a link to=20
transactions that implement the following proposal. At the moment, the bes=
t I=20
can do is unit test and generate the rawtransaction output at each step =96=
you=20
can find source code and test output here: <font face=3D"Times New Roman"><=
a href=3D"https://gist.github.com/jspilman/5424310">https://gist.github.com=
/jspilman/5424310</a></font></div><div><br></div>
<div> </div>
<div>The initial funding transaction and time-locked refund is pretty annoy=
ing=20
to setup, if you want to support the general case of coins from arbitrarily=
=20
sized inputs. You will have:</div>
<div> - 1 or more inputs from the user, 0 or 1 change outputs</div>
<div> - 0 or more inputs from the AP, 0 or 1 change outputs</div>
<div> - 1 output to =912 PK1 PK2 2 CHECKMULTISIG=92</div><div><br></div>
<div> </div>
<div>This precludes using SIGHASH_SINGLE except for the special cases where=
=20
inputs are perfectly sized (i.e. they are created in a prior step).</div><d=
iv><br></div>
<div> </div>
<div>0. User and AP negotiate how much to escrow, who pays the fees, and ho=
w far=20
in the future nLockTime will be set (how long user=92s funds will be tied i=
f AP=20
doesn=92t close the channel)</div><div><br></div>
<div> </div>
<div>1. User creates an unsigned TX1 with 1 or more inputs from user=92s=20
=91listunspent=92, change going back to user (if any), and a single output =
of=20
=91FundAmount=92 with scriptPubKey of =912 PK1 OP_0 CHECKMULTISIG=92, and s=
ends to the=20
AP</div><div><br></div>
<div> </div>
<div>2. AP adds to TX1; their inputs (if any), their change (if any), repla=
ces=20
OP_0 in the scriptPubKey with a PK they control, and signs SIGHASH_ALL, and=
=20
returns TX1 to User.</div><div><br></div>
<div> </div>
<div>3. User verifies TX1 is as agreed, and signs it SIGHASH_ALL, but keeps=
it=20
to himself. User, having completed TX1, knows its TxID and can now create=
=20
TX2-Locked spending TX1 back to themselves. User sets nLockTime to the agr=
eed=20
point, signs SIGHASH_ALL, and sends TX2-Locked to AP.</div><div><br></div>
<div> </div>
<div>4. AP verifies TX2-Locked and adds their signature, and returns TX2-Lo=
cked=20
to User. User can now broadcast TX1 and TX2-Locked.</div><div><br></div>
<div> </div>
<div>5. At each payment milestone, user creates TX2-Final; TX1 as input, fi=
nal=20
nSequence, no lock time, with a single output going back to to the user, an=
d an=20
amount equal to the remaining balance of the channel. User signs with=20
SIGHASH_SINGLE and sends to the AP.</div><div><br></div>
<div> </div>
<div>6. AP can add an output to TX2-Final sending their portion of the coin=
s=20
where ever they want, sign it SIGHASH_ALL, and broadcast it at any point,=
=20
closing the channel. AP must broadcast TX2-Final before nLockTime, but has=
no=20
guarantee the user hasn=92t offered a bribe for miners by spending TX2-Lock=
ed with=20
a large fee, e.g. a pissed off user spends TX2-Locked entirely to fees just=
to=20
see if they can convince miners to wait for it.</div><div><br></div>
<div> </div>
<div>The alternative to the TX2-Locked is a 3rd party in the MULTISIG who i=
s=20
trusted to close the channel at the request of either party, based on the l=
atest=20
TX2-Final which was sent by the user. In this case there is no TX2-Locked, =
only=20
a single boardcast version of TX2-Final, and you do not need transaction=20
replacement at all.</div><div><br></div>
<div> </div>
<div>Thanks,</div>
<div>--Jeremy</div></div></div>
--047d7bfeb10a38f7d904dac10723--
|
