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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1USkm6-0005Xi-Pl
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 09:05:02 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.110 as permitted sender)
client-ip=62.13.148.110; envelope-from=pete@petertodd.org;
helo=outmail148110.authsmtp.com;
Received: from outmail148110.authsmtp.com ([62.13.148.110])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1USkm4-0007MX-P8 for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 09:05:02 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r3I94rQt007520; Thu, 18 Apr 2013 10:04:53 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r3I94iNm040107
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 18 Apr 2013 10:04:47 +0100 (BST)
Date: Thu, 18 Apr 2013 05:04:44 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130418090444.GA30995@savin>
References: <CANEZrP1yKeQMayFHsEUWtA3=q+v5rPAutjzEFVVHopPGNZ4jGQ@mail.gmail.com>
<453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com>
<CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com>
<CAPaL=UVJd3mdd0bs6Oo9vFHnv_6RbFowjmp0tD-ZbOzZxJEJ3g@mail.gmail.com>
<CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o"
Content-Disposition: inline
In-Reply-To: <CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 05918ffe-a807-11e2-b5c5-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwoUGUUGAgsB AmUbWlReUFl7XWs7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqAmUI AkdgDxl2dwRGfzBy ZE5kXj5bWU17fRAr
F1MFHW0BeGZhPWIC AkULch5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4iGCI9 DzwFJn0hGldNWzV7
NRE+LlcXEUMcNFla
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1USkm4-0007MX-P8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Thu, 18 Apr 2013 09:05:03 -0000
--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Apr 18, 2013 at 10:32:24AM +0200, Mike Hearn wrote:
> RE: shutting down services dependent on replacement. No, good users of
> replacement would still end up taking priority over the constantly churni=
ng
> DoS replacements. The most you can shut down is one contract. Obviously, =
if
> there's no form of tx replacement at all then the "tried and doesn't work"
> state is the same as "never tried", which doesn't seem like a win.
Yeah, an attack is a bit more subtle than perhaps John Dillon realizes.
Assuming that nodes prioritize the transactions with the fewest total
replacements first it becomes a multiplier on the standard attack of
just broadcasting transactions. So for non-replacement users it's
probably not that bad.
An attack still shuts down useful tx replacement though. For instance in
the adjusting payments example an attacker sets up a legit adjusting
payment channel, does a bunch of adjustments, and then launches their
attack. They broadcast enough adjustments that their adjustment session
looks like part of an attack, and then don't have to pay for the full
adjusted amount.
What's worse, the attack itself can be just a large number of these
micropayment sessions, IE, no bogus sessions at all.
> The testnet is trivially DoSable today by anyone who cares to do so, there
> are hardly any nodes and most people get coins from the faucet. Look at h=
ow
It's *easily* DoSable, not trivially. Testnet has all the same
fee/priority rules that Bitcoin has, so any attack still costs some
amount of coins. For instance I did the math once on what it would cost
to flood testnet with 1MB blocks, and it came out to IIRC $100/month or
so in terms of lost mining revenue. Small, but still not trivial.
non-final nLockTime floods and timewarp assisted can be easily done mind
you, but the former is easy to fix and the latter is relatively tricky
to pull off and still requires some mining expenditure.
> Your proposed alternative doesn't seem any different DoS wise. Someone can
> still broadcast a long series of incrementally different transactions and
> have miners replace them. So you still need prioritisation of work. It's
> useful anyway for other reasons. And as you point out yourself, it's still
> susceptible to the problem that you end up running out of money because
> it's all been spent on fees.
John's proposing something that would work in conjunction with fees, so
it's no different than the MIN_RELAY_FEE that has quite successfully
prevented flooding on mainnet. For that matter, what he proposed can be
used even with non-final =3D=3D non-standard, which means the replacement
transactions can't be broadcast onto the network at all until they can
be mined.
Actually, that's an interesting point: one way to do replacement
anti-DoS would be to only allow each input a given number of chances to
do a replacement. Provided your design is asymmetric in who the attacker
would be, and the inputs controlled by the defender outnumber the
attacker, the defender can always count on doing the last replacement.
You would need some way of determining which input was responsible for a
replacement though - I can't think of an obvious way to within the
current transaction format, but I haven't thought hard about it yet.
How exactly do you envision replacement working with non-final =3D=3D
non-standard anyway?
> BTW $500 is rather low for the amount of work required. If you added a ze=
ro
> onto that there might be more takers.
If he's reasonable about the scope, IE just a initial implementation for
further evaluation, I figure it's about two days work. $250/day is
enough that I'd give it a go - I already looked into how to implement it
anyway.
--=20
'peter'[:-1]@petertodd.org
--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRb7crAAoJEH+rEUJn5PoEPegH/Atzltgd5shwlTjc3FMR99BY
oN1k5j89fHI0EYYQpYGeMBFEW3FXZ4X4BSPhoR/juf+nUj69567m7d5XbJm+U96Z
S97jIjk/sqMh5/MQXu1GC0MdfVKOCRXT1GG65pfeKNMUminFKwHCB+QUw5NuXhaO
2i+DHZRSO3o2hqiC75tUfANe8gE/RGr/0fRBZA1vZsdqz4KHTh5po1qqWWtOwSpo
9n18+Hghx7qlDdp627Qs0pwEXjyBuQTpukjpVTBAIy82hT9Yh0fLC5NFMSxx6nsb
mnGCTNf+ow/hU83BXSnNP+GEmpJdmdy0/WtaafESf8rKMIIRTL9GrFXq07ktlM4=
=i+kQ
-----END PGP SIGNATURE-----
--IS0zKkzwUGydFO0o--
|
