I’m writing this in a more accessible format; that is a blog rather than an academic paper.

Many people often wonder why Bitcoin used a 10-minute interval. Bitcoin is configured to adjust to a 10-minute block interval. However, you will notice that the average time for a block on the actual network is around 560 seconds or 9.3 minutes. The reason for this difference from the stated 10 minutes is related to the growth of the network. For the conceivable future we can expect Bitcoin to grow on a near exponential path following the prediction rates in Moore’s law. As such, we see lower block times.

While discovery in Bitcoin is not actually a Poisson or exponential process it approximates these only when it is set to exhibit longer block times. One of the primary reasons this holds and I can make this statement is that Bitcoin is an SEIR process. When scientists model epidemics they use a combined model relating to the following terms:

- susceptible - exposed - infectious - recovered

In a system such as Bitcoin, or for that matter any decentralised node system, we can describe this as follows, the susceptible state is one where the network has selected a block and is mining seeking a new block solution. In this, block zero [B(0)] is known throughout the network and all miners for practical purposes are mining on it. Next, we have the exposed state. In the exposed state, a miner has discovered a new block solution. One or more miners hold the solution and are now mining on a new block. This needs to be propagated from the miner that discovered the hash solution to all other miners. There is a definite time between the marking of time on an exposed state and the receipt of that block to other miners.

The next state can be modelled in the infectious state in epidemiology research. Here, the miner has validated and accepted the received block as satisfying a solution to the block hash and starts propagating this to other miners. Straight after the validation stage each miner starts seeking a solution now for block number one following block zero [B(1)].

The expected time to elapse before all nodes know the transaction is:

See the model at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3151940

The result is not a limit above, but rather an asymptotic equivalence. The fact that the expected time increases with N is related to the fact that we don’t scale I0 with N. From this we see that when a small number of poorly connected nodes hold a transaction, and when nearly all nodes have a copy of a block or transaction, the node’s propagation to the remaining nodes in a Gossip network occurs very slowly.

We can now extend this model to account for censoring and the fact that when a block is discovered, the block will reset and restart the process.

Each block received by a node is validated and checked for veracity. When two blocks are mined at nearly the same time, the first block to be received by a node is included and is verified. The next block will be placed into the “orphan pool” and is validated after the initially received block. This orphan block is only added to the main chain for the node, if a further block is added making this a longer chain.

Each node verifies a block before it propagates it to the connected peer nodes. In this way only valid blocks are propagated, and any invalid blocks are quickly isolated. The Bitcoin Core client lists all the validation requirements in the following functions:

CheckBlock CheckBlockHeader

In validating a block, the node will ensure that:

The data structure of the block is formatted correctly.

The block header hash is less than or equal to the set target difficulty for the two-week period.

The timestamp on the block is less than 120 minutes into the future. This allows for some time drift on mining nodes.

The block size is less than or equal to the value set in the MAX_BLOCK_SIZE parameter.

The initial transaction is a coinbase generation transaction. This is transaction zero for the block, and pays the winning miner.

No other coinbase transaction is present in the block.

Each transaction in the block is valid. Each transaction, as well as its hash, must be individually checked and validated.

Next, the block is validated to ensure that:

The transaction index validity is correct.

The transaction hashes are correct.

Spend txouts have been spent in the main chain.

All prevouts are marked as spent.

Spent txouts are spent by a valid transaction that consumes them.

As UTXO caching saves received transactions, the validation of each transaction should be fast if it has been received, cached, and saved in the pool. The case where a transaction is not in the UTXO cache slows the process. The node requests a copy of the transaction from the network, validates it, and adds this to the hash checks.

When a block is received that has a transaction the miner is missing, the mining node needs to download a copy of the missing transaction before it can complete validation of a received block. In the distribution displayed below we see the block times as recorded on the Bitcoin network. Although this is approximately exponential with a 10-minute block time, we can see that it forms a power law distribution when we look at the sub one minute times.

The validation and propagation time is small compared to 10 minutes. The result is that we can approximate a Poisson approach which is far simpler to calculating differential equations associated with true SEIR models or simpler power law approximations.

Time matters.

Bitcoin needs to work within the financial world, not to have this idea that the financial world can be modelled to work in Bitcoin. Monetary transactions do not follow an equal distribution. Back in 2006 and 2007 I was involved with modelling monetary transactions in the creation of automated fraud systems for accounting and auditing purposes. I became very familiar with the time distributions of monetary transactions in global systems.

