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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
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 1USlwU-0004oD-CH
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 10:19:50 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.46 as permitted sender)
client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f46.google.com;
Received: from mail-oa0-f46.google.com ([209.85.219.46])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1USlwT-0006q3-H1
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 10:19:50 +0000
Received: by mail-oa0-f46.google.com with SMTP id h2so2573069oag.19
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Apr 2013 03:19:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.60.136 with SMTP id h8mr5010760obr.47.1366280384109;
Thu, 18 Apr 2013 03:19:44 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Thu, 18 Apr 2013 03:19:43 -0700 (PDT)
In-Reply-To: <20130418100806.GA13908@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>
<20130418090444.GA30995@savin>
<CANEZrP0AYaWnVhrAbMXP0BGhb=CZMg_-PYVzwKbcCoRKC9V2rw@mail.gmail.com>
<20130418100806.GA13908@savin>
Date: Thu, 18 Apr 2013 12:19:43 +0200
X-Google-Sender-Auth: ePaEmuD66Z5qsNCfguHJTnFqHRw
Message-ID: <CANEZrP0T7y8jqhMDUsf-HNw1sJnVuXngMa3x5+O5qgRE6eswew@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c1c420f5667104da9ff00e
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: 1USlwT-0006q3-H1
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 10:19:50 -0000
--001a11c1c420f5667104da9ff00e
Content-Type: text/plain; charset=UTF-8
Indeed, as I mentioned in my first mail, nodes can be told how much
bandwidth they're allowed to use and then prioritize within that, so I
don't see any way convergence can fail. And regardless, I used 10mbit for
the calculations, that isn't exactly unlimited. My home internet connection
is better than that. It's just an arbitrary choice that lets us get a feel
for the numbers. We can see that even with a lot of replacements, an
attacker would have a hard time matching up his flood with when a block is
actually solved.
On the wider point - how many people DoS things with their own bandwidth?
The point of DNS reflection and/or botnets is you use other peoples
bandwidth. The attacks on Mt Gox are supposedly 80 gigabit+, which is
enough to take out all of the main network simultaneously. We can't do
anything about that. So I agree we should work to avoid opening up new DoS
attacks, but we should also be realistic about what can be accomplished.
The kind of people trying to manipulate Mt Gox could nuke the entire P2P
network off the face of the internet with the flick of a switch, presumably
the reason they aren't doing that it would to use Satoshi's phrasing
"undermine the validity of their own wealth".
> sure it's worth doing, at least immediately. Weakening the non-final ==
>
non-standard test to give a window of, say, 3 blocks, would be fine I
> think.
>
Sure. I think Gavin wants some kind of wider memory pool limiter policy
which would encompass such a thing already.
--001a11c1c420f5667104da9ff00e
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>Indeed, as I mentioned in my first mail, nodes can be told how much =
bandwidth they're allowed to use and then prioritize within that, so I =
don't see any way convergence can fail. And regardless, I used 10mbit f=
or the calculations, that isn't exactly unlimited. My home internet con=
nection is better than that. It's just an arbitrary choice that lets us=
get a feel for the numbers. We can see that even with a lot of replacement=
s, an attacker would have a hard time matching up his flood with when a blo=
ck is actually solved.</div>
<div><br></div><div style>On the wider point - how many people DoS things w=
ith their own bandwidth? The point of DNS reflection and/or botnets is you =
use other peoples bandwidth. The attacks on Mt Gox are supposedly 80 gigabi=
t+, which is enough to take out all of the main network simultaneously. We =
can't do anything about that. So I agree we should work to avoid openin=
g up new DoS attacks, but we should also be realistic about what can be acc=
omplished. The kind of people trying to manipulate Mt Gox could nuke the en=
tire P2P network off the face of the internet with the flick of a switch, p=
resumably the reason they aren't doing that it would to use Satoshi'=
;s phrasing "undermine the validity of their own wealth".</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">sure it's worth d=
oing, at least immediately. Weakening the non-final =3D=3D</span><br></div>=
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
non-standard test to give a window of, say, 3 blocks, would be fine I<br>
think.<br></blockquote><div><br></div><div style>Sure. I think Gavin wants =
some kind of wider memory pool limiter policy which would encompass such a =
thing already.</div></div></div></div>
--001a11c1c420f5667104da9ff00e--
|
