b3chain / Testing & Verification / Phase 11 / 51% Attack

The 51% Attack: Live Demo & Defences

A 51% attack is the most-discussed risk for any proof-of-work chain. This page explains what it is, walks through a live regtest reproduction, gives the math behind the safety margin, calculates the cost on real hardware, and lists the defences both b3chain and the user can apply.

Demo: audit-51-attack-sim.py Math: Nakamoto §11 Status: live demo PASS
Educational only. This page demonstrates how the attack works on a local regtest network. Do not attempt this on any live production chain — you will lose money and may break the law.

1. What a 51% attack actually is #

Bitcoin and b3chain choose the canonical chain by picking the one with the most cumulative proof-of-work. If a single entity controls more than 50% of the hashrate, they can mine a private chain in secret and, once it has more work than the public chain, reveal it. Every honest node will switch to the longer chain because that is what consensus tells them to do. 

            block                              this block paid Bob
              |                                          |
genesis ----- 1 ----- 2 ----- 3 ----- 4 ----- 5 ----- [6] ----- 7 ----- 8     (honest chain)
              |                                          |
              \                                          \--- mempool tx (NOT in attacker chain)
               \
                \-- 1' ----- 2' ----- 3' ----- 4' ----- 5' ----- 6' ----- 7' ----- 8'   (attacker chain, secret)
                                                                          ^
                                                              attacker chain is now LONGER
                                                              attacker reveals; honest nodes reorg
                                                              tx that paid Bob is REVERSED

The transaction that paid Bob existed only on the honest chain. After the reorg, Bob's wallet sees its 6-confirmation deposit disappear and the attacker's address holds the funds instead.

2. The math: Nakamoto's reorg-success formula #

From Bitcoin: A Peer-to-Peer Electronic Cash System (§11). Let q be the attacker's fraction of total hashrate, z the number of confirmations the victim waited for. The probability the attacker eventually overtakes the honest chain is approximately: 

P(success) = 1 - sum_{k=0}^{z} { e^(-zq/(1-q)) * (zq/(1-q))^k / k! } * ( 1 - (q/(1-q))^(z-k) )

Reorg-success probability table

q (attacker hashrate)z = 1z = 3z = 6z = 10
10%20.46%1.32%0.02%0.00%
20%41.59%10.32%1.43%0.11%
30%62.77%32.46%13.21%4.17%
40%82.89%66.42%50.40%36.00%
45%91.98%84.44%76.61%68.54%
50%100%100%100%100%

Once the attacker has > 50% of hashrate, success is certain on a long enough timeline. The interesting question is "how many confirmations protect against an attacker with X%?". For a 30% adversary, 6 confirmations gives 87% safety; 10 confirmations gives 96%.

3. Cost calculator #

Hashrate isn't free. To control 51% of a chain's hashrate for the duration of an attack you need to either own that much equipment, or rent it. The table below assumes the attacker rents.

Scenarioz (confs)Attack windowIndicative cost
Tiny altcoin (~10 PH/s total)6~1 hour~$50–500 of cloud compute
Mid-cap PoW chain (~1 EH/s)6~1 hour~$10 000–100 000
Bitcoin mainnet (~600 EH/s)6~1 hour~$300 million (no rental market that deep exists)
Early b3chain (post-launch, low hashrate)6~1 hourat risk — see defences

Numbers are illustrative. The point is: attack cost scales with network hashrate × attack duration. Live tracking of these numbers for various PoW chains is at crypto51.app.

4. Live regtest demo #

The audit script audit-51-attack-sim.py reproduces a full reorg end-to-end on a local regtest network. It is short (about 12 seconds) and prints a step-by-step educational commentary.

What the demo does

  1. Spawns two completely isolated regtest clusters: one honest (Alice the miner, Bob the victim) and one attacker (Mallory).
  2. Both clusters mine 110 blocks privately to get spendable coinbase outputs.
  3. On the honest chain, Alice sends Bob 25 B3C; Alice mines 6 more blocks — from Bob's view the payment has 6 confirmations and is "safe".
  4. The attacker secretly mines 8 blocks from the same parent, replacing Bob's payment with a payment to Mallory's own address.
  5. The clusters are connected. The honest node sees the attacker's chain has more work and switches to it.
  6. Bob's wallet shows a 0-confirmation (or "conflicted") balance. The funds are gone.

Run it

cd b3chain
python3 contrib/testing/audit/audit-51-attack-sim.py

Annotated expected output

========================================================================
  51% ATTACK SIMULATION (regtest, educational)
========================================================================
   ⓘ  ... educational explanation ...

[step 1] Spawning isolated honest + attacker clusters
[step 2] Both clusters mine 110 blocks (need spendable coinbase)
              honest cluster: height=110  tip=...
              attacker cluster: height=110  tip=...

[step 3] On the HONEST chain Alice pays Bob 25 B3C, miner mines 6 confirmations
     honest payment txid     : 0a...
     Bob balance after 6 confirms: 25.0 B3C
  PASS  [A-1] Bob's payment is confirmed >=6 times on the honest chain

[step 4] In SECRET the attacker mines 8 blocks (reach honest height + lead)
     attacker self-pay txid  : b1...
              attacker cluster: height=118  tip=...

[step 5] ATTACKER REVEALS the longer chain (connect honest <-> attacker)
  PASS  [A-1] honest node reorged onto attacker chain (more PoW wins)

[step 6] Verify Bob's payment is REVERSED
  PASS  [A-1] Bob's transaction has 0 or negative confirmations after reorg
     Bob balance before reorg: 25.0 B3C
     Bob balance after reorg : 0.0 B3C
  PASS  [A-1] Bob's wallet balance decreased after the reorg

========================================================================
  RESULT: Bob has been double-spent