Something that is commonly overlooked within the crypto community is the time distribution of transactions. In any period of time we can see that this distribution is approximately exponential in nature. The larger the block interval, the closer the distribution is to an exponential function. In large-scale commercial systems, over a period of time exceeding five minutes but remaining less than an hour we generally would expect transactions to fall within a 95% confidence bound along an exponential plot.

Alternatively, as we lowered the interval, the data appears to be more and more random and the impact of noise to the system makes it harder to predict.

The impact of not being able to model time intervals is a wider distribution of block sizes. At one minute, even at the lower 10% alpha, we expect many deviations from a standard predictable distribution. The result is far larger standard deviation for block size.

Although the distributions of blocks are asymmetric, a larger block time allows an increased range of small miners. As the time is decreased, fewer miners are able to compete. Part of the reasoning is the asymmetric distribution of transactions. At one minute the orphan rate is around 2.5 to 3 times that exhibited at a 10-minute block interval. The graph below plots this as orphan rate against time in 10th of minute blocks.

I could’ve spent more time doing the indices and playing up the graphs, however, this entire process of explaining why money should not be altered is the problem.

Changing settlement (block times) to less alters the distribution and ends up favouring larger miners more than the small. It skews profitability.

That is why 10 mins.

More importantly however, 10 minutes is not optimal, nothing is. For Bitcoin to work correctly it needs to be somewhere between five minutes and 20. The exact ideal optimal time is not calculable because it varies by time of day, season, use, electricity price and many other factors that are not standard.

The argument that this helps merchants is spurious at best. Money works best when it is stable. This is the entire purpose of Bitcoin. To make money that is stable, and yet this is the one thing everyone tries to alter, that is to make Bitcoin a typical Silicon Valley screw with it and hope that it works experiment. That’s the thing, Bitcoin will never work in this manner.

When scaled to incorporate larger block sizes, this is 1 GB for a 10-minute block or the corresponding 100 MB for a one-minute block interval.

Although superficially, the two power law distributions of blocks displayed above appear similar, they differ radically because of block processing time and distribution times that are not evenly distributed.

Moreover, with smaller block times it becomes simpler to withhold some transactions that the miner creates themselves further skewing the distributions. At a 10-minute interval, the first quartile is 30% of the mean. In a one-minute block, the first quartile is 40.5% of the mean.

Given quickly discovered blocks that exist in the third quartile and above for size, not distribution time we end up with a scenario where the one-minute block ends up containing enough transactions to slow distribution. Unfortunately, the majority of so-called scaling tests use evenly distributed processes rather than power-law block size. Our one-minute block in the third quartile of size ends up being propagated slowly to all but the largest miners. In the current environment that would be mining pools and solo miners with 15% or more hash rate. The small miners would receive this block slowly enough that they would fail to validate the block 27% of the time before a new block was discovered.

The increase in hash rate predominantly impacts miners with under 10% of the total hash rate.

Benefit

The touted benefit to a one-minute block rate is improved merchant adoption. Even at a one-minute block, approximately 20% of blocks are discovered in a period exceeding two minutes. To be useful to a merchant in a commerce scenario, a block would need to be discovered and propagated without orphaning in an interval of under three seconds. This occurs extremely rarely at the best of times. The argument is a false argument against the benefits of 0-conf. The reality is there are no realisable gains in changing block time.

There are many negatives.

The primary negative is that Bitcoin is a cash-based payment system. Merchants develop software and applications and every time a change is made, they need to redeploy these. This is the worst weakness Bitcoin has exhibited. When compared to fiat, Bitcoin changes minute by minute.

If we are to make Bitcoin a global currency, we need to replicate the features of cash. First and foremost, this comes down to creating a stable platform. Every time the protocol is altered, merchant opportunities are lost. The original Bitcoin protocol was resilient enough. There is never a state of perfection.

The 10-minute time interval within Bitcoin was a guess. It’s a good enough one. Maybe five minutes would’ve been better or maybe 15 but the reality is none of this matters because it could never be anything less than two minutes and successfully scale. The most important aspect of what needs to be done is to stabilise and lock down the protocol so that merchants can build and use coins globally.

Larger block times lead to less uncertainty

We see the distributions of blocks in the figure below. A small (1-minute blocktime) is only able to be modelled using a power law or exponential distribution. A larger block time is close to a normal or Gaussian distribution.

As with many things, block time in Bitcoin is a trade-off. There is no perfect time and as you lower or increase the time, you alter the incentives and change the system.

That, above all is what Bitcoin cannot do. Bitcoin was designed to be stable and set in stone.

This is how good money works.