diff options
| author | Sergio Lerner <sergiolerner@certimix.com> | 2014-10-05 20:00:29 -0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-10-05 23:00:26 +0000 |
| commit | 714853f7d828c31e303efddc63529f0fde14af48 (patch) | |
| tree | f82f7dca814646c6053ac77fdeecd6d94c7c5efd | |
| parent | c8adf720a82b5f880d61e4b7a79fec93f0c4dffc (diff) | |
| download | pi-bitcoindev-714853f7d828c31e303efddc63529f0fde14af48.tar.gz pi-bitcoindev-714853f7d828c31e303efddc63529f0fde14af48.zip | |
[Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
| -rw-r--r-- | 33/4c4a91fb494175e804d27aab20579e557be3c9 | 225 |
1 files changed, 225 insertions, 0 deletions
diff --git a/33/4c4a91fb494175e804d27aab20579e557be3c9 b/33/4c4a91fb494175e804d27aab20579e557be3c9 new file mode 100644 index 000000000..cf01aac7b --- /dev/null +++ b/33/4c4a91fb494175e804d27aab20579e557be3c9 @@ -0,0 +1,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-- + + |