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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <raystonn@hotmail.com>) id 1Z24N7-0006sJ-W9
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 21:14:18 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of hotmail.com
designates 65.55.34.204 as permitted sender)
client-ip=65.55.34.204; envelope-from=raystonn@hotmail.com;
helo=COL004-OMC4S2.hotmail.com;
Received: from col004-omc4s2.hotmail.com ([65.55.34.204])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z24N6-0006UQ-O9
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 21:14:17 +0000
Received: from COL131-DS27 ([65.55.34.200]) by COL004-OMC4S2.hotmail.com over
TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);
Mon, 8 Jun 2015 14:14:10 -0700
X-TMN: [wNs6OzddqYl/DUcnArJpl9R9IRivCbT2]
X-Originating-Email: [raystonn@hotmail.com]
Message-ID: <COL131-DS2729F02884BC43E54C8D63CDBF0@phx.gbl>
From: "Raystonn ." <raystonn@hotmail.com>
To: "Patrick Mccorry \(PGR\)" <patrick.mccorry@newcastle.ac.uk>
References: <5574E39C.3090904@thinlink.com>,
<COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
<AD4A025F-D782-4094-9CBC-EBEF0DD04838@newcastle.ac.uk>
In-Reply-To: <AD4A025F-D782-4094-9CBC-EBEF0DD04838@newcastle.ac.uk>
Date: Mon, 8 Jun 2015 14:14:01 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
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: 08 Jun 2015 21:14:10.0970 (UTC)
FILETIME=[10523FA0:01D0A230]
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.2 STOX_REPLY_TYPE STOX_REPLY_TYPE
-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.204 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
0.9 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z24N6-0006UQ-O9
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: Mon, 08 Jun 2015 21:14:18 -0000
> If I were a miner under this attack, I would just use the spam to fill up
> blocks alongside normal transactions maximising my profit.
You are assuming here that you can identify which transactions are spam, and
which are not, and then segregate the spam into a separate channels of
transactions for inclusion on a 50/50 basis alongside other transactions.
There is no guarantee you will be able to identify those transactions.
Sure, if you can do that, then the easy fix is just to put them into a lower
class channel of transactions that guarantee no pressure on the non-spam
transactions. But it's just not possible to do this in any meaningful way.
If you wanted to try, it would certainly add quite a bit of cost and
complexity on the miner's side, and you aren't going to get anything other
than the simple spam that comes from the same set of addresses.
> If I were to spam a lot of transactions to fill the memory pool it would
> cost $120 every 10 minutes
You need to account for the transactions coming from real users. Every real
transaction is approximately one less spam transaction you need to fill the
blocks.
> there is no memory pool cap currently
Real hardware does not have an infinite amount of RAM. Memory pool sizes
cannot grow unbounded. Some transactions with insufficient fees do get
dropped today after many hours.
-----Original Message-----
From: Patrick Mccorry (PGR)
Sent: Monday, June 08, 2015 1:28 PM
To: Raystonn .
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential
solution described: Dropped-transaction spam attack against the block size
limit
Please correct me if I'm wrong (hopefully understood it). I don't think
normal users would need to pay a higher fee - as miners can just ignore the
spam (since they will all be linked).
If I were to spam a lot of transactions to fill the memory pool it would
cost $120 every 10 minutes (assuming 4,000 tx can fit inside a block and 3
cents per transaction), anything exceeding that may be considered "spam" -
although I don't know if it would be "free" as the miner will eventually
claim all the fees, delayed payment is probably a better way to describe it.
IIRC, there is no memory pool cap currently. To spam 1 million transactions
would cost $30k which would take up approx 250 blocks (around 250mb) which
is around 42 hours to process. I think the memory pool can handle this data
today (someone more knowledgeable can check this for me) - so the attack is
v.expensive to carry out.
A good way to prevent this spamming the memory pool is to only accept up to
a 'x' length of 0-confirmed transactions to make it more difficult to pull
off (not impossible).
If I were a miner under this attack, I would just use the spam to fill up
blocks alongside normal transactions maximising my profit.
Sent from my iPhone
> On 8 Jun 2015, at 21:09, Raystonn . <raystonn@hotmail.com> wrote:
>
> When implemented, the block size limit was put in place to prevent the
> potential for a massive block to be used as an attack to benefit the miner
> of that block. The theory goes that such a massive block would enrich its
> miner by delaying other miners who are now busy downloading and validating
> that huge block. The original miner of that large-block would be free to
> continue hashing the next block, giving it an advantage.
>
> Unfortunately, this block size limit opened a different attack. Prior to
> the limit, any attempt to spam the network by anyone other than someone
> mining their own transactions would have been economically unfeasible. As
> every transaction would have a fee, there would have been a real cost for
> every minute of spam. The end result would have been a transfer of wealth
> from spammer to Bitcoin miners, which would have harmed the spammers and
> encouraged further mining of Bitcoin, a very antifragile outcome.
>
> But now we have the block size limit. Things are very different with this
> feature in place. The beginning of a spam attack on the Bitcoin network
> will incur transaction fees, just like before. But if spam continues at a
> rate exceeding the block size limit long enough for transactions to be
> dropped from mempools, the vast majority of spam transaction fees will
> never
> have to be paid. In fact, as real users gain in desperation and pay
> higher
> fees to get their transactions through in a timely manner, the spammers
> will
> adjust their fees to minimize the cost of the attack and maximize
> effectiveness. Using this method, they keep their fees at a point that
> causes most of the spam transactions to be dropped without confirmation
> (free spam), while forcing a floor for transaction fees. Thus, while spam
> could be used by attackers to disable the network entirely, by paying
> high-enough fees to actually fill the blocks with spam, it can also be
> used
> by a single entity to force a transaction fee floor. Real users will be
> forced to pay a transaction fee higher than the majority of the spam to
> get
> their transactions confirmed. So this is an effective means for a
> minority
> of miners to force higher fees through spam attacks, even in the face of
> benevolent miners who would not support a higher fee floor by policy.
> Miners would simply have no way to fix this, as they can only put in the
> transactions that will fit under the block size limit.
>
> In the face of such a spam attack, Bitcoin's credibility and usability
> would
> be severely undermined. The block size limit enables this attack, and I
> now
> argue for its removal. But we can't just remove it and ignore the problem
> that it was intended to address. We need a new fix for the large-block
> problem described in the first paragraph that does not suffer from the
> dropped-transaction spam-attack problem that is enabled by the block size
> limit today. My proposal is likely to be controversial, and I'm very much
> open to hearing other better proposals.
>
> Large blocks created by a miner as a means to spam other miners out of
> competition is a problem because miners do not pay fees for their own
> transactions when they mine them. They collect the fees they pay. This
> breaks the economic barrier keeping people from spamming the network, as
> the
> spamming is essentially free. The proposed fix is to add a new rule on
> how
> fees are handled. Some amount of every fee should be considered as burned
> and can never be spent. I will propose 50% of the fee here, but there may
> be better numbers that can be discovered prior to putting this into place.
> If we'd like miners to continue to collect the same fees after this
> change,
> we can suggest the default fee per transaction to be doubled. Half of
> every
> fee would be burned and disappear forever, effectively distributing the
> value of those bitcoins across the entire money supply. The other half
> would be collected by the miner of the block as is done today. This
> solution would mean large blocks would cost a significant number of
> bitcoin
> to create, even when all of the transactions are created by the miner of
> that block. For this to work, we'd need to ensure a minimum fee is paid
> for
> most of the transactions in every block, and the new transaction fee rule
> is
> in place. Then the block size limit can be removed.
>
> Raystonn
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
