Rules of thumb no longer apply, and those who trade large amounts need to assess transaction risks in real time based on the current mining ecosystem.

 

By Jameson Lopp, Cypherpunk Cogitations

Compiled by: aididiaojp.eth, Foresight News

 

If you have ever used the Bitcoin network to conduct transactions, you may be aware that accepting unconfirmed (aka zero-confirmation) transactions is dangerous. Without confirmations, the Bitcoin recipient is vulnerable to race attacks, Finney attacks, and 51% attacks.

 

When you have at least one confirmation, you are no longer vulnerable to race attacks or Finney attacks. Now your only concern is the 51% attack. What is the rule of thumb for an acceptable number of confirmations?

 

  • 1 confirmation: sufficient for small payments under $1,000.

  • 3 Confirmations: Most exchanges require 3 deposit confirmations for payments between $1,000-$10,000.

  • 6 confirmations: Suitable for large payments between $10,000 and $1 million. Six confirmations are considered the standard for security.

  • 10 confirmations: Recommended for large payments greater than $1 million.

 

Digging Deeper

 

Of course Bitcoin is not that simple, and our so-called confirmability rules of thumb are just based on assumptions we don’t really talk about.

 

For example, the confirmation threshold for the rule of thumb listed above is actually based on an attacker with 10% of the global hash rate, in which case 6 confirmations can guarantee with 99.99% certainty that the attacker cannot rewrite a larger amount of history in the blockchain network.

 

But these calculations (which can be found in the whitepaper) were performed long before mining pools and industrial mining, when it was reasonable to assume that it would be difficult for someone to own more than 10% of the global hash rate. Since 2011, a large number of block producing entities (mining pools) have emerged on the network, amassing well over 10% of the global hash rate. At the time of writing this article, there are 5 such mining pools.

 

Quantifying real-time risk

 

Pages 6 and 7 of the Bitcoin whitepaper outline a method for calculating the risk that an attacker could rewrite the blockchain after a given number of transaction confirmations.

 

The competition between the honest chain and the attacker chain can be described as a binomial random walk. The success event is that the honest chain is extended by one block and its lead increases by 1, while the failure event is that the attacker's chain is extended by one block and the gap decreases by 1. The probability that the attacker chain catches up with the honest chain given a given probability is similar to the gambler's ruin problem. In layman's terms: the gambler (attacker) has a negative expected value of winning most of the time, so the longer they play this game with a negative expected value, the less likely they are to be the winner.

 

Given that we assume the attacker has less than 50% of the network hashrate, the attacker's probability of catching up decreases exponentially as the number of blocks they have to catch up increases. Since the longer the delay, the worse it is for the attacker, if he doesn't get lucky and sprint forward early, his chances become vanishingly small as he falls further and further behind. The attacker's potential probability of progress resembles a Poisson distribution, as all mining is a Poisson process, and therefore the outcome of success follows this distribution.

 

To determine the probability that an attacker can rewrite the blockchain from z blocks ago, we multiply the Poisson density of each amount of progress the attacker can make by the probability that he can catch up at that position, where:

 

  • p = probability that an honest miner will find the next block

  • q = probability of the attacker finding the next block

  • z = how many blocks (confirmations) need to be reorganized

  • lambda = z * (q / p)

  • k = integer from 0 to z

 

 

This isn’t a fun formula to calculate, so it seems like a good choice for open source projects.

 

Confirmation Risk Calculator

 

I created the following tool which will dynamically calculate the current chain reorg risk based on the mining pool with the highest hashrate estimate (from the trailing week of mined blocks.) You can of course override this parameter with any other hashrate percentage and number of confirmations required to get a risk score.

 

 

Now it is easy to see that if we want to be 99.9% certain that our transactions cannot be double spent, for an attacker with a given percentage of the network hashrate, the number of confirmations will increase dramatically as the attacker's hashrate approaches 50%.

 

 

Why should you care?

 

At the time of writing, Foundry has 36% of the world’s hash rate, which means that if you accept a payment after 3 confirmations, there is still a 49% chance that Foundry will rewrite the blockchain and launch a double spend attack.

 

 

Assuming the attacker has 10% of the hash rate, the rule of thumb of 6 block confirmations ensures 99.99% that double spends will not occur, while now 60 transaction confirmations are required to achieve the same confidence level.

 

As for the practicality of such an attack: mining pools certainly have no incentive to carry out an attack, as they could lose a lot of business if they did. Miners are generally long-term holders who are reluctant to damage people's confidence in the ecosystem. However, mining pools can still have a single point of failure that someone could exploit to hijack the pool for a short period of time. Similar situations have happened before, such as this BGP attack, which rerouted a large amount of mining pool traffic to mine coins for the attacker.

 

Summarize

 

While Bitcoin is robust and stable in some ways, it is highly volatile in other ways. For those conducting high-value transactions on the Bitcoin blockchain, it is important that they realize that they should adjust their risk assessment based on the current state of the mining ecosystem.

 

To be clear, the above points about Foundry should not be interpreted as some kind of imminent or systemic threat to the integrity of the Bitcoin network. Over the past decade, we have seen ups and downs in miner centralization due to a variety of factors. For example:

 

 

 

I remain optimistic that the incentives driving industrial Bitcoin miners are sound. They will continue to seek out sources of cheap, stranded, excess energy, and the nature of energy is that it can be put to efficient use around the world. In the long term, I expect we will see a more decentralized distribution of hashrate across mining pools. Beyond that, there are technical improvements such as Stratum V2 that take power away from mining pool operators and put it back into the hands of individuals.