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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
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 <david.vorick@gmail.com>) id 1Z69mh-0006SR-2j
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 03:49:35 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.51 as permitted sender)
client-ip=209.85.218.51; envelope-from=david.vorick@gmail.com;
helo=mail-oi0-f51.google.com;
Received: from mail-oi0-f51.google.com ([209.85.218.51])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z69mf-0001N0-TW
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 03:49:35 +0000
Received: by oiyy130 with SMTP id y130so75244923oiy.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 19 Jun 2015 20:49:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.112.138 with SMTP id iq10mr6588571obb.38.1434772168468;
Fri, 19 Jun 2015 20:49:28 -0700 (PDT)
Received: by 10.202.97.131 with HTTP; Fri, 19 Jun 2015 20:49:28 -0700 (PDT)
In-Reply-To: <COL131-DS897EBDD5B5E7BD300318CCDBE0@phx.gbl>
References: <5574E39C.3090904@thinlink.com>
<COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
<CAJmQggBcAw1u+Pha+67S4bG5FuKx0xi_dTffmEOUHPbwyJU1aA@mail.gmail.com>
<CABsx9T3tuBZePfS4_LCo4rp3aU6HFtrLbSDR28DktJyLQz2L-A@mail.gmail.com>
<COL131-DS259B1E7F076282CE9BBF96CDBE0@phx.gbl>
<CABsx9T0TzRCr7DRzALymWiNJ2oA_MuZZQ8jFD+z4-cUaiSsE1A@mail.gmail.com>
<COL131-DS897EBDD5B5E7BD300318CCDBE0@phx.gbl>
Date: Fri, 19 Jun 2015 23:49:28 -0400
Message-ID: <CAFVRnyrDJCUo1VUsfK5mXZYMCc6iaWhho9-1ks0a-pE+1SGRng@mail.gmail.com>
From: David Vorick <david.vorick@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0149cd4e6f6d860518eaed0e
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
(david.vorick[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
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: 1Z69mf-0001N0-TW
Subject: Re: [Bitcoin-development] New attack identified and potential
solution described: Dropped-transaction spam attack against the block size
limit
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 Jun 2015 03:49:35 -0000
--089e0149cd4e6f6d860518eaed0e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I disagree that 11 is a reasonable value. That's less than 2 hours, which
probably wouldn't even last peak trading hours. You want the mempool to be
big enough that low-fee transactions introduced during peak hours are still
around when there's much less activity (it maximizes miner profit and
prevents people/wallets from needing to resubmit after activity has died
down).
I think you'd want something closer to 72. At 1mb or even 8mb blocks, the
memory requirements are pretty reasonable. 20mb blocks and you may have to
reconsider that limit.
On Tue, Jun 9, 2015 at 3:03 PM, Raystonn . <raystonn@hotmail.com> wrote:
> You are right of course. This will work. I like this idea more than
> my own proposed fix, as it doesn=E2=80=99t make any big changes to the ec=
onomics of
> the system in the way that burning would have.
>
> *From:* Gavin Andresen <gavinandresen@gmail.com>
> *Sent:* Tuesday, June 09, 2015 11:25 AM
> *To:* Raystonn . <raystonn@hotmail.com>
> *Cc:* Loi Luu <loi.luuthe@gmail.com> ; Bitcoin Dev
> <bitcoin-development@lists.sourceforge.net>
> *Subject:* Re: [Bitcoin-development] New attack identified and potential
> solution described: Dropped-transaction spam attack against the block siz=
e
> limit
>
> On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <raystonn@hotmail.com> wrote=
:
>
>> That does sound good on the surface, but how do we enforce #1 and #2?
>> They seem to be unenforceable, as a miner can adjust the size of the mem=
ory
>> pool in his local source.
>>
>
> It doesn't have to be enforced. As long as a reasonable percentage of has=
h
> rate is following that policy an attacker that tries to flood the network
> will fail to prevent normal transaction traffic from going through and wi=
ll
> just end up transferring some wealth to the miners.
>
> Although the existing default mining policy (which it seems about 70% of
> hashpower follows) of setting aside some space for high-priority
> transactions regardless of fee might also be enough to cause this attack =
to
> fail in practice.
>
> --
> --
> Gavin Andresen
>
>
>
> -------------------------------------------------------------------------=
-----
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e0149cd4e6f6d860518eaed0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I disagree that 11 is a reasonable value. That's =
less than 2 hours, which probably wouldn't even last peak trading hours=
. You want the mempool to be big enough that low-fee transactions introduce=
d during peak hours are still around when there's much less activity (i=
t maximizes miner profit and prevents people/wallets from needing to resubm=
it after activity has died down).<br><br></div>I think you'd want somet=
hing closer to 72. At 1mb or even 8mb blocks, the memory requirements are p=
retty reasonable. 20mb blocks and you may have to reconsider that limit.<br=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Ju=
n 9, 2015 at 3:03 PM, Raystonn . <span dir=3D"ltr"><<a href=3D"mailto:ra=
ystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div dir=3D"ltr">
<div style=3D"FONT-SIZE:10pt;FONT-FAMILY:'Arial';COLOR:#000000">
<div>You are right of course.=C2=A0 This will work.=C2=A0 I like this idea =
more=20
than my own proposed fix, as it doesn=E2=80=99t make any big changes to the=
economics of=20
the system in the way that burning would have.</div>
<div style=3D"FONT-SIZE:small;TEXT-DECORATION:none;FONT-FAMILY:"Calibr=
i";FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;DISPLAY:inline">
<div style=3D"FONT:10pt tahoma">
<div>=C2=A0</div>
<div style=3D"BACKGROUND:#f5f5f5">
<div><b>From:</b> <a title=3D"gavinandresen@gmail.com" href=3D"mailto:gavin=
andresen@gmail.com" target=3D"_blank">Gavin Andresen</a> </div>
<div><b>Sent:</b> Tuesday, June 09, 2015 11:25 AM</div>
<div><b>To:</b> <a title=3D"raystonn@hotmail.com" href=3D"mailto:raystonn@h=
otmail.com" target=3D"_blank">Raystonn .</a> </div>
<div><b>Cc:</b> <a title=3D"loi.luuthe@gmail.com" href=3D"mailto:loi.luuthe=
@gmail.com" target=3D"_blank">Loi Luu</a> ; <a title=3D"bitcoin-development=
@lists.sourceforge.net" href=3D"mailto:bitcoin-development@lists.sourceforg=
e.net" target=3D"_blank">Bitcoin Dev</a> </div><span class=3D"">
<div><b>Subject:</b> Re: [Bitcoin-development] New attack identified and=20
potential solution described: Dropped-transaction spam attack against the b=
lock=20
size limit</div></span></div></div>
<div>=C2=A0</div></div><div><div class=3D"h5">
<div style=3D"FONT-SIZE:small;TEXT-DECORATION:none;FONT-FAMILY:"Calibr=
i";FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;DISPLAY:inline">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <span=
dir=3D"ltr"><<a href=3D"mailto:raystonn@hotmail.com" target=3D"_blank">=
raystonn@hotmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT:1ex;MARGIN:0px 0px =
0px 0.8ex;BORDER-LEFT:#ccc 1px solid">
<div dir=3D"ltr">
<div dir=3D"ltr">
<div style=3D"FONT-SIZE:10pt;FONT-FAMILY:'Arial';COLOR:#000000">
<div>That does sound good on the surface, but how do we enforce #1 and=20
#2?=C2=A0 They seem to be unenforceable, as a miner can adjust the size o=
f the=20
memory pool in his local source.</div></div></div></div></blockquote>
<div>=C2=A0</div>
<div>It doesn't have to be enforced. As long as a reasonable percentage=
of hash=20
rate is following that policy an attacker that tries to flood the network w=
ill=20
fail to prevent normal transaction traffic from going through and will just=
end=20
up transferring some wealth to the miners.</div>
<div>=C2=A0</div>
<div>Although the existing default mining policy (which it seems about 70% =
of=20
hashpower follows) of setting aside some space for high-priority transactio=
ns=20
regardless of fee might also be enough to cause this attack to fail in=20
practice.</div></div>
<div>=C2=A0</div>-- <br>
<div>--<br>Gavin Andresen<br></div>
<div>=C2=A0</div></div></div></div></div></div></div></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div>
--089e0149cd4e6f6d860518eaed0e--
|
