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
225
|
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 <sergiolerner@certimix.com>) id 1Xaumw-00031T-T0
for bitcoin-development@lists.sourceforge.net;
Sun, 05 Oct 2014 23:00:26 +0000
X-ACL-Warn:
Received: from p3plsmtpa09-07.prod.phx3.secureserver.net ([173.201.193.236])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Xaumt-0004S0-QL for bitcoin-development@lists.sourceforge.net;
Sun, 05 Oct 2014 23:00:26 +0000
Received: from [192.168.1.100] ([190.247.34.93])
by p3plsmtpa09-07.prod.phx3.secureserver.net with
id zb0E1o00r20a7yu01b0GYr; Sun, 05 Oct 2014 16:00:17 -0700
Message-ID: <5431CD8D.7050508@certimix.com>
Date: Sun, 05 Oct 2014 20:00:29 -0300
From: Sergio Lerner <sergiolerner@certimix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative;
boundary="------------040308040708020408080601"
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [173.201.193.236 listed in list.dnswl.org]
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Xaumt-0004S0-QL
Subject: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack
(FRONT)
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: Sun, 05 Oct 2014 23:00:27 -0000
This is a multi-part message in MIME format.
--------------040308040708020408080601
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
I would like to share with you a vulnerability in the Bitcoin protocol
I've been thinking of which might have impact on the future of Bitcoin.
Please criticize it!
*The Freeze on Transaction Problem
*
The freeze problem occurs if someone publishes a transaction with fees
much higher than the block subsidy. I don't remember who described the
attack first. Suppose that, by mistake, a transaction is published with
50 BTC in fees. The transaction is included in a block at height n. If
everyone acts rationally in his own interest, then the best choice for
the remaining miners is to try to mine a competing block at the same
height n including the high-fee transaction, to collect the fee for
themselves. All the miners having solved the block at height n, now move
on mining at height (n+1). But they won't choose each other branches
until one branch is sufficiently longer so that it is better to switch
to it and abandon their own branch rather than try to keep the block
with the high fee. This case is different from the real block
competition case we see periodically on the blockchain, where the miners
are generally split between two branches. Here there are multiple
branches competing. If there are 10 "top" miners each having 10% of the
network hashing power, then 10 different branches will compete. The
analysis for this case is similar to the Gambler's Ruin problem analysis
present in the Satoshi paper, but with a fixed constant monetary
incentive not to switch. Since the incentive to switch grows
exponentially with the branch length difference, any initial constant is
diluted. In the special and rare case that all the miners have exactly
the same hashing power, then the network diverges, and this is
equivalent as having two miners having exactly 50% of the hashing power
each. So in principle the freeze on transaction problem is just a
temporary disruption in the network, but not a fatal halt. Nevertheless,
since during the freeze period each miner is mining on his own branch,
it also means that moving forward with blocks is a lot slower. Assuming
10 miners having 10% of the total hashing power each (+/- 3%), the
network becomes 10 times slower. I simulated it with a 50 BTC tx freeze
fee, and 10 miners, and it takes approximately 6 blocks to converge, so
the freeze time is approximately 60 times the block interval, or 10
hours. If the distribution is approximately 25% of the hashing power for
each top miner, the freeze time is 4 hours.
Obviously what's needed for the freeze problem to occur is that miners
are 100% rational, greedy and prepared. They need to have a modified
version of bitcoind which can automatically detect a high-fee
transaction and prevent adding to the best chain a not-owned block
containing such transaction. There will be no time for the miners to
patch bitcoind if such transaction is manually spotted. Also the latest
versions of bitcoind have preventions not to allow high fees by mistake.
So the freeze problem is currently non-existent, but may pop up in the
future in form of a state-sponsored attack.
*The Freeze problem as an Attack*
If an attacker plans to repeat such attack periodically at the expense
of wasting a lot of BTC, there is little the current protocol can do,
because miners will be prepared to take advantage of the attack. If the
attacker issues a new fee burning transaction before the network
converges, then the attacker can maintain incentives to keep every miner
separated in his own branch. So wasting 50 BTC every 4 hours, an
attacker can maintain the network frozen forever. Even if we restrict
the maximum fee per transaction, the scripting system has infinite ways
to create transactions whose output can be taken by anyone, and the
attacker can announce the method miners can use to collect those BTC and
even prepare and publish the bitcoind patches to automate collecting
those transaction outputs.
The best thing the community can do is act together and cooperate to
share the high transaction fee. This will neutralize the attack
completely and allow miners to earn extra bitcoins. But cooperation in
the Bitcoin community has never been easy. There is a technical solution
which is to modify the Bitcoin protocol so that every transaction output
has a maturity time of 6 blocks, and if a transaction output is redeemed
multiple times in a 6 block interval, then the BTC amount is split
between all redeemers, and also fees would be automatically shared in a
6 block sliding window. At a first glance, this provides a way for
miners to cooperate even anonymously and there is no immediate drawback,
but an in depth analysis is necessary.
--------------040308040708020408080601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I would like to share with you a vulnerability in the Bitcoin
protocol I've been thinking of which might have impact on the
future of Bitcoin. Please criticize it!<br>
</p>
<p><strong>The Freeze on Transaction Problem<br>
</strong></p>
<p>The freeze problem occurs if someone publishes a transaction with
fees much higher than the block subsidy. I don’t remember who
described the attack first. Suppose that, by mistake, a
transaction is published with 50 BTC in fees<span lang="en-US">.</span>
The transaction is included in a block at height n. If everyone
acts rationally in his own interest, then the best choice for the
remaining miners is to try to mine a competing block at the same
height n including the high-fee transaction, to collect the fee
for themselves. All the miners having solved the block at height
n, now move on mining at height (n+1). But they won’t choose each
other branches until one branch is sufficiently longer so that it
is better to switch to it and abandon their own branch rather than
try to keep the block with the high fee. This case is different
from the real block competition case we see periodically on the
blockchain, where the miners are generally split between two
branches. Here there are multiple branches competing. If there are
10 “top” miners each having 10% of the network hashing power, then
10 different branches will compete. The analysis for this case is
similar to the Gambler’s Ruin problem analysis present in the
Satoshi paper, but with a fixed constant monetary incentive not to
switch. Since the incentive to switch grows exponentially with the
branch length difference, any initial constant is diluted. <span
lang="en-US">In the special and rare case that all the miners
have exactly the same hashing power, then the network diverges,
and this is equivalent as having two miners having exactly 50%
of the hashing power each. So in principle the freeze on
transaction problem is just a temporary disruption in the
network, but not a fatal halt. Nevertheless, since during the
freeze period each miner is mining on his own branch, it also
means that moving forward with blocks is a lot slower. Assuming
10 miners having 10% of the total hashing power each (+/- 3%),
the network becomes 10 times slower. I simulated it with a 50
BTC tx freeze fee, and 10 miners, and it takes approximately 6
blocks to converge, so the freeze time is approximately 60 times
the block interval, or 10 hours. If the distribution is
approximately 25% of the hashing power for each top miner, the
freeze time is 4 hours. </span></p>
<p>Obviously what’s needed for the freeze problem to occur is that
miners are 100% rational, greedy and prepared. They need to have a
modified version of bitcoind which can automatically detect a
high-fee transaction and prevent adding to the best chain a
not-owned block containing such transaction. There will be no time
for the miners to patch bitcoind if such transaction is manually
spotted. Also the latest versions of bitcoind have preventions not
to allow high fees by mistake. So the freeze problem is currently
non-existent, but may pop up in the future in form of a
state-sponsored attack.</p>
<p><strong>The Freeze problem as an Attack</strong></p>
<p>If an attacker plans to repeat such attack periodically at the
expense of wasting a lot of BTC, there is little the current
protocol can do, because miners will be prepared to take advantage
of the attack. If the attacker issues a new fee burning
transaction before the network converges, then the attacker can
maintain incentives to keep every miner separated in his own
branch. So wasting 50 BTC every 4 hours, an attacker can maintain
the network frozen forever. Even if we restrict the maximum fee
per transaction, the scripting system has infinite ways to create
transactions whose output can be taken by anyone, and the attacker
can announce the method miners can use to collect those BTC and
even prepare and publish the bitcoind patches to automate
collecting those transaction outputs.</p>
<p>The best thing the community can do is act together and cooperate
to share the high transaction fee. This will neutralize the attack
completely and allow miners to earn extra bitcoins. But
cooperation in the Bitcoin community has never been easy. There is
a technical solution which is to modify the Bitcoin protocol so
that every transaction output has a maturity time of 6 blocks, and
if a transaction output is redeemed multiple times in a 6 block
interval, then the BTC amount is split between all redeemers, and
also fees would be automatically shared in a 6 block sliding
window. At a first glance, this provides a way for miners to
cooperate even anonymously and there is no immediate drawback, but
an in depth analysis is necessary.</p>
</body>
</html>
--------------040308040708020408080601--
|
