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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1Z2Oag-0000WC-As
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Jun 2015 18:49:38 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.45 as permitted sender)
client-ip=209.85.215.45; envelope-from=gavinandresen@gmail.com;
helo=mail-la0-f45.google.com;
Received: from mail-la0-f45.google.com ([209.85.215.45])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z2Oaf-000350-Bg
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Jun 2015 18:49:38 +0000
Received: by laar3 with SMTP id r3so17845958laa.3
for <bitcoin-development@lists.sourceforge.net>;
Tue, 09 Jun 2015 11:49:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.147.201 with SMTP id tm9mr23911752lbb.40.1433874318619;
Tue, 09 Jun 2015 11:25:18 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Tue, 9 Jun 2015 11:25:18 -0700 (PDT)
In-Reply-To: <COL131-DS259B1E7F076282CE9BBF96CDBE0@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>
Date: Tue, 9 Jun 2015 14:25:18 -0400
Message-ID: <CABsx9T0TzRCr7DRzALymWiNJ2oA_MuZZQ8jFD+z4-cUaiSsE1A@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: "Raystonn ." <raystonn@hotmail.com>
Content-Type: multipart/alternative; boundary=047d7b34391a69fb6e051819e1f9
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
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1Z2Oaf-000350-Bg
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 18:49:38 -0000
--047d7b34391a69fb6e051819e1f9
Content-Type: text/plain; charset=UTF-8
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.
--
--
Gavin Andresen
--047d7b34391a69fb6e051819e1f9
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">On T=
ue, Jun 9, 2015 at 1:52 PM, Raystonn . <span dir=3D"ltr"><<a href=3D"mai=
lto:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-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>That does sound good on the surface, but how do we enforce #1 and #2?=
=C2=A0=20
They seem to be unenforceable, as a miner can adjust the size of the memory=
pool=20
in his local source.</div></div></div></div></blockquote><div><br></div><di=
v>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 net=
work will fail to prevent normal transaction traffic from going through and=
will just end up transferring some wealth to the miners.</div><div><br></d=
iv><div>Although the existing default mining policy (which it seems about 7=
0% of hashpower follows) of setting aside some space for high-priority tran=
sactions regardless of fee might also be enough to cause this attack to fai=
l in practice.</div></div><div><br></div>-- <br><div class=3D"gmail_signatu=
re">--<br>Gavin Andresen<br></div><div class=3D"gmail_signature"><br></div>
</div></div>
--047d7b34391a69fb6e051819e1f9--
|
