Why ten-minute blocks: what faster blocks cost every node and wallet, measured

Where ten minutes comes from

The whitepaper mentions the interval once, in Section 7 on reclaiming disk space:

A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, Section 7, 2008. The whole paper, section by section: the Bitcoin whitepaper.

The reasoning is in Satoshi Nakamoto's correspondence. Answering James A. Donald on the Cryptography Mailing List, who had asked whether the network could generate coins slowly enough for news of each to flood the network first:

Sorry if I didn't make that clear. The target time between blocks will probably be 10 minutes.

Satoshi Nakamoto, Cryptography Mailing List, 10 November 2008

Four days later, to Hal Finney and James A. Donald on the same list, on what happens if broadcasts are slow:

If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.

Satoshi Nakamoto, Cryptography Mailing List, 14 November 2008

In December 2010 Mike Hearn asked him privately where the ten-minute target came from, since large peer-to-peer networks such as BGP could spread new data worldwide in under a minute. The reply, from emails Hearn later published:

If propagation is 1 minute, then 10 minutes was a good guess. Then nodes are only losing 10% of their work (1 minute/10 minutes). If the CPU time wasted by latency was a more significant share, there may be weaknesses I haven't thought of. An attacker would not be affected by latency, since he's chaining his own blocks, so he would have an advantage. The chain would temporarily fork more often due to latency.

Satoshi Nakamoto to Mike Hearn, "More BitCoin questions", 29 December 2010

He set the interval against the time a block takes to spread and worked out the work lost from the two, a tenth at one minute. The whitepaper treats its numbers the same way, from the 4.2 MB a year of headers in Section 7 to the attacker's odds in Section 11. The same arithmetic at faster intervals gives 42 MB of headers a year at one minute, 168 MB at fifteen seconds and 2.5 GB at one second.

So ten minutes is a ratio: the interval set well above the time a block needs to reach every miner, so that little work is lost and an attacker, who never waits for his own blocks, gains little from the delay. The ratio has a cost side as well. Every block carries a fixed cost that every node and light wallet pays for as long as the chain runs, so a faster interval raises the infrastructure cost of the whole network, while a chain that already prevents double-spending before a block is found gains nothing certain or measurable in return. Everything below follows from that ratio.

Stale blocks: the time a block takes to spread

Mining is a race with no starting gun. While a new block is still travelling, another miner who has not yet seen it can find a competing block at the same height. Both are valid; the network keeps one and the other becomes stale, its work wasted. Decker and Wattenhofer measured this on Bitcoin in 2012: a block reached half the network in 6.5 seconds on average (median), 12.6 seconds mean, and 5% of nodes still had not received it after 40 seconds. Of 10,000 blocks, 169 forked, a rate of 1.69%, and their model, the chance of a competing block during the time a block is spreading, predicted 1.78%. They also put a price on it: the work wasted on each fork lowered the share of hashrate an attacker needed to overtake the chain from 50% to 49.1%.

Propagation has improved since. Compact block relay sends a block as short transaction IDs the receiver already has in its mempool. A 2021 measurement by Fechner, Chandrasekaran and Makkes, published in 2022, found a median of 0.45 seconds for Bitcoin, more than ten times faster than in 2012, a mean of 4.1 seconds, and 5% of nodes still waiting after 15.8 seconds. Over 50 days they counted these fork rates:

Dogecoin's blocks were smaller than Bitcoin's and spread almost as fast, yet it forked about eight times as often: with a block every minute, the same delay is a ten times larger share of the interval. Bitcoin's stale blocks are still counted by volunteers in the stale-blocks dataset: 28 in 2022, 70 in 2023, 49 in 2024, 93 in 2025 and 61 in 2026 to 4 November, between 0.05% and 0.2% of blocks a year, a floor since only blocks its contributors' nodes saw are listed.

The propagation budget: interval and block size share it

The chance that a block goes stale is about 1 − e^−d/T, where d is the time it takes to reach the other miners and T the block interval. Fix the share of work a chain is willing to waste, and the interval sets how long a block may take to arrive. At 1%:

The figures follow from the formula; 15.8 seconds is the slowest 5% of Bitcoin nodes in the 2021 measurement. Two limits sit under them. Light in optical fibre covers about 200,000 km a second, so a block needs at least a tenth of a second to cross half the planet, before any router, any hop between nodes or any check of the block. At fifteen-second blocks that alone uses most of the 1% budget. And the budget is the same one block size draws on: every extra kilobyte takes time to send and to check at each hop, which in 2012 cost 80 milliseconds per kilobyte. A chain at ten minutes has six seconds to spend on bigger blocks. A chain at one minute has spent most of its 0.6 seconds on distance and has little left for data.

The loss does not fall evenly. A large pool finds many of its own blocks and builds on them at once, with no delay; a small miner on a slow connection is always the last to hear. At one-minute blocks a miner whose blocks arrive 15.8 seconds late loses nearly a quarter of them; at ten minutes, 2.6%. Faster blocks pay well-connected pools more than everyone else, which is the pressure towards fewer, larger pools that the grade's pool diversity measure counts against. Wasted work also lowers the cost of attack, as Decker and Wattenhofer found and Satoshi foresaw, and Gervais and colleagues showed that a higher stale rate raises what a selfish miner earns.

Many small blocks are not one large block cut up

Ten one-minute blocks carry no more transactions than one ten-minute block, but they cost more in bandwidth, storage, processing and time, and they take longer to spread. Each block is its own message, handled whole at every hop: announced to each peer, requested, its missing transactions fetched, checked, and only then passed on. With compact block relay that takes at least half a round trip per hop, and one and a half when the receiver lacks a transaction, before any check, and a round trip between continents takes up to 300 milliseconds. That part of the delay depends on distance and on the number of hops, not on size, so a smaller block does not spread proportionally faster: in the 2021 measurement, Litecoin's and Bitcoin Cash's blocks, far smaller than Bitcoin's, still took 0.08 and 0.13 seconds to reach the median node, and Dogecoin's 0.18.

From those medians, a Bitcoin block reached the median node in 0.45 seconds, about 0.08 of it the fixed part. Ten blocks of a tenth the size each pay the fixed part again, about 0.12 seconds apiece, 1.2 seconds in all: about 2.6 times as long to spread the same transactions, and the share of each interval spent spreading rises from 0.075% to 0.2%. The better relay gets at sending the bytes, the more of the delay is the fixed part, and the closer that ratio comes to ten.

The same transactions, carried at faster intervals, set against ten-minute blocks. Spreading time uses the 2021 medians above; fixed data uses the bytes every block costs, measured in the next section:

At first a faster chain feels smooth: a young chain is small, its nodes catch up in minutes, and an extra hundred megabytes goes unnoticed. The burden grows with every block and is never paid off. A one-minute chain carries 178 MB more fixed data than a ten-minute chain after one year, 1.8 GB after ten and 3.6 GB after twenty, on every node, and every node that joins later downloads and checks all of it. The time spent spreading and the share of work lost are paid again on every block, for as long as the chain runs.

Over months and years the per-block delays add up. The table counts, for the same transactions, the time during which a new block had not yet reached half the nodes, and the time it had not yet reached 95% of them. It takes the reading most favourable to faster blocks: that the slow tail shrinks with the block, from the 15.8 seconds Bitcoin's full blocks took to reach 95% of its nodes down to 1 second, the time Litecoin's and Bitcoin Cash's small blocks took.

Dogecoin, a one-minute chain, checks the estimate: 5% of its nodes waited more than 3.2 seconds for each block in 2021, about 19 days a year in all, against the 15 days estimated here. At ten-minute blocks the network spends 0.08% of its time with a block still on its way to half the nodes; at fifteen seconds, 0.6%. In each of those hours some miners work on a block that has already been beaten, and the same hours are added again every year.

Copying files works the same way: a thousand small files take longer than one file of the same total size, because each carries its own lookup, metadata and write. A node pays its share per block: a header to check, an index entry and undo data to write, a chain tip to update and every peer to tell. Ten times the blocks is ten times those steps, whatever the blocks carry. The next section measures their bytes.

The fixed cost of a block, measured

Every block costs the same before it carries a single payment: an 80-byte header, which every node and every light wallet downloads, checks and keeps; a coinbase transaction, which every full node downloads and every archival node keeps; and an entry in the node's block index, kept even by pruned nodes. These were measured on 9 November 2026 from each chain's own nodes, over its peer-to-peer protocol: headers asked for 2,000 at a time and weighed as they arrived, the last 30 blocks of each chain read whole, and the block index of a Bitcoin Cash Node weighed on disk.

