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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1R4ANT-0008Us-HH
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 11:45:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R4ANS-0002uT-Bw
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 11:45:11 +0000
Received: by wwg14 with SMTP id 14so3184614wwg.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Sep 2011 04:45:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.198.12 with SMTP id u12mr983212wen.65.1316087104202; Thu,
15 Sep 2011 04:45:04 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.52.81 with HTTP; Thu, 15 Sep 2011 04:45:04 -0700 (PDT)
In-Reply-To: <CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com>
References: <CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com>
Date: Thu, 15 Sep 2011 13:45:04 +0200
X-Google-Sender-Auth: OH9fwVj3rFvb-L4g7cbV4ML61yA
Message-ID: <CANEZrP3FFEK0xrZqQkPyi8uoyb=XiPU7fSJDcGCLxiGH2uh3dQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=0016e6d7e6b456e74904acf968d7
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: 1R4ANS-0002uT-Bw
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Request review: drop misbehaving peers
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, 15 Sep 2011 11:45:11 -0000
--0016e6d7e6b456e74904acf968d7
Content-Type: text/plain; charset=UTF-8
Probabilistic disconnections could make it quite hard to debug protocol
implementations and increases the risk of flaky behaviour in the wild
significantly. I don't see why a simpler solution isn't better.
The most likely failure mode of this is not an attack but the same as
previous breakages - scaling or legitimate version skew that causes problems
as the network evolves.
Agree with Luke that non-standard transactions should not be considered an
attack.
If you stay with the scoring system I'd be tempted to have a flag (defaults
to 100) that sets a minimum threshold for the badness scores and ignores any
below that. Attacks based on sending transactions that aren't syntactically
valid don't seem likely to me, this isn't a good way to DoS somebody because
discarding them is so cheap. If it turns out later there is a problem,
people under attack could flip the flag until a new version is released.
The formula for the DoS score in the case of invalid signatures/merkle roots
seem unnecessarily elaborate. An invalid signature should never occur and
could always result in immediate disconnection.
Treating a block with too many sigops as invalid means legitimate relayers
might be treated as an attacker if/when the constant changes in future. I'd
suggest not treating this as an attacking situation at all.
Why use a mutable field with a const setter?
Unit tests that rely on sleeps like this can be flaky because the OS delay
isn't always precise, not to mention slow/irritating to run. It's better if
tests can override the clock, eg, if GetTime() did something like
if (nMockTime) { return nMockTime} else { ... }
then unit tests could reliably modify and advance the clock in a
fast/efficient manner.
--0016e6d7e6b456e74904acf968d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Probabilistic disconnections could make it quite hard to debug protocol imp=
lementations and increases the risk of flaky behaviour in the wild signific=
antly. I don't see why a simpler solution isn't better.<br><div>
<br></div><div>The most likely failure mode of this is not an attack but th=
e same as previous breakages - scaling or legitimate version skew that caus=
es problems as the network evolves.=C2=A0</div><div><br></div><div>Agree wi=
th Luke that non-standard transactions should not be considered an attack.<=
/div>
<div><br></div><div>If you stay with the scoring system I'd be tempted =
to have a flag (defaults to 100) that sets a minimum threshold for the badn=
ess scores and ignores any below that. Attacks based on sending transaction=
s that aren't syntactically valid don't seem likely to me, this isn=
't a good way to DoS somebody because discarding them is so cheap. If i=
t turns out later there is a problem, people under attack could flip the fl=
ag until a new version is released.</div>
<div><br></div><div>The formula for the DoS score in the case of invalid si=
gnatures/merkle roots seem unnecessarily elaborate. An invalid signature sh=
ould never occur and could always result in immediate disconnection.</div>
<div><br></div><div>Treating a block with too many sigops as invalid means =
legitimate relayers might be treated as an attacker if/when the constant ch=
anges in future. I'd suggest not treating this as an attacking situatio=
n at all.</div>
<div><br></div><div>Why use a mutable field with a const setter?</div><div>=
<br></div><div>Unit tests that rely on sleeps like this can be flaky becaus=
e the OS delay isn't always precise, not to mention slow/irritating to =
run. It's better if tests can override the clock, eg, if GetTime() did =
something like</div>
<div><br></div><div>=C2=A0 =C2=A0if (nMockTime) { return nMockTime} else { =
... }</div><div><br></div><div>then unit tests could reliably modify and ad=
vance the clock in a fast/efficient manner.</div>
--0016e6d7e6b456e74904acf968d7--
|
