Proposal to prevent 51% Attack -> raise alarm and set client in freeze mode

[yaffare]

When someone pulls of an 51% Attack, this means that the last x blocks including all transactions are going to be invalid. Thats the problem.

Short:
We just should forbid overwriting more than 10 blocks. If that happens user manually selects prefered chain.

Long:
Every bitcoin-client no mather if bitcoind or gui exactly knows when such an attack is going to happen. This is when more than the last 10 blocks are going to be replaced. (You can change the number 10 to maybe 100 or something else if you want, its just an example, but I think we should keep this number as low as possible).

If that happens the bitcoin client raises an alarm and goes into freeze mode, meaning it is not accepting any more blocks until the right block-chain has been manually selected.

Basically there are 2 cases:
1) only you and some others got the alarm, because of internet problems you were accidentally building a bitcoin-subnet. In that case just continue with the real chain and you are good. This to happen is very unlikely, because you and a small number of other clients have to mine 10 blocks by yourself. You would needs weeks to mine those blocks and you would realize much earlier, that something is wrong with your internet connection.

2) A real 51% attack. Every client goes into freeze mode. The attacker cannot take advantage from the attack. The bitcoin-develeopers release a new version with the last correctly mined block as a harcoded block-hash. Everyone downloads the new version and continues as normal.

After the attack everybody would know that someone bad really has 51%. Everybody would increase the minimum confirmations to 10.

Feedback appreciated.

[deepceleron]

A 51% attack refers only to mining and the transaction blocks that are included in the blockchain, it matters not for the average Bitcoin user.

It would require a malevolent actor to have more than the hashrate of the entire bitcoin network for a sustained time, and they would be generating valid blocks, just ones with different transactions in them than were previously sent. There is no "invalid" blockchain, just a longer one.

The attack scenario would be that I spend 10000 BTC buying dollars or something else tangible and irreversible. My transaction sending the seller money is included in block 210,000, lets say 10 blocks ago. I then start generating my own blocks starting at 210,000 that would erase the transaction and overtake the network's current block number, and then publish the whole longer blockchain I've been working on, thereby wiping my 10000 BTC transaction and refunding my money. Very improbable with the current difficulty.

If there was a major network split, it would still be hard to set an "alarm". Let's say that you are in Iran, and they turn off the Internet, cutting off Bitcoin to the outside world. Now people in Iran can only mine the local copy. Blocks would come incredibly slower because of the small number of miners in Iran vs the current difficulty, and people in Iran wouldn't know about the transactions the outside world is making. The new blocks and transactions are still valid though. Someone might send you coins that have already been spent on the worldwide network, and the payment is still valid, even though you might have this transaction erased once Iran reconnects to the world.

[casascius]

I have actually proposed this in the past as a good idea.  I recall others disagreeing but I wish I could clearly explain why.

I think a drastic drop in difficulty (such as seeing block generation rate drop by more than 90%) should also put a client into freeze mode.  This would be a likely sign that you've been isolated from a supermajority of the network.

If you're in Iran and are isolated for an extended period of time, you're lucky to see one block perhaps a day rather than every 10 minutes, and things are going to remain unconfirmed for an extremely long time, so it's not likely it would go unnoticed.

[kjj]

I always thought that my exponential climb for deep replacements was a good middle ground here.  The main objection to it was that it might sometimes require human intervention on a node, which never bothered me.

[deepceleron]

So such an alarm might be a netsplit/isolation warning, such as an in-sync connected client not getting a new block for an extremely long time and/or one or more blocks with extremely long timestamp delays. The time thresholds could be set to an example .00001 probability of taking so long. Such a warning would come up every few years on normal Bitcoin and be erased quickly when another block comes, but would stay present on a client on an isolated network until block finding returns to an expected rate.

It would only take one person smuggling a blockchain copy on a USB flash disk across the border to catch everybody up in censor-stan. Spending money (smuggling out transactions) would be a bit harder though; you'd have to get out a hibernated laptop with cached transactions or such.

It's hard to picture a scenario where a "freeze" would be needed or could be automated. However, payments you have received that have only been confirmed by extremely long block times could remain marked untrusted (indicating they may only exist on an isolated subnet far behind the current block count). Do you have a link to an explanation of "exponential climb"?