Dogecoin is merge-mined with Litecoin, so each of its headers carries an AuxPoW proof: Litecoin's coinbase transaction, two Merkle branches and Litecoin's header. Its headers measured 503 bytes around block 400,000 and 847 bytes around block 6,000,000, growing as Litecoin's coinbase grows. A scrypt chain's proof of work also costs far more to check: one scrypt hash took 823 microseconds on the server that ran these measurements, against 9 for SHA-256d.

The header chains today

A light wallet that checks the chain from the start, the simplified payment verification of the whitepaper's Section 8, downloads every header. Multiplied out at each chain's height on 9 November 2026:

Bitcoin, seventeen years old, has 78 MB of headers. Dogecoin, nearly thirteen, has 4.4 GB, more than fifty times as much: ten times the blocks, each ten times the size. DigiByte, at fifteen seconds, has 25 times Bitcoin's block count in less time. Many light wallets for these chains do not check from the start; they begin from a checkpoint built into the app and trust the developer for everything before it, which is the verification the header chain exists to give.

What that means for a phone. A light wallet syncing from the first block asks for headers 2,000 at a time, each batch after the last has arrived, so every batch costs a round trip, the bytes, and a check of each header's proof of work. On a 20 Mbit/s mobile connection with 150-millisecond round trips, and on a 2 Mbit/s one with 300 milliseconds, with SHA-256 headers checked at the measuring server's 9.4 microseconds and scrypt headers at its 823:

At eight years a ten-minute chain syncs in under a minute on a good connection and a few minutes on a poor one; a one-minute chain takes ten times as long, half an hour at eight years on a slow connection, before the wallet can show a single payment as confirmed. The phone keeps ten times the headers in storage, and the whitepaper's light client keeps them in memory. On a scrypt chain the checking alone takes nearly an hour of a server core at eight years, and a phone is slower. The weight falls hardest where the connection is slowest and the phone cheapest.

Year after year: the cost that never goes away

The fixed part of a block is paid whether the block is full or empty, and it is never paid off. Headers cannot be dropped by a node that checks the chain, a pruned node keeps every header and index entry, and every node that joins later downloads and checks all of them. With Bitcoin Cash's measured figures, 80 bytes of header, 149 of coinbase and 148 of index a block:

The growth is linear in years but it compounds in who pays. Each year's blocks are added to what every future node must download and check, so a wallet installed in twenty years inherits twenty years of headers. The cost does not depend on use: a one-minute chain with no payments at all still writes 526,000 blocks a year. And it sits on top of the transactions, which a faster chain carries in the same total bytes as a slower one. Shortening the interval adds overhead without adding capacity; raising the block size adds capacity without adding overhead.

For a scrypt chain the checking compounds too. At 823 microseconds a header, a year of ten-minute blocks takes 43 seconds of one core to verify; a year of one-minute blocks, seven minutes; a year of fifteen-second blocks, half an hour. On a phone, several times that.

Do faster blocks make payments faster?

A block every minute gives a first confirmation sooner, but a first confirmation on a faster chain carries less work behind it, and those who take large deposits count work, not blocks. Kraken's deposit page, updated 22 October 2026, asks for 3 confirmations of Bitcoin, which it puts at about 45 minutes, 12 of Litecoin (30 minutes), 40 of Dogecoin (40 minutes) and 15 of Bitcoin Cash (150 minutes). Three blocks take 30 minutes on average, but block times vary, and three take longer than 45 minutes about one time in six, so the estimate covers the usual spread. Bitcoin Cash asks for more because its miners use the same SHA-256 hardware as Bitcoin's, a network with many times its hashrate. Binance releases deposits for withdrawal after 2 confirmations of Bitcoin, 15 of Litecoin, 36 of Dogecoin and 50 of DigiByte. In Gervais and colleagues' 2016 analysis, matching six Bitcoin confirmations against an attacker with 30% of the hashrate took 28 Litecoin confirmations (70 minutes) and 47 Dogecoin confirmations (47 minutes) against Bitcoin's 60. Faster blocks shorten the wait for a deposit modestly at best; the number of confirmations follows the cost of an attack, not the block count.

For everyday payments the interval matters less than how a chain treats a payment before it is mined. On a chain where nodes keep the first version of a transaction they see and relay proof of any attempt to double-spend it, as Bitcoin Cash does, a payment is accepted in seconds, the fast payments the grade checks for, and no one waits for a block. On a chain that lets an unconfirmed payment be replaced by a higher fee, the replace-by-fee rule, the receiver has to wait for a block, and there the interval is the wait.

