The formula
While the honest network adds z blocks on top of your payment, the attacker works on a private chain. The whitepaper models the attacker's progress during that time as a Poisson distribution with mean ฮป = zยทq/p (p = 1 โ q is the honest share), and the chance of catching up from k blocks behind as (q/p)^k โ the gambler's-ruin result. Summing over every possible progress k gives the success probability.
The numbers fall fast for a minority attacker: at q = 10% the probability is about 20% with one confirmation and 0.09% with five. At q = 30% the same 0.1% risk needs 24 confirmations, at 45% it needs 340. At 50% or more the attacker eventually wins regardless of depth โ that is the '51% attack'.
ฮป = zยทq/p
P = 1 โ ฮฃ_{k=0..z} (ฮป^kยทe^(โฮป) / k!) ยท (1 โ (q/p)^(zโk))What it means for deposits
Services choose a confirmation count by asking how much hashrate an attacker could realistically command on that network. On Bitcoin, renting even a few percent of the hashrate is very expensive, so many services credit after one to three confirmations. Smaller proof-of-work coins can be attacked with rented hashrate for a fraction of the cost, which is why their deposits wait for dozens or hundreds of blocks: the liquidity provider behind KOT.CASH waits for 6 Litecoin blocks, 12 Dogecoin blocks and 150 Ethereum Classic blocks (network list of 20.10.2026). Ethereum Classic suffered real 51% reorganisations in 2019 and 2020.
Proof-of-stake chains use a different security model โ finality by validator votes โ so this formula does not apply to Ethereum, Solana or TRON; their confirmation counts protect against short reorganisations rather than hashrate attacks.
Limits of the model
- It assumes the attacker starts at the moment of your payment and builds a single private chain; real attacks may be pre-mined or combined with network partitioning.
- It ignores block propagation delays and selfish-mining strategies, which slightly favour a strong attacker.
- It says nothing about cost. Hashrate share is cheap to obtain on a small coin and extremely expensive on Bitcoin.
Frequently asked questions
+Is one Bitcoin confirmation safe?
Against an attacker with a few percent of the hashrate the risk is small, and attacks on Bitcoin are very costly. For large amounts merchants traditionally wait for six blocks, where the probability for q = 10% is about 0.02%.
+Why does Kaspa need 1000 confirmations?
Kaspa produces many blocks per second, so 1000 blocks pass in under two minutes. The count reflects block rate, not lower security per minute; this chain-based formula is only a rough guide for its DAG.
+Does this apply to USDT on TRON or Ethereum?
No. Those are proof-of-stake systems with finality. Confirmations there protect against short reorganisations, and Ethereum blocks become final after about two epochs (~13 minutes).
+What does q mean in practice?
The share of the network's total hashrate the attacker controls during the attack โ owned or rented โ compared to all honest miners.
+Where is the formula from?
Satoshi Nakamoto, 'Bitcoin: A Peer-to-Peer Electronic Cash System' (2008), section 11 'Calculations', which also includes C code and the table this tool reproduces.
Calculations run entirely in your browser; nothing you type is sent to KOT.CASH. Results are estimates for information only and are not financial, tax or legal advice.