Can a 51% attack be detected and dealt with?

Question

If someone got 51% hash power and started rewriting the blockchain from scratch (building a longer chain with a completely different history), could this be detected? Could "the honest users" revert such attacks?

Answer 1

Can such attacks be detected? Yes.

What you would see is a chain reorganization that invalidates a large (greater than three) number of previously-accepted blocks. The standard client will actually log this -- you'll see a REORGANIZE in the client's debug.log file. The client doesn't currently log the number of blocks invalidated by the reorganization, but that's a simple enhancement.

Can honest users revert such attacks? Sort of.

If a transaction you care about is in the set of blocks that was invalidated, you can always resubmit that transaction. Unless the sender issued a conflicting transaction as part of a double-spend attack, the transaction will still be valid. (The network will actually do this for you automatically. Miners don't want to miss out on the chance to grab the transaction fees associated with the undone transactions.)

As a longer-term solution, there have been proposals discussed to reject reorganizations that invalidate suspiciously large numbers of blocks such as four or more. The problem with these proposals is that under unusual circumstances (such as if a disaster partitions the Internet for half an hour), the network can permanently split with each side rejecting the other side's block chain as a suspicious reorganization.

Essentially, the client would have to go to a "lockout" mode if this happened and reject all transactions until some mechanism to find the real block chain could be implemented. (It could submit all transactions to both chains and consider only transactions accepted in both as confirmed!) One proposal uses a central authority to pick the real chain. This is an area where there is room for innovation.

One important point to keep in mind though: If the sender is not attempting a double-spend attack, you have nothing to worry about (other than the reduced usefulness of an unstable exchange network). You can submit the transaction to the block chain as many times as you need to until some block containing the transaction finally does win. Only the sender can create a conflicting transaction that would make you unable to get the transaction you care about into the chain.

Update: In fact, you can lose coins even if the sender wasn't attempting a double-spend attack. Suppose A sends B money and then B sends C money, if A successfully uses a double-spend attack to invalidate the transaction that sent the coins to B, the send from B to C can fail (because a conflicting transactions means B will never have the funds to spend) even though B was not attempting a double-spend attack.

Answer 2

A comment about “starting from scratch”.

Several check-points have been hardcoded in the client source (hashes of blocks are regularly added in new versions of the client) precisely to reduce the impact of large rewrites of big chain chunks. The transaction history generated in the early days of bitcoin could easily be rewritten with all the processing power available to miners today. But recent clients cannot be lured this way because of these check-points.

Someone with 51% of the total computing power could start rewriting the history from the last check-point, but he cannot go further in the past. Also, for the attack to be effective, one must overtake the network chain before the next check point is accepted by a majority of nodes.

Answer 3

There has to be consequence to the attacker, large enough for him to feel the blow of his own attack.

To create the consequence for him: The voter (trusted Node/Full Node) has to have bitcoin, and the more bitcoin the node has, the more voting power (more trusted they are). Example, if the attacker really wants to kill the whole bitcoin network, he has to have at least 51% of bitcoin in circulation. If a bitcoin network is worth $100 billion. He has to buy $50 billion worth of it. Try killing the network and he will lose his $50 billion. Yes, others will lose some little value, but he'll lose much more value, and we can start another cryptocurrency.

It doesn't have to be a linear 1 bitcoin = 1 voting power. It can be a function. like voting power = root2(bitcoin), or other functions.

The only problem with this is that most people will use a centralized node (because they're either using a light node and do not want to waste resources for full node), so their voting power may be centralized somewhere and can be used by the attacker to attack (assuming that more bitcoin = more voting power). The solution to this is probably applying a slowing function (like the root function) to limit their voting power. But then the attacker may use many small value wallet to undermine the big centralized wallet. (Everything in moderation tactic, too much or too little is not good) So we should as well lower the voting power of those who has very little bitcoin in their node - see picture.

So what happens to the node that doesn't have a bitcoin? It's going to be useless anyway because they will leech from the network. I'd say to assign no bandwidth and voting power at all to them since they're not using bitcoin anyway and only wasting network resources. perhaps let them be a low priority reference, just to make them a bit useful.

Same goes to the miners. we should assign similar function as in the picture. We don't want big miners to make the network centralized and in the end having too much power to ruin the network. Since the bitcoin community is by the people and for the people; That is the point of the whole decentralization thing, isn't it? So that we don't get bullied by the big power who wants to centralize everything. We definitely should limit the big power, as well as the useless people who don't use bitcoin and leeching from the network and slowing the real community as a whole.

See the picture below:

Can this help dealing with the DDOS attack as well?

Answer 4

Block checkpoint mechanism has been described as a powerful way for blockchain developers to protect against re-mining the whole chain. Which blocks get to be checkpoints?

Upon actual code review, the block checkpointing mechanism has not been in active use recently. The last block checkpointed in Bitcoin release 0.14 is 295000, which was mined on Apr 9, 2014. However, a total number of transactions since the Genesis block, and the timestamp of that one have been checkpointed up to block 446482 mined on Jan 3, 2017.

By comparison, Litecoin 0.13.2.1 checkpoints block 721000 that was mined on Jan 30, 2015. and then transaction 5502192, mined on Jan 31, 2015. Guess they have not been as diligent and are still catching up to Bitcoin in this regard.