The case for faster blocks, against the measurements

Two arguments are made for faster blocks. Gervais and colleagues simulated one-minute blocks of 1 MB and found the stale rate did not rise substantially, and propagation is faster than when Satoshi chose ten minutes. A proposal before Bitcoin Cash, CHIP-2025-03, would move it to one-minute blocks, expecting stale rates below 2% across its modelled conditions and headers growing from 4.2 to 42 MB a year, with a companion proposal to let wallets keep a fixed number of headers.

Neither changes the measurements above. One-minute blocks of 1 MB spread quickly because they are small; the propagation budget above caps how large they can become. Fast propagation today is the work of compact block relay and well-connected pools; a miner on an ordinary connection still sits in the slow tail, where one-minute blocks cost a quarter of its work. And a wallet that keeps a fixed number of headers has to trust a checkpoint for the rest. None of it lowers the fixed cost: ten times the blocks is ten times the headers, coinbases and index entries, for every node, for as long as the chain runs. Ten minutes is the interval at which that cost stays negligible on any computer, wasted work stays near zero on ordinary connections, and blocks keep room to grow. The chains show it: Bitcoin and Bitcoin Cash forked on 0.015% and 0.014% of blocks and keep 78 MB of headers after seventeen years, while Dogecoin, at one minute, forked eight times as often and keeps 4.4 GB. On a chain that accepts payments in seconds, a faster block buys nothing those figures could be weighed against.

What the measurements show

• The same transactions at one-minute blocks cost every node ten times the fixed data, 198 MB a year against 20 MB, and take 160% longer to spread to half the nodes.
• Dogecoin, at one minute, forked on 0.127% of blocks in 2021; Bitcoin and Bitcoin Cash, at ten, on 0.015% and 0.014%.
• Seventeen years of ten-minute blocks have left 78 MB of headers; thirteen years of one-minute blocks with AuxPoW proofs have left Dogecoin with 4.4 GB.
• A light wallet syncs eight years of ten-minute headers in under a minute on a good connection; one-minute headers take eight minutes, and half an hour on a slow one.
• Faster chains ask for more confirmations for the same security: 28 Litecoin blocks, 70 minutes, against six Bitcoin blocks, 60.
• On a chain that stops double-spending before a block is found, a payment is accepted in seconds whatever the interval; a faster block adds nothing to it.

Every cost of a faster interval is measured and permanent; its one gain, an earlier first confirmation, is worth nothing to a payment already accepted in seconds. Ten minutes is where those costs stay negligible.

How the Grade scores block time

The CoinSpectrum Grade scores block time as part of scalability: ten minutes scores 10, and each tenfold step away from it, faster or slower, costs 3.6 points: 6.4 at one minute, 2.8 at ten seconds and 0 at one second. Block space is scored per ten minutes, the size limit times 600 divided by the interval, so a fast chain with moderate blocks is not marked down twice. Fast payments are a separate check, since a chain can accept a payment in seconds without fast blocks.

Questions

Sources

• Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, Sections 7 and 8.
• Satoshi Nakamoto, Cryptography Mailing List, 10 November 2008 and 14 November 2008.
• Satoshi Nakamoto to Mike Hearn, "More BitCoin questions", 29 December 2010.
• C. Decker and R. Wattenhofer, Information Propagation in the Bitcoin Network, IEEE P2P 2013.
• A. Gervais, G. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf and S. Čapkun, On the Security and Performance of Proof of Work Blockchains, ACM CCS 2016, and the talk at Scaling Bitcoin, Milan 2016.
• J. Fechner, B. Chandrasekaran and M. X. Makkes, Calibrating the Performance and Security of Blockchains via Information Propagation Delays, ACM SAC 2022.
• bitcoin-data/stale-blocks, read 9 November 2026.
• Kraken, Cryptocurrency deposit processing times, updated 22 October 2026; Binance's public network list, read 9 November 2026.
• CHIP-2025-03, Faster Blocks for Bitcoin Cash, and its discussion.
• Header, coinbase and block index sizes: measured by CoinSpectrum on 9 November 2026 from each chain's nodes over its peer-to-peer protocol; Dogecoin's recent blocks read from Blockchair.