Why do we use Proof-of-Work?

The problem that PoW solves is how to allow any node in the network to find the current correct consensus of transaction ordering that every other node sees, even when leaving and rejoining the network, without trust. This state consistency is what prevents double spends while allowing a dynamic set of permissionless validators and coordinators.

From the Bitcoin whitepaper abstract:

The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they’ll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.

This avoids something called “subjectivity”, meaning that a node looking at two chains can tell the correct version without some external information. This is an issue that proof-of-stake systems have to deal with but that PoW has completely sidestepped. Bitcoin is an objective consensus system so clients need nothing but the rule set to find the best chain.

What is “finality”?

In a consensus system “finality” is the property of a state transition (i.e. a Bitcoin transaction) being irreversible. Many people think of Bitcoin transactions as irreversible but without checkpoints all transactions in Bitcoin can be reversed if an entity is willing to burn enough capital. This introduces the concept of “economic finality”, meaning that a transaction is final if and only if no party is willing to waste capital to reverse it. Every block on top of a transaction gives its economical finality more and more probability.

Without checkpointing transactions are never 100% final. Until the first checkpoint was added Bitcoin could have been reorged back to the Genesis block, but the first checkpoint prevented that and every subsequent checkpoint has given its contained transactions the same degree of finality. Unfortunately checkpoints are a soft forking behavior that requires either a social or miner consensus to organize and take manual action.

Without finality everyone is in for a hard time. If transactions can be undone after many hours, days, or weeks then we no longer have a stable payment system, a sound investment, or a usable system in any capacity.

Incentivize miners to improve finality

If we want better transaction finality without manually coordinating rule changes, and without introducing subjectivity, we need to encourage the miners to act in a way that provides it. Consensus rules do not need to change if we can incentivize miners to work against reorgs. The existing rules encourage miners to immediately act on reorgs in order to increase convergence times but that may not be the optimal strategy.

For miners to make money their blocks must end up on the “main chain”; the valid chain with the most PoW. If their blocks end up getting orphaned then they lose money. Currently the best way for miners to ensure that their blocks end up on the main chain is to always work on the chain with the most work. This works because they expect the majority of honest miners to do the same so their states will converge.

More generally the way a miner gets their block into the main chain is to correctly guess what the majority of hash rate is going to work on. It does not need to be the most-work-right-now rule if that’s not what is most likely to end up with the most work in the end. If there is a widespread mining policy that does not immediately jump chain tips then switching as soon as you see a tip with more work may not be the most likely way to get your block in the main chain.

Acceptance Depth, but for proved work

In the Bitcoin Cash network there is actually a deviation from the immediate switch behavior in the case of large blocks. Each node decides how large of blocks they want to follow and they ignore more-work chains that have excessive blocks unless that chain gets far enough ahead. Then it will give up and collapse to the most-work chain. How far a chain will accept working with the work-minority is called the “Acceptance Depth”. The consensus does not change, the most PoW chain is still the most current consensus but nodes continue to try salvaging the chain with smaller blocks.

Similarly you could model the work with an Acceptance Depth which currently is 0. If a miner sees another chain whose work is greater than their current chain by any amount they will switch to the new chain. If we recognize that large reorgs are harmful to users we can make a policy to require a larger work depth before reorging where the depth is based on the amount of blocks being reorged. If a node is seeing a reorg chain building it can fall into the fork-detection “safe mode” and warn operators about an ongoing situation.

The Auto-Finalize Acceptance Depth policy

After recognizing the concept of an Acceptance Depth for work we can increase finality by increasing the depth. Miners, exchanges, other businesses, and other users can elect for their nodes to try to do what they can to salvage the first chain they see. They are alerted when a public reorg chain is forming so they can take manual action and be prepared for future action. Miners are incentivized to salvage the main chain because they know the majority of other honest miners are doing so too.

If honest miners can win out in a time-frame determined by the policy’s depth, they can overtake the reorg chain in work and keep the consensus using the original chain. Nodes will avoid going through a large reorg and everyone but the attacker will be happy. If the attacker can sustain >50% of hash rate long enough to overcome the policy depth then the honest nodes will experience a reorg from the fork point to the point where the attackers break the work threshold.