From: Sergio Lerner <sergiolerner@certimix.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
Date: Sun, 05 Oct 2014 20:00:29 -0300 [thread overview]
Message-ID: <5431CD8D.7050508@certimix.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4649 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 5476 bytes --]
next reply other threads:[~2014-10-05 23:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-05 23:00 Sergio Lerner [this message]
2014-10-05 23:40 ` [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT) Gregory Maxwell
2014-10-05 23:50 ` Gregory Maxwell
2014-10-05 23:54 ` Jorge Timón
2014-10-06 0:01 ` Gregory Maxwell
2014-10-06 11:02 ` Mike Hearn
2014-10-06 12:22 ` Tamas Blummer
2014-10-06 6:42 ` Alex Mizrahi
2014-10-06 13:21 ` Sergio Lerner
2014-10-06 13:29 ` Tamas Blummer
[not found] <543438E4.8080501@certimix.com>
2014-10-07 19:04 ` Sergio Lerner
2014-10-07 19:16 ` Gregory Maxwell
2014-10-07 20:04 ` Sergio Lerner
2014-10-08 10:19 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5431CD8D.7050508@certimix.com \
--to=sergiolerner@certimix.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox