ABC Tools

Proof-of-Work Mining, Explained

After reading this you can predict how many SHA-256 hashes a block at a given difficulty needs, explain why tampering with an old block breaks every block after it, and compute an attacker's chance of rewriting the chain from a known deficit and hashrate share.

Proof of work turns computing power into a lottery ticket. A miner picks a block of transactions, appends a number called a nonce, and hashes the whole thing with SHA-256. If the resulting hash is small enough (has enough leading zero bits), the block is valid and gets chained. If not, the miner changes the nonce and tries again. There is no clever shortcut. You grind.

The simulator uses real SHA-256, the same 256-bit hash defined in FIPS 180-4 that Bitcoin uses. The only thing scaled down is the target: instead of Bitcoin's ~76 leading zero bits, you work with 8 to 24 bits, so a block finishes in milliseconds to seconds in your browser instead of ten minutes across a planet-sized network.

What the simulator shows you

Three ideas, three panels. The mining panel lets you set the difficulty in leading zero bits and watch the nonce counter climb until one hash clears the target. The chain panel gives you a finished 4-block chain and lets you edit an old block, so you can watch every later block turn red at once. The probability panel plots the two distributions that govern everything: the geometric spread of attempts per block, and the random-walk chance that an attacker catches up.

The hook is the tampering demo. Change one character in block 1's transactions and blocks 2, 3, and 4 all become invalid instantly. Not because anyone checked the transactions, but because each block header contains the hash of the block before it. Rewrite block 1 and its hash changes, so the "previous hash" stored in block 2 no longer matches, and so on down the chain.

When this model applies

Use this to build intuition about Bitcoin, Litecoin, and any Nakamoto-style consensus where security comes from cumulative hashing work. The mechanics here (hash-linked blocks, a difficulty target, longest-chain rule) are exactly those systems at tiny scale.

This is not a model of proof-of-stake chains, BFT consensus, or any permissioned ledger. Those replace hashing work with staked capital or a known validator set, and the catch-up math below does not apply to them. Do not carry the 51% intuition over unchanged.

The difficulty formula

A SHA-256 output is a uniformly random 256-bit number, as far as any known attack can tell. Requiring the first b bits to be zero means you accept a fraction 2^{-b} of all possible hashes. Each nonce is an independent trial with that success probability.

P(\text{success on one hash}) = 2^{-b}

Here b is the difficulty in leading zero bits. The number of attempts until the first success follows a geometric distribution, and its mean is the reciprocal of the success probability.

E[\text{attempts}] = 2^{b}

So at b = 16 you expect 65536 hashes per block. At b = 17 you expect 131072. Every extra bit doubles the expected work. That is the whole idea of difficulty adjustment: to keep block times steady as hashrate grows, the network raises b.

The variance is large. For a geometric distribution the standard deviation is almost equal to the mean, so a block that "should" take 65536 hashes might finish in 3000 or take 250000. That is not a bug. It is the coin-flip nature of mining.

A worked example at 16 bits

Reproducing the demo run

Load the tool with its defaults (difficulty b = 16 bits, a 4-block chain) and mine.

  1. Success probability per hash is 2^{-16} = 1/65536 \approx 1.526 \times 10^{-5}.
  2. Expected attempts per block: 2^{16} = 65536.
  3. At a browser rate of, say, 500,000 hashes per second, one block takes about 65536 / 500000 \approx 0.131 seconds on average.
  4. Mining 4 blocks in a row costs about 4 \times 65536 = 262144 hashes on average, roughly half a second.
  5. Now edit block 1. Its hash changes, so blocks 2 through 4 are invalid. To fix the chain you must re-mine block 1 (another ~65536 hashes), then block 2, 3, and 4, because each one's valid nonce depended on the previous hash you just changed.

The lesson: tampering with a block one deep does not cost you one block of work. It costs you every block from there to the tip, all over again.

The header being hashed includes the previous block's hash, a Merkle-style commitment to the transactions, and the nonce. Change any bit of any of those and the output hash is completely different, with about half its bits flipped on average. That avalanche property is why you cannot patch a hash; you can only search for a new nonce.

The spread of attempts

