Which Bitcoin pool tells its miners about a new block first?
Continuous str_race.py measurement
of mining.notify arrival times across public stratum endpoints.
Lower is better — slow notifications mean hashing stale work.
| # | Pool | Median | Offset (ms) | Avg | P95 | Best | Wins | Win % | Empty 1st | Races | Status |
|---|
| Height | Time (UTC) | Found by | First full template | Empty jump-start | Runner-up | Gap (ms) | Spread (ms) | Pools |
|---|
A server holds persistent stratum connections to every pool listed. When a new Bitcoin block is found,
each pool pushes mining.notify with a fresh prevhash and clean_jobs=true.
The first pool to deliver it wins that race; every other pool is timed as an offset (in milliseconds) behind the winner.
Rankings use the median offset across all observed blocks, so a single lucky or unlucky block doesn't move a pool much.
Empty templates: some pools broadcast an empty template the instant a block is found — a job containing only the coinbase transaction, no transaction selection or validation — and send the full template seconds later. Racing on "first notify" would flatter that strategy, so rankings here use each pool's first non-empty template. All pools are still shown; the Empty 1st column reports how often a pool led with an empty template, and each block's earlier empty notify (if any) appears as Empty jump-start.
A win means this client observed that pool first from this network vantage point — it is not proof that the pool globally won block propagation. Results depend on geography, routing, DNS, and pool backend behavior. Sub-millisecond differences in a single race are noise; medians over many races are the signal.
Vantage point: