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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1USkGd-00043v-PB
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 08:32:31 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.170 as permitted sender)
client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f170.google.com;
Received: from mail-ob0-f170.google.com ([209.85.214.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1USkGc-00081Z-4W
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 08:32:31 +0000
Received: by mail-ob0-f170.google.com with SMTP id eh20so1140401obb.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Apr 2013 01:32:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.28.37 with SMTP id y5mr5028978oeg.134.1366273944753; Thu,
18 Apr 2013 01:32:24 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Thu, 18 Apr 2013 01:32:24 -0700 (PDT)
In-Reply-To: <CAPaL=UVJd3mdd0bs6Oo9vFHnv_6RbFowjmp0tD-ZbOzZxJEJ3g@mail.gmail.com>
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>
Date: Thu, 18 Apr 2013 10:32:24 +0200
X-Google-Sender-Auth: T7u6Y_WpcHtiFqtXSaqGJKKr7Ac
Message-ID: <CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: John Dillon <john.dillon892@googlemail.com>
Content-Type: multipart/alternative; boundary=e89a8fb1f7f024a54204da9e71a2
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1USkGc-00081Z-4W
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 08:32:31 -0000
--e89a8fb1f7f024a54204da9e71a2
Content-Type: text/plain; charset=UTF-8
When did I say DoS was unimportant? I just wrote a giant email explaining
how it can be resolved.
I think it's worth pointing out that Bitcoin was launched with no DoS
protection at all, and it's still here. There are still obvious DoS bugs
being fixed with every release. So yes, it's important to robustify the
code, but not to the extent of not having any features. If Satoshi had
taken that perspective Bitcoin might not exist at all. We can have our cake
and eat it.
RE: shutting down services dependent on replacement. No, good users of
replacement would still end up taking priority over the constantly churning
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.
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 how
quickly people got upset when somebody drained it. As Jeff has pointed out,
there could theoretically be a "nextnet" but the overhead of setting one up
doesn't seem worth it. If somebody wanted to troll developers they could
easily DoS testnet and nextnet simultaneously with bandwidth to spare.
> That #3 has not been noticed before shows that for all this hot air
> no-one has ever bothered making an implementation of the idea.
>
Yes, I noticed it a few days ago when making some notes, but figured I
would indeed make an prototype implementation and then just put all the
details and latest protocols on the wiki at once. As nobody indeed noticed
the bug for years apparently nobody else is working on this so it didn't
seem urgent to update.
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.
BTW $500 is rather low for the amount of work required. If you added a zero
onto that there might be more takers.
--e89a8fb1f7f024a54204da9e71a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
style>When did I say DoS was unimportant? I just wrote a giant email expla=
ining how it can be resolved.</div><div style><br></div><div style>I think =
it's worth pointing out that Bitcoin was launched with no DoS protectio=
n at all, and it's still here. There are still obvious DoS bugs being f=
ixed with every release. So yes, it's important to robustify the code, =
but not to the extent of not having any features. If Satoshi had taken that=
perspective Bitcoin might not exist at all. We can have our cake and eat i=
t.</div>
<div style><br></div><div style>RE: shutting down services dependent on rep=
lacement. No, good users of replacement would still end up taking priority =
over the constantly churning DoS replacements. The most you can shut down i=
s 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.</div>
<div style><br></div><div style>The testnet is trivially DoSable today by a=
nyone who cares to do so, there are hardly any nodes and most people get co=
ins from the faucet. Look at how quickly people got upset when somebody dra=
ined it. As Jeff has pointed out, there could theoretically be a "next=
net" but the overhead of setting one up doesn't seem worth it. If =
somebody wanted to troll developers they could easily DoS testnet and nextn=
et simultaneously with bandwidth to spare.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
That #3 has not been noticed before shows that for all this hot air<br>
no-one has ever bothered making an implementation of the idea. <br></blockq=
uote><div><br></div><div style>Yes, I noticed it a few days ago when making=
some notes, but figured I would indeed make an prototype implementation an=
d then just put all the details and latest protocols on the wiki at once. A=
s nobody indeed noticed the bug for years apparently nobody else is working=
on this so it didn't seem urgent to update.</div>
<div style><br></div><div style>Your proposed alternative doesn't seem =
any different DoS wise. Someone can still broadcast a long series of increm=
entally different transactions and have miners replace them. So you still n=
eed prioritisation of work. It's useful anyway for other reasons. And a=
s you point out yourself, it's still susceptible to the problem that yo=
u end up running out of money because it's all been spent on fees.=C2=
=A0</div>
<div style><br></div><div style>BTW $500 is rather low for the amount of wo=
rk required. If you added a zero onto that there might be more takers.</div=
></div></div></div>
--e89a8fb1f7f024a54204da9e71a2--
|
