Simulations

These simulators compute real hashes in your browser. Nothing here is pre-recorded, and nothing touches a live network or your keys.

Distributed network — four nodes, one coin, no referee

genericApplies to both networks

Broadcast conflicting spends across a four-node network with adjustable delay, partition and a dishonest participant. Watch local histories diverge.

  • Broadcast a single honest payment and confirm all four nodes converge
  • Broadcast two conflicting spends from opposite ends and record which nodes disagree
  • State the property whose absence caused the disagreement

Distributed network simulator · educational model

Four-node payment network · Alice holds 1 coin-A1

Low latency, no partition, honest participants.

t = 0idle

Node 1 · Alice

no spend of the coin seen yet

Alice: 1 · Bob: 0 · Charlie: 0

local history

empty

Node 2 · Bob (merchant)

no spend of the coin seen yet

Alice: 1 · Bob: 0 · Charlie: 0

local history

empty

Node 3 · Charlie

no spend of the coin seen yet

Alice: 1 · Bob: 0 · Charlie: 0

local history

empty

Node 4 · Auditor

no spend of the coin seen yet

Alice: 1 · Bob: 0 · Charlie: 0

local history

empty

in-flight messages: 0

    event log

    • nothing yet

    Signature Blockchain Simulator — 10 linked blocks

    bitcoinBitcoin model — UTXO, PoW, nonce, difficulty, subsidy

    Start from a fully valid chain. Edit a historical transaction and watch detection propagate forward.

    • Edit a transaction in an early block and identify every field that changed
    • Recalculate only that block and explain why the chain is still invalid
    • Re-mine from that block to the tip and state what this would cost in a real network

    Simulation

    Signature Blockchain Simulator — genesis to block 10

    Every block is valid to begin with. Edit a historical transaction and follow the damage forward.

    Block 4 header
    block number
    4
    timestamp
    2026-01-01T00:40:00Z
    previous block hash
    0002cf4345360d81382014bdd8c70ef934e60d34f7d702979d0414eb739c6346
    merkle root
    754f1a97d5fd914f85b62d2665dbdefc042458b7bde51b205ff977cd22a27db4
    nonce
    2283
    difficulty / target
    3 leading hex zeros
    block header hash
    000049c431ab7e6467a938e9d0fdc16695b815e2b8d2f700810b0872e76e3233

    Transactions in block 4 — editable

    Change any character: the Merkle root changes, then the header hash, then block 5’s previous-hash reference stops matching.

    Hash linkage detects inconsistency. Which history a distributed network actually accepts is decided by consensus — cumulative work plus the most-work chain rule — not by the hash function. Hashing alone never makes history impossible to change.

    Mempool and block capacity

    bitcoinBitcoin model — UTXO, PoW, nonce, difficulty, subsidy

    Build a candidate block from a pending pool with finite capacity.

    • Fill a block by fee rate
    • Add a conflicting transaction and observe validity
    • Leave a low-fee transaction pending and explain why

    Simulation

    Mempool and finite block capacity

    Pending transactions compete for limited space. Fee rate — not arrival time — drives selection.

    Pending transaction pool (fee-rate sorted)

    tx idsenderrecipientamountsizefeefee ratespendsstatus
    tx-f6kiranlata0.15200 vB31.0utxo-6pending
    tx-b2caroldave1.1400 vB30.0utxo-2pending
    tx-d4gitahari2.5300 vB30.0utxo-4pending
    tx-a1alicebob0.4250 vB20.0utxo-1pending
    tx-e5ivanjane0.8500 vB7.0utxo-5pending
    tx-c3evefrank0.02220 vB2.0utxo-3pending

    Candidate block — capacity 1200 vB

    0 / 1200 vB used

    • No candidate built yet.
    Low-fee transactions stay PENDING — they are not invalid. Two transactions spending the same output are mutually exclusive: at most one can be confirmed against the accepted history.

    Proof-of-work with competing miners

    bitcoinBitcoin model — UTXO, PoW, nonce, difficulty, subsidy

    Three miners search independently. Watch a winner publish and the others rebuild.

    • Raise difficulty and observe attempt counts
    • Explain why verification stays cheap

    Simulation

    Proof-of-work with competing miners

    Three miners build DIFFERENT candidate blocks on tip 120 and search independently.

    shared candidate header inputs

    height     121

    prev hash fa7d0a3908d2b7b97c87c4a180210d5986dcda70ff9bcf7611711b72035f8b8f

    target     4 leading hex zeros

    No winner yet. Attempt counts below rise roughly with 16difficulty.

    Miner Aidle

    tx set: tx-b2, tx-d4, tx-f6 · extraNonce A-0x91

    attempts 0

    awaiting start…

    Miner Bidle

    tx set: tx-b2, tx-f6, tx-a1 · extraNonce B-0x4f

    attempts 0

    awaiting start…

    Miner Cidle

    tx set: tx-d4, tx-a1, tx-e5 · extraNonce C-0xe7

    attempts 0

    awaiting start…

    The nonce is not 'the puzzle'. The puzzle is finding ANY block-header input whose hash falls below the current target. Because each miner has a different transaction set, timestamp and extraNonce, they explore different search spaces — there is no globally coordinated nonce sequence. Producing a valid header is expensive; verifying one is a single hash.

    Double-spend under network delay

    bitcoinBitcoin model — UTXO, PoW, nonce, difficulty, subsidy

    Alice spends the same output to Bob and to Charlie. Different nodes see different transactions first.

    • Confirm one branch
    • Explain why the other transaction becomes invalid
    • Increase confirmation depth and describe the risk change

    Simulation

    Double-spend under network delay

    Alice holds ONE spendable output worth 1.0. She signs it to Bob (TX-A) and to Charlie (TX-B).

    Conflicting transactions

    TX-A · alice → bob 1.0 · spends utxo-alice-1 · signature valid
    TX-B · alice → charlie 1.0 · spends utxo-alice-1 · signature valid

    What each node saw first

    Node 1 (near Bob)
    Node 2 (relay)
    Node 3 (mining pool)

    With propagation delay, honest nodes genuinely disagree about what is pending. No node is faulty.

    Accepted history

    Nothing confirmed yet. Both spends are pending somewhere; neither is settled.

    Both transactions are authentic and correctly signed. Cryptography cannot choose between them — only an agreed ordering can. This is precisely why distributed ordering exists.

    Sybil identities vs costly participation

    genericApplies to both networks

    Compare one-identity-one-vote against work-weighted influence.

    • Scale the attacker to 1,000,000 identities
    • Switch to work-weighted mode and compare

    Simulation

    Sybil identities vs costly participation

    One attacker, many names. Compare a network that counts identities with one that counts a costly resource.

    Attacker creates

    Cost of an extra identity on an open network: essentially zero. Cost of extra hash power: hardware plus electricity, continuously.

    honest influence30
    attacker influence1
    attack does not scale

    Identity counting collapses as soon as identities are free to create.

    Proof-of-work makes influence cost a scarce resource, so extra identities buy nothing. It is resistance to cheap identity creation — not human identity verification, and not proof that a participant is honest.