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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <raystonn@hotmail.com>) id 1Z2OoB-0004XD-9m
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Jun 2015 19:03:35 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.com
designates 65.55.34.92 as permitted sender)
client-ip=65.55.34.92; envelope-from=raystonn@hotmail.com;
helo=COL004-OMC2S18.hotmail.com;
Received: from col004-omc2s18.hotmail.com ([65.55.34.92])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z2OoA-0002qy-8A
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Jun 2015 19:03:35 +0000
Received: from COL131-DS8 ([65.55.34.72]) by COL004-OMC2S18.hotmail.com over
TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);
Tue, 9 Jun 2015 12:03:28 -0700
X-TMN: [Va8KGCNqVpnZQjA6SJG74zZ+oXg38yL5]
X-Originating-Email: [raystonn@hotmail.com]
Message-ID: <COL131-DS897EBDD5B5E7BD300318CCDBE0@phx.gbl>
From: "Raystonn ." <raystonn@hotmail.com>
To: "Gavin Andresen" <gavinandresen@gmail.com>
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>
In-Reply-To: <CABsx9T0TzRCr7DRzALymWiNJ2oA_MuZZQ8jFD+z4-cUaiSsE1A@mail.gmail.com>
Date: Tue, 9 Jun 2015 12:03:13 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_03E8_01D0A2AC.42FAED40"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
X-OriginalArrivalTime: 09 Jun 2015 19:03:28.0693 (UTC)
FILETIME=[F85F7E50:01D0A2E6]
X-Spam-Score: -0.0 (/)
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
(raystonn[at]hotmail.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [65.55.34.92 listed in list.dnswl.org]
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
1.0 FREEMAIL_REPLY From and body contain different freemails
-0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z2OoA-0002qy-8A
Cc: 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 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: Tue, 09 Jun 2015 19:03:35 -0000
------=_NextPart_000_03E8_01D0A2AC.42FAED40
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 =
economics of the system in the way that burning would have.
From: Gavin Andresen=20
Sent: Tuesday, June 09, 2015 11:25 AM
To: Raystonn .=20
Cc: Loi Luu ; Bitcoin Dev=20
Subject: Re: [Bitcoin-development] New attack identified and potential =
solution described: Dropped-transaction spam attack against the block =
size 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 =
memory pool in his local source.
It doesn't have to be enforced. As long as a reasonable percentage of =
hash rate is following that policy an attacker that tries to flood the =
network will fail to prevent normal transaction traffic from going =
through and will 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.
--=20
--
Gavin Andresen
------=_NextPart_000_03E8_01D0A2AC.42FAED40
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD>
<BODY dir=3Dltr>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<DIV>You are right of course. This will work. 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=20
style=3D'FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: =
"Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; =
DISPLAY: inline'>
<DIV style=3D"FONT: 10pt tahoma">
<DIV> </DIV>
<DIV style=3D"BACKGROUND: #f5f5f5">
<DIV style=3D"font-color: black"><B>From:</B> <A =
title=3Dgavinandresen@gmail.com=20
href=3D"mailto:gavinandresen@gmail.com">Gavin Andresen</A> </DIV>
<DIV><B>Sent:</B> Tuesday, June 09, 2015 11:25 AM</DIV>
<DIV><B>To:</B> <A title=3Draystonn@hotmail.com=20
href=3D"mailto:raystonn@hotmail.com">Raystonn .</A> </DIV>
<DIV><B>Cc:</B> <A title=3Dloi.luuthe@gmail.com=20
href=3D"mailto:loi.luuthe@gmail.com">Loi Luu</A> ; <A=20
title=3Dbitcoin-development@lists.sourceforge.net=20
href=3D"mailto:bitcoin-development@lists.sourceforge.net">Bitcoin =
Dev</A> </DIV>
<DIV><B>Subject:</B> Re: [Bitcoin-development] New attack identified and =
potential solution described: Dropped-transaction spam attack against =
the block=20
size limit</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV=20
style=3D'FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: =
"Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; =
DISPLAY: inline'>
<DIV dir=3Dltr>
<DIV class=3Dgmail_extra>
<DIV class=3Dgmail_quote>On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . =
<SPAN=20
dir=3Dltr><<A href=3D"mailto:raystonn@hotmail.com"=20
target=3D_blank>raystonn@hotmail.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
<DIV dir=3Dltr>
<DIV dir=3Dltr>
<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 =
#2? They seem to be unenforceable, as a miner can adjust the =
size of the=20
memory pool in his local source.</DIV></DIV></DIV></DIV></BLOCKQUOTE>
<DIV> </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 will=20
fail to prevent normal transaction traffic from going through and will =
just end=20
up transferring some wealth to the miners.</DIV>
<DIV> </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 =
transactions=20
regardless of fee might also be enough to cause this attack to fail in=20
practice.</DIV></DIV>
<DIV> </DIV>-- <BR>
<DIV class=3Dgmail_signature>--<BR>Gavin Andresen<BR></DIV>
<DIV=20
class=3Dgmail_signature> </DIV></DIV></DIV></DIV></DIV></DIV></BODY>=
</HTML>
------=_NextPart_000_03E8_01D0A2AC.42FAED40--
|
