Ten Minute Confirmation Time

The Bitcoin Blockchain is built of blocks, which are updates to the shared global record synced to all participants in the Bitcoin peer to peer network. Blocks are produced every ten minutes on average. This limit was chosen based on using the speed of light as a baseline for how quickly a synchronized state may be reached around the world.

Although ten minutes is an average, blocks must be found at very random intervals to avoid a race condition where multiple miners are finding blocks on multiple chains at the same time and multiple equally valid parallel and conflicting histories are created. So really the case of a much smaller value must be considered to be a common occurrence, say a one minute block.

A good rule of thumb for thinking about how fast data may be synchronized around the world is that in the perfect case where no back and forth or jumps are necessary and the fastest possible bandwidth and latency exists, this is about a tenth of a second, limited by the speed of light. Assuming real world latency and back and forth, real world bandwidth, validation of data, this best case scenario is more realistically about one second, about three jumps and three times as slow as light in a vacuum.

So considering the case of a one second block time, there would be constant conflicts around the world where independent miners would come up with the same blocks before they even realized that others had solved a block, resulting in a huge amount of wasted hash power towards blocks that were just discarded, and a very confusing experience of viewing confirmation numbers going up and down rapidly.

Another way to think about is it is to consider someone trying to mine Bitcoin on Neptune or Pluto. It takes the speed of light so long to get there, they would have no chance to compete in mining because they'd always be behind. This could be fixed by making block times something huge like one hundred years, but then that would not be practical for human use.

Even if shorter block times might be achieved, at the fastest speed: seconds, this would be superfluous due to how the Bitcoin proof of work functions. The concept of proof of work depends on sufficient work, the reason it is infeasible for an an attacker to replace the last thousand blocks lies not with the number of blocks, but rather with the energy expenditure they represent. Energy spent over time provides the risk mitigation tool, blocks merely provide markers along that path. The recommendation for securely receiving funds with Bitcoin is not a single block, but rather multiple blocks, preferably from multiple independent sources. Three to six blocks, or half an hour to an hour, whichever comes later, stands as a general recommendation for meaningful proof of work.

The other issue with making block times extremely short lies with the incentives behind mining. Mining incentives have been constructed carefully so that blocks are meaningfully and discretely describing the proof of work that is used as a risk mitigator when accepting Bitcoin transactions. Mining incentives are designed to promote an even playing field for anyone to enter, so as not to obscure the proof of work cost behind barrier to entry costs. Miners mine against a set of headers that are separated from the number of nature of transactions included, so that they are incentivized to include transactions and not simply seek the miner subsidy.

With extremely short block times, the importance of the speed of light and other close-networking advantages grows: miners located next to each other are much more likely to catch each others' blocks and not have their blocks fail in a race between close-time blocks and be ignored by the network. This incentivizes miners to co-locate, reducing the durability of the network: a single specific geographic location is much more likely to suffer some calamity or issue than many distributed independent locations.

Other Bitcoin applications beyond the peer to peer network must bear the costs of block times as well. For example so-called SPV clients that simply download the smaller sized Block headers, must potentially download more block headers when faced with a greater number of blocks, degrading their user experience.