I absolutely fucking despise people that use these forums to promote their shitty blogs. I give Sergio a pass on that because he has done a bunch of good work, but I still refuse to click his links. Does anyone want to copy the text of this article here?
Hey, don't need to get upset. I'm posting the article here. I didn't post it because I thought that the solution was more important that the post itself, which is very speculative ....
The Bitcoin Eternal Choice for the Dark Side Attack (ECDSA)Warning: This post is a mere speculation. There are many unknowns that may change the ending of this story, but nevertheless, an attack like this, that tries to divide the Bitcoin community, undermining the moral of each user, sounds quite probable to me. But I love Bitcoin, I’m optimistic and I wish Bitcoin a great future.
The 51% attack is probably to costly and to risky to be performed for profit. Currently it requires the attacker to invest (buy) around 5M USD in ASIC mining boxes. This have been widely discussed (e.g. here).. There are nevertheless fewer posts analyzing on the impact of an 51% attack performed to destroy Bitcoin (e.g. here). The most simple idea is to use 51% of the hashing power to paralyze Bitcoin: just creating empty blocks. But it turns out that this attack can be defeated by comparing branches not only using the PoW, but using the age of the coins transacted.
I will describe an attack that could destroy Bitcoin, starting with less resources, such as 15% of the hashing power, with high probability of success, so then the attacker has a chance to increase the resources gradually as the attack proves to be working. I’ve call it the Eternal Choice for the Dark Side Attack (ECDSA), so that it doesn’t clash with some other attack name in the literature. It may work, and may be carried anonymously. The idea is that, with 15% of the hashing power, the attacker has approximately a 1:1000 chance of creating a branch of 8 blocks in a row himself faster than the main branch. So every 7 days, on average, the attacker gets a chance to revert transactions that most people think they are sufficiently confirmed. So far, nothing new.
Now imagine that the attacker never broadcasts the blocks he mines, keeping them private. The attacker includes in his blocks some percentage of the transaction he sees in the network, such as 10%, to thwart a coin-age distinguisher algorithms. Every time he mines 7 blocks in a row faster than the honest chain, he anonymously publishes the block headers (as proof) in some public board such as bitcointalk, but he does not publish the transactions referred by the Merkle root. He also hacks some computer X somewhere and runs a special version of bitcoind that only accepts double-spends (not new transactions, nor previous transactions). Then he advertises a “service” to allow people to double-spend the past transactions, which would only require people to send the double-spend transactions to X, including a fee of 10% of the transaction output value (the 10% fee is just a diversion to let people think it’s some kind of dark business). Since the attacker has 15% of the hashing power, he can succeed creating a new block with the double-spends collected with probability 1/6.6.
What people would do? If they are honest, they will not use the double-spend service. If they are not, they may be tempted to do so. Suppose 10% of the people try double-spending. After the first successful attack , some victims will complain as having been cheated. Rumors will spread regarding the current insecurity of the network. The price will fluctuate, but will stabilize. Seven days later, the same announce is made, publishing the 6 block header branch. This time the market will react before the attack is even made. Bitcoin price will certainly decrease, even if afterwards the attack is unsuccessful. In forums, people are advised not to accept 6 confirmations, but 10. Now the attacker increases his resources to 20% of the network hashing power. Seven days later, the announce is made again, showing 10 block headers. This time 20% of the people opt for cheating. More fraud victims appear. Now more fear spreads. Bitcoin price drops substantially. Miners fail to prevent the attack by including the original transactions in blocks mined after the attacker branch because some of the transactions were actually included in the attackers branch, but which ones is unknown until the attack is performed. Core developers try to implement a patch for the satoshi client to distinguish between the attacker branches and the “honest” branches, by inspecting the maturity of the coins transferred. But since the attacker branch also contains some percentage of valid transactions, the distinction is risky and the patch also introduces the possibility of wrongly switching to a parallel branch with less PoW. The attacker manages to fool the patch. Some honest miners leave Bitcoin mining business temporarily with dubts. The attacker now sees an increase of its hashing share to 30% of network hashing power. He begins to accept double-spends before actually performing the attack, so cheaters can gamble at SatoshiDice and have their bets reversed when they loose, with 1/3 of cheating probability. SatoshiDice closes temporarily. Cheaters find other online sites to abuse. The Core dev team tries to implement a checkpoint system to manually distinguish between branches every week, but there is no consensus on who should take the decision of which is the right branch. There is a warm debate in the forums. Time to decide for the Core dev team is running out. The same eternal choice of cheating or not comes over and over, as attacker announcements are made too often, like Darth Sidious seducing Anakin to go the dark side. The attacker increases his power to 40%. . The offer is more tempting, so more people try to cheat. Bitcointalk heros tell people to accept only transactions with 20 confirmations. The usefulness of Bitcoin is in danger. Bitcoin price decreases. The attacker is advertising the reversal of transaction every hour, with a 50% success probability. Honest people stop transacting using Bitcoin preventively. The price drops, and drops again. Cheaters start to automate cheating using bots, and withdraw funds as fast as they can. The price collapses.
The attackers laughs, and then an order to dispose 1M USD in custom ASIC chips arrives, not before 100 additional employees are hired and given hammers in order to smash each chip 7 times, in some secret office at a secret headquarters of a secret department of some secretive state.
Solution(this section has been edited)
At the time I wrote the post I had no clue of how to solve the problem. My only relief was the hope that there are more honest people in the world than dishonest ones. But after 4 hours of bad sleep I realized that the key is taking pro-active measures. There is little that can be done well under the pressure of an attack. So my idea is to add the Satoshi client a “Safe Mode”. In Safe Mode, transactions are only considered confirmed if they have 144 blocks of confirmation (1 day). Also in Safe Mode, the clients do not accept any chain reorganization of length greater than 144 blocks (this is the key restriction). One day has been proven to be enough for the core dev team to resolve chain forking situations, and still it is short enough to let people transact almost as normal. Only services that require fast confirmation will have to pause their operations, or accept payments of low value with the implicit risk. Safe Mode could be announced by using the network alert system, either by making clients automatically switch to this mode or by requiring the user confirmation. Safe Mode alerts would have a finalization date, as other alerts. Also Safe Mode would be immediately terminated by the “Alert key compromised” alert.
This solution is very simple to implement (maybe 5 lines of code), and yet provides an incredible increased level of protection against attacks that attempt Bitcoin destruction. I has to be there so it never needs to be used.
The only drawback would be if a 51% powerful attacker colludes with the dev team to activate the Safe Mode and create a 144 length alternate branch to split the network, which is of course a much more sophisticated attack.
Time for breakfast.
