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
|
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 <pete@petertodd.org>) id 1Z25Np-0005f7-TV
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 22:19:05 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.154 as permitted sender)
client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
helo=outmail148154.authsmtp.co.uk;
Received: from outmail148154.authsmtp.co.uk ([62.13.148.154])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z25No-0004FN-DM for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 22:19:05 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t58MIufZ051033;
Mon, 8 Jun 2015 23:18:56 +0100 (BST)
Received: from muck (bas3-cooksville17-1176329630.dsl.bell.ca [70.29.93.158])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t58MIox1007838
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 8 Jun 2015 23:18:53 +0100 (BST)
Date: Mon, 8 Jun 2015 18:18:43 -0400
From: Peter Todd <pete@petertodd.org>
To: "Raystonn ." <raystonn@hotmail.com>
Message-ID: <20150608221843.GA4275@muck>
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>
<COL131-DS52C1B18F4EFC4D7D7EEA1CDBF0@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q"
Content-Disposition: inline
In-Reply-To: <COL131-DS52C1B18F4EFC4D7D7EEA1CDBF0@phx.gbl>
X-Server-Quench: 5a0627b5-0e2c-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgoUEkAaAgsB AmMbWVdeUVV7XGY7 bApPbwxDa0lQXgBi
T01BRU1TWkFtCWF4 WVYfUhl1fwZONnxw bUJmEHUKXEJ4chR4
X04BFz4bZGY1bX1N U0leagNUcgZDfk5E bwQuUz1vNG8XDQg5
AwQ0PjZ0MThBJSBS WgQAK04nCWAGAXY1 WwwLFjZnHEEIQTky
IR0rJhYVGkpZKkIu PF09WFscUVcJDQlD A0BKBk5VKkIKXSsh
AA8IFWIEFyVFTCsZ HgchJARBCSBTXSwQ H1NMTlkGFz9MWyoA
QTlUUys2EBA1J09I ei4bNgoyABwsRlJJ DBgTWiMh
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 70.29.93.158/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS SPF: sender matches SPF record
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z25No-0004FN-DM
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:19:05 -0000
--Q68bSM7Ycu6FN28Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote:
> >There will always be a blocksize limit based on technological
> >considerations - the network has a finite bandwidth limit.
>=20
> A bandwidth limit is not the same as a blocksize limit. Bandwidth
> is unique to every individual. Miners in China have different
> bandwidth and connectivity than miners in the U.S., for example.
> But the block size limit is dictated for eveyone. They are not
> comparable.
Bitcoin is a global consensus system - if you're bandwidth isn't
sufficient to keep up you are not part of the consensus.
The blocksize limit *is* what determines the minimum bandwidth required
to stay in consensus.
> >Without a blocksize limit the attacker would just flood the
> >network until the bandwidth usage became so great that consensus
> >would fail, rendering Bitcoin both worthless, and insecure.
>=20
> No, with no blocksize limit, a spammer would would flood the network
> with transactions until they ran out of money. Meanwhile, everyone
> would jump on board trying to mine the blocks to collect the fees
> from the spammers. It could be one of the greatest transfers of
> wealth ever. Bitcoin infrastructure would build up to handle the
> required bandwidth, paid for by the very entity spamming the
> network. Bitcoin would flourish, growing wildly as long as the fees
> kept coming. This is antifragility at its best.
Again, in your scenario if the bandwidth consumed by those transactions
was sufficiently high, the network would collapse because consensus
would fail.
Why wouldn't that bandwidth be high enough to cause that collapse?
Because of the blocksize limit! (combined with an intelligent mempool
that increases the minimum fee/KB appropriately - we don't have that
yet)
> >The worst an attacker flooding the network with transactions with
> >a blocksize limit can do is raise costs, without harming security.
>=20
> No, at attacker flooding the network with transactions with a
> blocksize limit can keep their fees high enough that perhaps 1% of
> transactions coming from real end-users go through. At this point
> everyone would give up on Bitcoin as it would become completely
> unusable. The BTCUSD market would tank, making it even easier to
> pay the transaction fees to keep real transactions out of blocks, as
> it would continue to become cheaper and eventually cost-free to
> obtain the bitcoin fees through market purchase.
I already did the math for you on that: the maximum transaction fee
you'd see in that kind of attack is around $2.5 USD/tx. That definitely
is not high enough to make Bitcoin non-viable - I personally could
easily afford fees like that for about 90% of my transactions this year
by value, as I mainly use Bitcoin to get paid by my clients around the
world. In fact, just today O'Reilly paid $15 USD to send me a wire
transfer for expenses related to a conference I was invited too.
A much more realistic transaction flood scenario - one that didn't raise
serious questions about whether or not the attacker could afford to 51%
attack Bitcoin - would raise tx fees to something more like $0.25/tx
--=20
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
--Q68bSM7Ycu6FN28Q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVdhTAXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj
YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyd1wf+KvozUrU/wVjTMISz/JTpJD86
B6C72QrFJOkqEuraVLGwtYpl3aSOF4Cc6abiyzqg7TYnyTgI8tf0BZM0ZxHPV0Wb
yqBklusrCj7kIuSoHGmaYHPkK+d9KxqmROuM1NtKqZNcVoxemyheQ55HeH8umj/I
RjlE5UsjmYaVCM+/A6z0qwoG4DOQBVlJ4UPgOITlbYbrw0Rbko9D2kyP6lXUIdyY
RTPCAZHr/oQxBE42BzD7EYzgsxanh38xeTE81+W7WIzQdBGsIHY9LQBWNZOHQRJo
W5/wiaur40kXXjoS5rSDLThgAztN9tmEU0kJOly7JUrxhpjunbGf/Qk/DwEhBg==
=Edzm
-----END PGP SIGNATURE-----
--Q68bSM7Ycu6FN28Q--
|
