Topic: Eternal Choice for the Dark Side Attack (ECDSA) and the Safe Mode solution (Read 1383 times)

I've changed the post to include gmaxwell explanation about why my solution just doesn't work.

This is my idea of how to change my solution to actually work:

The additional protective measure would be that any chain reorg of n blocks is delayed n seconds.  During that wait period, if another better chain reorg is received, is processed in the same way. After one period expires, the chain reorg is applied, and a new best chain is created. If a block that extends a waiting chain is received, then the waiting lapse is restarted from zero for that chain. If a node receives a 144 length branch in a very short period of time, it will wait 144 seconds to actually apply the reorganization, so if the network is not split, that gives plenty of time to exchange all other chains in existence and choose the best.  If a node receives two 143 block competing branches in a short period of time, then any attempt to extend both chains at the same time will result in both staying in a waiting state for 144 seconds more. A chain of 144 blocks won't accept any additional extension (the max is 144) so the attacker cannot keep playing this game forever.

Any problem with this?

Sigh.

Cost of attack:  15% of the global block reward, until the end of time (currently ~$378,000 per week)
Reward per successful attack:  some fraction (50%?) of a fraction (perhaps nearly 100%) of the transactions happening in a randomly located 8 block window, plus the mining reward from 8 blocks

For the low, low cost of only 15% of the network, you can reliably overturn transactions in 0.7952% of the blocks.

I hope you didn't lose too much sleep over this.  I'm sure not going to.

This idea keeps getting reincarnated in different forms, but it's a naive idea. For example I remember that I discussed it with Meni in the context of cementing prior to decentralized checkpoint blocks (where the client could un-cement at the checkpoint, which would be better than what you propose). The problem with this idea is that an attacker can create netsplits by broadcasting a competing branch with same height as the cementing limit, and potentially cause chaos (under the assumption that the network is decentralized). Gregory Maxwell explains nicely the naivety of this idea:

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.

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?

There are 2 possible solutions (and both are soft-forks):

1. Automatic checkpointing (or automatic alerting system) with Ripple-like consensus system: https://bitcointalksearch.org/topic/applying-ripple-consensus-model-in-bitcoin-144193
This one is specially designed to fight against situations like ECDSA

2. Decoupling POW and transaction: https://bitcointalksearch.org/topic/decoupling-transactions-and-pow-179598
This one allows 10 seconds/confirmation, without worrying much about network latency. There will be 360 confirmations in 1 hour and impossible to reverse without a real 51% attack

Thanks for choosing a name for the attack that doesn't confuse people with other things. 

I would like to share my post in my blog relating a society-engineering/technical attack on Bitcoin.
The attack is speculative, and there is no certainty that I will succeed as described. Nevertheless the attack idea makes sense for me, and the suggested solution could prevent the network from other unknown market-socio-technical attacks, that play with human emotions like fear or greed.

Here is my post: http://bitslog.wordpress.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/

Here is a copy of the proposed solution:

Add the Satoshi client a “Safe Mode” (since there is already a Safe Mode that is related to the RPC commands, this could be Safe Mode 2). 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.

Best regards, Sergio.