blob: e38605cba50bdf1ab9501e050558889ed87ea72c (
plain)
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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <raystonn@hotmail.com>) id 1Z2579-00050D-N3
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 22:01:51 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.com
designates 65.55.34.152 as permitted sender)
client-ip=65.55.34.152; envelope-from=raystonn@hotmail.com;
helo=COL004-OMC3S14.hotmail.com;
Received: from col004-omc3s14.hotmail.com ([65.55.34.152])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z2578-0003hj-PF
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 22:01:51 +0000
Received: from COL131-DS5 ([65.55.34.137]) by COL004-OMC3S14.hotmail.com over
TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);
Mon, 8 Jun 2015 15:01:45 -0700
X-TMN: [84xHa1rK9p3PCqA/twvx2gyQ6CrKdol/]
X-Originating-Email: [raystonn@hotmail.com]
Message-ID: <COL131-DS52C1B18F4EFC4D7D7EEA1CDBF0@phx.gbl>
From: "Raystonn ." <raystonn@hotmail.com>
To: "Peter Todd" <pete@petertodd.org>
References: <5574E39C.3090904@thinlink.com>
<COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
<AD4A025F-D782-4094-9CBC-EBEF0DD04838@newcastle.ac.uk>
<COL131-DS2729F02884BC43E54C8D63CDBF0@phx.gbl>
<7E7DF414-6DDB-48A6-9199-D6883209B67D@newcastle.ac.uk>
<COL131-DS61BB9B5776DE65077ED0ACDBF0@phx.gbl>
<20150608214443.GC19826@muck>
In-Reply-To: <20150608214443.GC19826@muck>
Date: Mon, 8 Jun 2015 15:01:34 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: quoted-printable
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 22:01:45.0259 (UTC)
FILETIME=[B59C2FB0:01D0A236]
X-Spam-Score: -1.0 (-)
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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [65.55.34.152 listed in list.dnswl.org]
0.3 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z2578-0003hj-PF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
"Patrick Mccorry \(PGR\)" <patrick.mccorry@newcastle.ac.uk>
Subject: Re: [Bitcoin-development] New attack identified and potential
solution described: Dropped-transaction spam attack against
the blocksize 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 22:01:51 -0000
> There will always be a blocksize limit based on technological=20
> considerations - the network has a finite bandwidth limit.
A bandwidth limit is not the same as a blocksize limit. Bandwidth is uniqu=
e=20
to every individual. Miners in China have different bandwidth and=20
connectivity than miners in the U.S.=2C for example. But the block size li=
mit=20
is dictated for eveyone. They are not comparable.
> Without a blocksize limit the attacker would just flood the network until=
=20
> the bandwidth usage became so great that consensus would fail=2C renderin=
g=20
> Bitcoin both worthless=2C and insecure.
No=2C with no blocksize limit=2C a spammer would would flood the network wi=
th=20
transactions until they ran out of money. Meanwhile=2C everyone would jump=
on=20
board trying to mine the blocks to collect the fees from the spammers. It=
=20
could be one of the greatest transfers of wealth ever. Bitcoin=20
infrastructure would build up to handle the required bandwidth=2C paid for =
by=20
the very entity spamming the network. Bitcoin would flourish=2C growing=20
wildly as long as the fees kept coming. This is antifragility at its best.
> The worst an attacker flooding the network with transactions with a=20
> blocksize limit can do is raise costs=2C without harming security.
No=2C at attacker flooding the network with transactions with a blocksize=20
limit can keep their fees high enough that perhaps 1% of transactions comin=
g=20
from real end-users go through. At this point everyone would give up on=20
Bitcoin as it would become completely unusable. The BTCUSD market would=20
tank=2C making it even easier to pay the transaction fees to keep real=20
transactions out of blocks=2C as it would continue to become cheaper and=20
eventually cost-free to obtain the bitcoin fees through market purchase.
-----Original Message-----=20
From: Peter Todd
Sent: Monday=2C June 08=2C 2015 2:44 PM
To: Raystonn .
Cc: Patrick Mccorry (PGR) =3B Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential=20
solution described: Dropped-transaction spam attack against the blocksize=20
limit
On Mon=2C Jun 08=2C 2015 at 02:33:54PM -0700=2C Raystonn . wrote:
> > the attack would be expensive.
>
> For attacks being waged to destroy Bitcoin by filling all blocks with spa=
m=20
> transactions=2C the attack succeeds when the attacker is well funded. Th=
is=20
> gives well-funded private and/or public entities the means to destroy=20
> Bitcoin if they desire. This is only true after the block size limit was=
=20
> implemented. Without the block size limit=2C the spam doesn=E2=80=99t ha=
rm Bitcoin.=20
> It simply enriches miners at the cost of the spammers=2C which is a nicel=
y=20
> antifragile quality.
There will always be a blocksize limit based on technological=20
considerations - the network has a finite bandwidth limit.
Without a blocksize limit the attacker would just flood the network until=20
the bandwidth usage became so great that consensus would fail=2C rendering=
=20
Bitcoin both worthless=2C and insecure.
The worst an attacker flooding the network with transactions with a=20
blocksize limit can do is raise costs=2C without harming security. Keep in=
=20
mind=2C that at some point it'd be cheaper to just 51% attack the network.=
=20
Based on the current block subsidy of 25BTC/MB that's at the point where=20
transaction fees are 25mBTC/KB=2C which corresponds to <$2/tx fees - not th=
at=20
cheap=2C but still quite affordable for a large percentage of Bitcoin's use=
rs=20
right now. And that's the *absolute worst-case* attack possible.
|
