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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy.spilman@gmail.com>) id 1UTeky-0002dL-Ev
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Apr 2013 20:51:36 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.48 as permitted sender)
client-ip=209.85.212.48; envelope-from=jeremy.spilman@gmail.com;
helo=mail-vb0-f48.google.com;
Received: from mail-vb0-f48.google.com ([209.85.212.48])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UTeks-0000Dz-Vt
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Apr 2013 20:51:36 +0000
Received: by mail-vb0-f48.google.com with SMTP id p13so4743191vbe.35
for <bitcoin-development@lists.sourceforge.net>;
Sat, 20 Apr 2013 13:51:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.58.187.42 with SMTP id fp10mr15058501vec.46.1366491083313;
Sat, 20 Apr 2013 13:51:23 -0700 (PDT)
Received: by 10.58.137.197 with HTTP; Sat, 20 Apr 2013 13:51:23 -0700 (PDT)
Date: Sat, 20 Apr 2013 13:51:23 -0700
Message-ID: <CA+CODZF_kVoKcPjPgpfnEH4PBFfLJqS7SuvsRG_DRJroo3gcLA@mail.gmail.com>
From: Jeremy Spilman <jeremy.spilman@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7b6dccb09c19a204dad0ff97
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: 1UTeks-0000Dz-Vt
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 20:51:36 -0000
--047d7b6dccb09c19a204dad0ff97
Content-Type: text/plain; charset=ISO-8859-1
I was discussing this with petertodd a couple days ago and we were thinking
the sequence I sent yesterday was usable today. I tried getting it to work
on test-net but the final transaction closing the channel was not being
accepted into the mempool beacause "ERROR: CTxMemPool::accept() : inputs
already spent"
But I was talking with sipa and gmaxwell on IRC about it, and sipa reminded
me; Test-Net implements IsStandard() to allow the non-final "refund" TX
into the mempool, but then doesn't allow it to be replaced, Main-Net
implements IsStandard() to *reject* non-final transactions in the first
place.
Therefore, this actually will work on Main-Net today, since the refund TX
won't even be allowed into the mempool until it's final, the AP is free to
sign and broadcast its final TX without any replacement. Of course, if the
AP waits too long, the user can get their Refund into the mempool and the
AP's [higher seq] version will be locked out.
This may be a case where Test-Net is in a "bad" state, by allowing
non-final TXs into the pool, but not allowing replacement, you get an
intermediate state which neither matches Main-Net behavior, nor implements
behavior which would ever be deployed to Main-Net as-is.
The current Main-Net behavior is actually very well suited for this
application. Any application that can be reduced to two instances of a Tx,
namely one non-final, and one final which is updated internally between the
parties, works very well under the current Main-Net rules.
If you set the nLockTime of the refund to be several days after the
scheduled closing time of the channel, it would be quite challenging to get
the Refund TX into the blockchain *despite* a final broadcast TX from the
AP. Since the vast majority of Main-Net won't even accept it, the attacker
would have to distribute the TX to any miner who could include the AP's
transaction in a block between now and when the refund becomes final, and
convince them all to not include the perfectly valid, fees paid, final,
nSeq=MAX, nLockTime=0 transaction from the AP. Demonstrating that level of
coordination would act substantially against the best interests of the
miners, to say the least.
This proposal still suffers from any malleability weakness, where the
user's refund could be invalidated by a miner changing the TxID of TX1.
--047d7b6dccb09c19a204dad0ff97
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra" style>I was discussing this wit=
h petertodd a couple days ago and we were thinking the sequence I sent yest=
erday was usable today. =A0I tried getting it to work on test-net but the f=
inal transaction closing the channel was not being accepted into the mempoo=
l beacause "ERROR: CTxMemPool::accept() : inputs already spent"</=
div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>But I was talking with sipa and gmaxwell on IRC about it, and sipa reminde=
d me; Test-Net implements IsStandard() to allow the non-final "refund&=
quot; TX into the mempool, but then doesn't allow it to be replaced, Ma=
in-Net implements IsStandard() to *reject* non-final transactions in the fi=
rst place.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>Therefore, this actually will work on Main-Net today, since the refund TX =
won't even be allowed into the mempool until it's final, the AP is =
free to sign and broadcast its final TX without any replacement. Of course,=
if the AP waits too long, the user can get their Refund into the mempool a=
nd the AP's [higher seq] version will be locked out.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>This may be a case where Test-Net is in a "bad" state, by allowi=
ng non-final TXs into the pool, but not allowing replacement, you get an in=
termediate state which neither matches Main-Net behavior, nor implements be=
havior which would ever be deployed to Main-Net as-is.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>The current Main-Net behavior is actually very well suited for this applic=
ation. Any application that can be reduced to two instances of a Tx, namely=
one non-final, and one final which is updated internally between the parti=
es, works very well under the current Main-Net rules.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>If you set the nLockTime of the refund to be several days after the schedu=
led closing time of the channel, it would be quite challenging to get the R=
efund TX into the blockchain *despite* a final broadcast TX from the AP. Si=
nce the vast majority of Main-Net won't even accept it, the attacker wo=
uld have to distribute the TX to any miner who could include the AP's t=
ransaction in a block between now and when the refund becomes final, and co=
nvince them all to not include the perfectly valid, fees paid, final, nSeq=
=3DMAX, nLockTime=3D0 transaction from the AP. Demonstrating that level of =
coordination would act substantially against the best interests of the mine=
rs, to say the least.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>This proposal still suffers from any malleability weakness, where the user=
's refund could be invalidated by a miner changing the TxID of TX1.</di=
v>
</div>
--047d7b6dccb09c19a204dad0ff97--
|
