On Solving the 51% Attack Problem in Bitcoin (Part 2)

Jonald Fyookball
2 min readNov 22, 2018

--

In Part 1, we discussed the problem of the 51% attack, and why it is difficult to solve. Here I would like to present a possible solution. (Disclaimer: I have not spent much time analyzing this, so maybe there is some big obvious flaw.)

This solution is extremely simple. The node will penalize any chain that it sees attempting a re-org based on a delay. Delay penalties and Delayed proof of work schemes have been proposed before. I do not know whether this particular scheme has been proposed.

The penalty shall be 0.1% for each second of time elapsed between the time the node sees the reorg block and the time the node saw the previous block of the same blockheight.

The penalty applies to the entire chain starting with the reorg block.

The smooth decay with respect to time is the magic here.

Normal Orphans Not Affected

Currently, in the normal situation when 2 blocks are found at the same time, each node will respect the first seen rule. In this case, not much would change. For example if one node gets the block 5 seconds later, then that chain has a penalty of half of one percent. When the next block is found on either chain, it would still be decisive.

Deep Reorgs Prevented

Now let’s go to the other extreme: Say an attacker waits 10 minutes and tries a reorg. That’ obviously malicious. In this case, the penalty would be 600 seconds or 60%. That means they would need 3 blocks to overcome 1 honest block… Or 5–6 blocks to overcome 2 honest blocks.

If the reorg attack came at 1000 seconds, it simply gets 0% weight. Other nodes who saw it at 999 seconds would give it an minuscule amount of weight, so it would easily be outrun.

Middle Ground?

It would be possible to get some penalty in the middle, 20, 30, 50%… and this could create a race condition, but only at a shallow reorg depth. The race would soon be over, and just as important, an attacker could not fool honest nodes into battling each other because they would each see a similar penalty.

Finalty

Finalty falls back to Nakamoto Consensus. When the race ends and the longest chain proof of work overtakes the attacker chain eventually (no matter how long), it is finalized in the purest sense.

Proof of Reorg

Penalties are applied by real time analysis of delays but duplicate chainwork can be proven by publishing (for example to a block explorer) of the duplicate work blocks.

The time at which blocks are received will be seen by nodes and miners and can also be published. Nodes that are syncing can recognize a race condition and wait till it is resolved.

--

--