Four real mining pools, each a glass cube holding its own copy of the UTXO state, with a pool of transactions, a tower of blocks and a worker who builds, checks and cranks each candidate block by hand. Click a node to look closer.
Newest first. Each block row shows how many nodes have that block in their tower; network events sit between the blocks.
Real: the chain tip and its parents, the four pools and their 1-week share of blocks, network hashrate, difficulty and nBits. The 28 starting transactions are real mempool transactions, carried as their raw bytes with the coins they spend. Your browser recomputes every txid and verifies every signature: legacy and SegWit ECDSA (with the legacy and BIP143 sighash) and Taproot Schnorr (BIP340/BIP341), plus the check that each public key hashes to the locking script. SHA-256 is a full implementation; the button above reproduces the real tip's block hash.
Simulated, but real format: when the real transactions are mined, simulated wallets keep sending. Each simulated transaction is a genuine P2WPKH transaction, signed with the wallet's own secp256k1 key and verified exactly like the real ones. It spends coins those wallets hold, including outputs of earlier simulated blocks. Coinbases are serialized for real, and their txids and the merkle roots are computed for real.
The node cubes: each cube is that node's own view of the UTXO set: every coin it knows about, placed by the address (locking script) that owns it and sized by its value. When a block is connected, the coins its transactions spend disappear and the new outputs appear, with a thin thread from each spent coin to each new one; the coinbase threads start at the gold mint at the top. A node on a losing fork briefly shows a different state until it reorgs.
Network model: each node keeps its own mempool and checks every transaction against its own chain tip before passing it on. Signature results are cached, as Bitcoin Core does. Double-spends follow full RBF: first seen wins unless the newcomer pays enough more. Nodes follow the branch with the most cumulative work, so forks and reorgs happen naturally and show up in each node's tower.
Scaled down: the real target needs about 78 leading zero bits (roughly 6 × 1023 hashes per block). Here each turn of a worker's handle is one real SHA-256d of the full 80-byte header, with the nonce limited to 0–100 for illustration (the real field runs to about 4.3 billion). When 0–100 is used up, the worker changes the extranonce in the coinbase, which gives a new merkle root, and starts again at 0. A block counts when its hash has at least the demo target of leading zero bits (5 by default; adjustable). Bigger pools turn their handle faster, in proportion to their share of hashrate. The header still carries the real nBits. Blocks hold up to 12,000 weight units instead of 4,000,000. Script-path Taproot, multisig and other script types are not verified by this page; none appear in the snapshot.
Live data: opened as a standalone .html file, the page fetches mempool.space directly and polls for new real blocks; every node then reorgs onto the real chain because it carries vastly more work. Inside the Claude desktop app, “Pull live data” uses the app's browser.
Reading the scene: the worker opens the candidate block, lets transactions stream in from the pool, checks each one on the clipboard, then hashes the txids into a merkle root; the gold cord ties the block to the hash of the previous block. Each turn of the handle writes a new nonce; the readout prints the hash (leading zeros in gold) and the column counts its leading zero bits against the target line. Pool transactions are coloured by fee rate: pale blue under 1 sat/vB, green 1–2, yellow 2–5, orange 5 and up; a double-spend pair is pink and purple. In each tower the newest block sits on the cube and older ones stack above it, then … for the blocks not shown and G, the genesis block (#0); the grey blocks are the real chain tip and its parents, and a reorged block tips off the stack. In a cube, dotted threads belong to the block being built (green once checked); a wallet's coins match the colour its owner wears, real-world addresses are muted by script type and coinbase coins are gold; each cube draws at most its newest 320 coins. Twelve simulated wallets stand on the wallet platform; click a person to flash their coins red in every cube. The chip in the header says whether the page runs on the built-in snapshot or on live data.
The whitepaper §5 board: Satoshi's six steps for running the network. Each lights up when it happens on screen: the step the node named on the board is doing now is lit gold and marked NOW, a step that just happened at any node gets a grey outline, and the line under the steps says what that node is doing. “Follow along” walks the camera through the steps with one node. §5 also: nodes always consider the chain with the most proof-of-work to be the correct one. If two blocks arrive at once, nodes work on the first one they received but keep the other in case its branch grows longer. §4 proof-of-work: increment a nonce until the block's hash falls below a target. The average work grows exponentially with the zero bits required, and anyone can verify it with one hash. §2 transactions: each owner transfers a coin by digitally signing a hash of the previous transaction and the next owner's public key. Nodes check those signatures.