========================================================================
   ⓘ  A 51%-capable attacker reversed a 6-confirmation transaction.
   ⓘ  ... defence guidance ...

------------------------------------------------------------------------
  4/4 checks passed in 12.2s
AUDIT RESULT: PASS  [A-1]

5. How b3chain helps #

  • BLAKE3 PoW. Bitcoin's SHA-256 ASIC industry has produced very concentrated hashrate. BLAKE3 is new enough that no large-scale ASIC line exists, so early b3chain hashrate is unlikely to be dominated by a single industrial farm. This advantage erodes as the chain matures — eventually BLAKE3 ASICs will exist.
  • Conservative consensus. No exotic proof-of-stake or finality gadget that could open new attack surfaces. The only PoW behaviour change is the algorithm itself.
  • Public test corpus. Every consensus invariant has an automated audit (this site). A regression that, e.g., accepted the wrong PoW hash would be caught by H-1 before reaching mainnet.

6. How users defend themselves #

  • More confirmations for high-value payments. The Nakamoto table above is the only protection against a determined 51%-capable attacker. For a payment worth $1 000, six confirmations is industry standard. For $1 000 000, wait twenty. For $100 000 000, wait until the network is mature.
  • Watch for reorgs. Run a node and subscribe to ZMQ block-disconnect notifications. Block explorers also surface reorgs.
  • Hot wallet hygiene (exchanges). Limit hot-wallet float; require multiple-confirmation cooling-off for deposits; suspend deposits during hashrate drops.
  • Treat unknown senders carefully. A reorg-only attacker usually targets a specific recipient (an exchange listing). If you are an unknown wallet, you are not the target.

7. Source files

The problem in one sentence

A miner with majority hashpower can always re-write recent history; the question is "how recent" and "at what cost", and the answer is testable on regtest with the demo here.

The theory (Nakamoto's race)

If the attacker controls fraction q of total hashpower (p = 1 - q honest), the probability of catching up from z confirmations is:

\[ P_z = \left( \frac{q}{p} \right)^z \quad \text{for } q < p \]

For q < 0.5 this decays exponentially in z. For q ≥ 0.5 it is 1 — the attacker wins eventually, with high probability.

Practical confirmation thresholds (Satoshi 2008, simplified):

| q (attacker share) | confirmations for P_z < 0.001 | |--------------------|-------------------------------| | 10% | 6 | | 20% | 11 | | 30% | 24 | | 40% | 89 | | 49% | thousands (impractical) |

Hands-on demo

python3 contrib/testing/audit/audit-51-attack-sim.py

The script:

  1. Spawns two isolated regtest clusters (3 nodes each):

"honest" and "attacker".

  1. Honest cluster mines 100 blocks; attacker mines 99 from the same

parent in private.

  1. Honest cluster sends a transaction to a third party, gets 6

confirmations.

  1. Attacker secretly mines 7 more blocks (8 total > honest's 6),

double-spending the same UTXO to an attacker-controlled address.

  1. Attacker reveals the longer chain. Both clusters reorganise.
  2. The original tx is reversed; the attacker's double-spend is now

in the canonical chain.

  1. Output: blocks reorganised, time elapsed, hashrate ratio required.

The demo runs in ~30s on regtest. On mainnet at typical difficulty, the same scenario would cost many millions of dollars in compute time and electricity — that's the gap that keeps Bitcoin safe.

Exercise: the cost calculator

Open the script. The attacker_hashrate_ratio parameter controls how much faster the attacker mines than the honest cluster. With ratio=2.0 (attacker has 2/3 of total hashpower), the attack finishes in ~10s on regtest. With ratio=1.05 (attacker has barely 51%), the attack still always succeeds but takes much longer in expected wall time.

Try:

python3 contrib/testing/audit/audit-51-attack-sim.py --ratio 1.05 --timeout 600

You should see the attack succeed but take hundreds of seconds, matching the exponential decay above.

What protects B3Chain

Three layers, in increasing order of importance:

  1. BLAKE3 PoW reduces ASIC concentration risk in early days. The

cost-of-attack at launch is bounded by GPU/CPU rental rates, which are diffuse. Bitcoin's SHA-256 ASIC market is concentrated in 5 companies; those companies could (in principle) repurpose hardware to attack a SHA-256 fork from day one. BLAKE3 doesn't have that problem yet.

  1. Conservative confirmation defaults. Wallets and exchanges should

require more confirmations for high-value B3Chain transactions in year one, until total hashrate grows enough that the cost-of-attack is high.

  1. Checkpoint key ceremony (planned, see

SECURITY-ROADMAP.md). Trusted maintainers sign post-launch checkpoint hashes; nodes can opt in to refuse reorgs deeper than the most recent checkpoint. Centralising in a way, but the recovery option exists if a sustained attack appears.

What does NOT protect against 51%

  • "Just keep upgrading the difficulty algorithm" — doesn't help; the

attacker also benefits from the higher difficulty.

  • "Detect the attacker by IP" — they're using cloud rental and

rotating IPs.

  • "Charge a fee for reorgs" — there's no protocol mechanism to do this

generically.

  • "Switch to PoS" — different security model; B3Chain is committed to

PoW.

Further reading

  • Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System",

section 11 ("Calculations"): bitcoin.org/bitcoin.pdf

  • Eyal & Sirer, "Majority is not Enough: Bitcoin Mining is

Vulnerable" (selfish mining attack): arxiv.org/abs/1311.0243

  • Bonneau et al., "SoK: Research Perspectives and Challenges for

Bitcoin and Cryptocurrencies" (2015 IEEE S&P): cseweb.ucsd.edu/~smeiklejohn/files/ieeesp15.pdf

  • Ethereum Classic 51% attacks (2019, 2020) — real-world examples of

the cost-of-attack curve at small chain sizes.