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
|
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 <tier.nolan@gmail.com>) id 1Z2KMZ-0002Wv-7m
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Jun 2015 14:18:47 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.45 as permitted sender)
client-ip=209.85.192.45; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f45.google.com;
Received: from mail-qg0-f45.google.com ([209.85.192.45])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z2KMX-0003kV-Gv
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Jun 2015 14:18:47 +0000
Received: by qgfa66 with SMTP id a66so6043486qgf.0
for <bitcoin-development@lists.sourceforge.net>;
Tue, 09 Jun 2015 07:18:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.132.17 with SMTP id 17mr27928471qhe.36.1433859520120;
Tue, 09 Jun 2015 07:18:40 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Tue, 9 Jun 2015 07:18:40 -0700 (PDT)
In-Reply-To: <CABsx9T3tuBZePfS4_LCo4rp3aU6HFtrLbSDR28DktJyLQz2L-A@mail.gmail.com>
References: <5574E39C.3090904@thinlink.com>
<COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
<CAJmQggBcAw1u+Pha+67S4bG5FuKx0xi_dTffmEOUHPbwyJU1aA@mail.gmail.com>
<CABsx9T3tuBZePfS4_LCo4rp3aU6HFtrLbSDR28DktJyLQz2L-A@mail.gmail.com>
Date: Tue, 9 Jun 2015 15:18:40 +0100
Message-ID: <CAE-z3OXfoAM-xgikzEUz=uYqgJBMr1x5_npU6Q-SBgw6gJ4jHA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c07c725adc600518166f4e
X-Spam-Score: 3.3 (+++)
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
(tier.nolan[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
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1Z2KMX-0003kV-Gv
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 14:18:47 -0000
--001a11c07c725adc600518166f4e
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:
> How about this for mitigating this potential attack:
>
> 1. Limit the memory pool to some reasonable number of blocks-worth of
> transactions (e.g. 11)
> 2. If evicting transactions from the memory pool, prefer to evict
> transactions that are part of long chains of unconfirmed transactions.
> 3. Allow blocks to grow in size in times of high transaction demand.
>
>
I think 2 should just be fee per kB. If the pool is full and a transaction
arrives, it has to have a fee per kB that is higher than the lowest
transaction in the pool.
The effect is that the fee per kB threshold for getting a transaction into
the memory pool increases as the attack proceeds. This means that the cost
to maintain the attack increases.
With replace by fee, the new transaction would have to have a fee that is
more than a fixed amount more than the lowest already in the pool. I think
the replace by fee code already does this. This prevents transactions with
fees that increase by 1 Satoshi at a time being relayed.
For allowing large blocks when block space is in high demand, you could
limit the average block size.
If the average was set to 1MB, the rule could be that blocks must be 2MB or
lower and the total size of the a block and the previous 99 must be 100MB
or lower. This gives an average of 1MB per block, but allows bursts.
--001a11c07c725adc600518166f4e
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 2:36 PM, Gavin Andresen <span dir=3D"ltr"><<a href=3D=
"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com<=
/a>></span> 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">Ho=
w about this for mitigating this potential attack:<div><br></div><div>1. Li=
mit the memory pool to some reasonable number of blocks-worth of transactio=
ns (e.g. 11)</div><div>2. If evicting transactions from the memory pool, pr=
efer to evict transactions that are part of long chains of unconfirmed tran=
sactions.</div><div>3. Allow blocks to grow in size in times of high transa=
ction demand.</div><div><br></div></div></blockquote><div><br></div><div>I =
think 2 should just be fee per kB.=C2=A0 If the pool is full and a transact=
ion arrives, it has to have a fee per kB that is higher than the lowest tra=
nsaction in the pool.<br><br></div><div>The effect is that the fee per kB t=
hreshold for getting a transaction into the memory pool increases as the at=
tack proceeds.=C2=A0 This means that the cost to maintain the attack increa=
ses.<br></div><br></div><div class=3D"gmail_quote"></div><div class=3D"gmai=
l_quote">With replace by fee, the new transaction would have to have a fee =
that is more than a fixed amount more than the lowest already in the pool.=
=C2=A0 I think the replace by fee code already does this.=C2=A0 This preven=
ts transactions with fees that increase by 1 Satoshi at a time being relaye=
d.<br><br></div><div class=3D"gmail_quote">For allowing large blocks when b=
lock space is in high demand, you could limit the average block size.<br><b=
r></div><div class=3D"gmail_quote">If the average was set to 1MB, the rule =
could be that blocks must be 2MB or lower and the total size of the a block=
and the previous 99 must be 100MB or lower.=C2=A0 This gives an average of=
1MB per block, but allows bursts.<br></div></div></div>
--001a11c07c725adc600518166f4e--
|
