A new block does not reach every node instantly — it is relayed peer-to-peer ("gossip") across the network graph, one hop at a time. Each hop costs a fixed base latency plus the time to transmit the block's bytes over that link:
t_hop = latency_base + block_size / bandwidth
t_propagate ≈ diameter(network) × t_hop
If another miner finds a competing block before the first one has fully propagated, the network temporarily disagrees and one branch is later discarded ("stale"/orphaned). The chance of that race grows with the propagation time relative to the average time between blocks — this simulator uses the standard first-order approximation (Decker & Wattenhofer, 2013):
P(stale) ≈ 1 − e^(−t_propagate / T_block)
Bigger blocks carry more transactions per block (higher raw capacity) but take longer to propagate, so realised throughput has to discount for wasted, orphaned work:
throughput ≈ (block_size / avg_tx_size) / T_block × (1 − P(stale))
This is the core of the real block-size debate in Bitcoin-like networks: larger blocks raise raw capacity but also raise orphan risk and favour whichever miners have the fastest network links — a genuine security/decentralisation trade-off, not just a knob you can turn for free.
Header hash panel: real chains bind a block's contents to a short digest (SHA-256, Keccak, …) via a cryptographic hash function. This demo uses a simplified toy hash (not cryptographically secure) purely to show the avalanche effect that any real hash function must have: changing the nonce by 1 flips roughly half the output bits, which is exactly why searching for a valid proof-of-work hash cannot be shortcut — every guess is effectively independent.
- Block size / bandwidth — set the per-hop transmission cost.
- Target block interval — the average time between new blocks (mining difficulty target, abstracted).
- Auto-mine — schedules new blocks as a Poisson process at the target interval, compressed by the simulation-speed slider.