Why blocks collide
Two miners can finish a block seconds apart. Watch what a single chain throws away, and what a blockDAG keeps instead.
Opens at Kaspa's real rate, 10 blocks a second, with propagation set to 500 ms. No published measurement of real Kaspa block propagation exists to cite, so 500 ms is a representative estimate, the midpoint of this slider's own range, not a measured figure; real propagation varies with peer distance and network conditions. The slider's top end, 5 seconds, is NETWORK_DELAY_BOUND, rusty-kaspa's own worst-case network delay bound: the assumption the protocol is built to tolerate, well above what real propagation should take.
Single chain so far: 0 kept, 0 thrown away
BlockDAG every block kept
How this works, and the sources
Blocks arrive at random, like raindrops: a Poisson process with rate λ. A block collides with the one before it if the next block is found before the first one finishes spreading across the network, which takes time d. That gives a plain formula for how often a given block collides with at least one other:
That collision probability is not the number this page leads with. Once a single chain keeps a block, it will not accept anything that arrives before that block finishes propagating, so a run of colliding blocks only ever keeps the first and discards the rest, the same way a non-paralyzable dead-time counter drops any event landing inside its recovery window without extending that window. Working through that identity gives a lower share than p:
Inferred from the dead-time-counter identity above, matching this simulator's own discard rule rather than quoted from a source. At Kaspa's defaults, λd = 5, so p works out to about 99% while the discarded share is about 83%, which is the figure the running tally above converges toward.
A single chain can only keep one block per collision, so the loser's work is wasted. A blockDAG references every block a miner could see when it started working, so both survive and get ordered instead of discarded.
Where this comes from. Block creation as a Poisson process of rate λ, and network propagation delay as the thing that causes concurrent blocks, are exactly the model in Sompolinsky, Wyborski and Zohar's PHANTOM/GHOSTDAG paper (eprint.iacr.org/2018/104): "Block creation follows a Poisson process with parameter λ," bounded by a network delay diameter D. Verified against that primary source. The paper's own math goes further than this demo: it bounds how many blocks can be created within a delay window (the anticone size k, used to tune GHOSTDAG itself), via a Poisson-tail formula in D·λ. This page's p = 1 − e−λd is the simpler building block underneath that: the chance at least one more block arrives before the first one finishes propagating, which is standard Poisson-process math (P(0 arrivals in time d) = e−λd) and matches the same collision mechanism used in the Bitcoin fork-rate literature (Decker & Wattenhofer, Information Propagation in the Bitcoin Network, IEEE P2P 2013). Inferred from that Poisson identity rather than quoted directly from either paper. This demo simplifies further by testing only whether a block collides with the immediately preceding one, not the full multi-block anticone GHOSTDAG actually resolves; it is a simplification of the source math, not the source math itself.
Playback speed scales with the rate instead of landing every setting at the same pace: a real Bitcoin block, on average one every 10 minutes, plays back roughly every 6 seconds here, about a hundredth of real time, so the wait still feels slow rather than reading as a label. Kaspa's real rate, ten a second, plays back close to real time, because a 100ms block is already watchable as itself. The collision math above always uses the real rate and delay, not the playback speed; only what you see on screen is sped up or slowed down for legibility.
Respects reduced-motion: turns into a manual step button instead of continuous animation.