Because attempts are geometric, the histogram of "hashes needed per block" is not bell-shaped. It is heaviest near zero and has a long tail. The fraction of blocks that finish within the expected count 2^{b} is 1 - e^{-1} \approx 0.632, so about 63% of blocks are found faster than average and 37% take longer, some far longer.

The geometric spread: about 39% of blocks finish in under half the expected work, but roughly 1.8% take more than four times as long.

Those numbers come straight from the exponential approximation to the geometric law: the chance of needing more than a multiple m of the mean is e^{-m}. So e^{-4} \approx 0.0183 gives the 1.8% tail.

Catch-up probability and the 51% attack

Suppose an attacker controls a share q of the total hashrate and starts k blocks behind the honest chain. Each new block is a race, and the attacker wins each one with probability q. This is a biased random walk. For q \lt 0.5 the probability that the attacker ever closes a deficit of k blocks is:

P_{\text{catch up}} = \left(\frac{q}{1 - q}\right)^{k}

The ratio q / (1 - q) is the attacker's blocks per honest block. If q = 0.3 that ratio is 0.3/0.7 \approx 0.4286. Catching up from 1 block behind: 42.9%. From 6 blocks behind: 0.4286^{6} \approx 0.0062, about 0.6%. That exponential decay in k is exactly why exchanges wait for six confirmations.

With 30% of the hashrate, each additional confirmation cuts the attacker's chance by roughly 57%.

At q = 0.5 the ratio is 1, so P = 1 for every k. That is the 51% attack: with at least half the hashrate, catching up and overtaking is certain given enough time. No number of confirmations saves you.

The catch-up probability from k blocks behind is (q/(1-q))^k when q is below 0.5. At q = 0.1 and k = 6 it is about 0.0000017; at q = 0.45 and k = 6 it is about 0.297. It jumps to 1 for any k once q reaches 0.5.

Common mistakes

Confusing bits with hex zeros
Leading zero bits, not hex digits. One hex digit is 4 bits. A target of "3 leading zero hex characters" is 12 bits, expected work 4096, not 3.
Expecting the expected
The mean is 2^{b}, but the median is only about 0.693 \times 2^{b}. Most blocks finish faster than the average because the long tail pulls the mean up. Do not read a fast block as a broken simulator.
Thinking tampering is cheap
Rewriting a block k deep means re-mining k+1 blocks while the honest chain keeps extending. That is the whole point of cumulative work.
Assuming q < 0.5 means safe forever
It means the success probability decays with each confirmation, not that it is zero. With q = 0.45 and k = 6 the attacker still has about a 29.7% chance.

Frequently asked questions

Frequently asked questions

Why does mining use SHA-256 specifically?

It is fast to compute forward, has no known way to run backward, and produces output that behaves like a uniform random number. Those three properties make it a fair, uninvertible lottery. Any strong cryptographic hash would work; Bitcoin chose SHA-256 (twice applied, actually).

How many hashes does real Bitcoin need per block?

Around 10^{22}, corresponding to roughly 76 leading zero bits. This simulator's 8 to 24 bits is the identical mechanism about a millionth of a trillionth of the scale, so you can watch it finish.

Can two miners find a valid block at the same time?

Yes. That produces a temporary fork. The network keeps whichever branch accumulates more work next, and the losing block's transactions return to the pool. This is why one confirmation is weak evidence and six is strong.

Does a faster computer change the odds per hash?

No. Every hash has the same probability 2^{-b} of success regardless of speed. A faster machine only takes more tickets in the same time, so it wins blocks proportionally more often. That is exactly what "hashrate share" q measures.

Why do exchanges wait for six confirmations?

Six confirmations put a would-be double-spender six blocks behind. At any realistic attacker share below about 25%, the catch-up probability is well under 0.1%, small enough to treat the payment as final.

Try it yourself in the tool

Related tools

AES Encryption

Encrypt and decrypt text with AES-GCM or AES-CBC.

Cryptographic Key Generator

Random keys, IVs, salts and API tokens from a CSPRNG.

Enigma Machine Simulator

Operate a full Enigma I — rotors, plugboard, lamp board — and watch each letter travel the wiring.

JWT Builder & Signer

Build and sign JSON Web Tokens (HS256/384/512).

RSA Key Pair Generator

Generate 2048/3072/4096-bit RSA keys in PEM format.

TOTP / HOTP Authenticator

Generate 2FA codes and otpauth:// QR strings.