On the Bitcoin Cash block time

It recently came to my attention that reducing the block time for Bitcoin Cash is still a hot topic in the eastern community. There also seems to be a lack of knowledge of the various arguments surrounding the matter, so in this article, I hope to clear things up a bit.

Why faster blocks?

A shorter block time has several advantages that shouldn't be dismissed too quickly.

As blocks come faster, the amount of mining work required to produce a block will diminish. For instance, if we reduce the block time to 1 minute, then each block will become 10x easier to produce. So the security of transactions is the same on long timeframes. 10 blocks at difficulty 100 is the same as 100 blocks at difficulty 10. But this is not the case in short timeframes. 1 block at difficulty 100 is significantly less secure than 10 blocks at difficulty 10. The math behind this can be a bit complex, but the intuition is that an attacker has 10 minutes to run its attack rather than 1.

Having higher security on a short timeframe would allow services such as payment processors and exchanges to process transactions faster, enabling more use cases on BCH. For reasons related to scaling, it is not really possible to dramatically reduce the block time, so this is not really a solution for instant payments, but it is very useful for arbitrage or reducing risk due to price variation for merchants.

Another important benefit of reducing the block time is to provide more information to the difficulty adjustment algorithm. The difficulty adjustment algorithm uses past blocks to estimate the amount of hashrate on the chain and adjust the difficulty accordingly. However, there is a lot of variance in the individual block time, so it is necessary to use several blocks to make a decision. The more blocks are used, the better the decision, but also the longer it takes to make that decision. There is an inherent tradeoff that can be improved by providing more blocks faster to the algorithm, allowing it to adjust faster and more precisely.

Considering all of the above, if I were to start a new coin from scratch, I would likely choose a block time lower than 10 minutes. Maybe 2.5, or even 1 minute, but no lower, for reasons that I will explain. However, when it comes to Bitcoin Cash specifically, it must be understood that there are drawbacks associated with the fact that there is an existing system, and so the benefit we need to expect from such a block time modification needs to be way higher than what is required from a new system.

Why do faster blocks hinders scaling?

Any bitcoin style network requires the block time to be significantly larger than the time required to process a block by the network as a whole. If that is not the case, then the capability of the network to come to an agreement is severely damaged. The most extreme case obviously occurs when blocks are produced faster than the network can process them, effectively sending each miner on its own chain. But even before the network reaches this state of total collapse, the quality will degrade due to the orphan rate increasing.

Intuitively, one would expect that if we make blocks faster, then each block would be smaller, and therefore, faster to propagate. To some extent this is true, but this is neglecting the fact that there are fixed costs associated with propagating a block. These costs do not depend on the size of the block. To understand this, let's assume that we have Alice, Bob and Carol propagate a block to each other in a way similar to what nodes on the network would be doing.

Alice, to Bob: Hey Bob, I just got a new block, its hash is 00012345af, do you want it?
Bob: Hey Alice. I do not know about this block, please send it over to me.
Alice: Alright Bob. So the first transaction in the block is .....

Bob, to Carol: Hey Carol, I just got a new block, its hash is 00012345af, do you want it?
Carol: Hey Bob. I do not know about this block, please send it over to me.
Bob: Alright Carol. So the first transaction in the block is .....

This is fairly similar to what happens on the network between nodes when a new block is found. As we can see, there is a fair amount of back and forth between the parties in addition to the transmission of the block itself. This back and forth is required because if it did not take place, then all the nodes would start to send blocks to everybody at once, causing a total network collapse when a new block is found. There are various tricks that can be used - and in fact are used by the Compact Block technology that is used by Bitcoin ABC nodes - to improve the situation, but the general problem remains, there are overhead costs.

By changing the block time from 10 minutes to 1 minute, we would effectively multiply by 10 the overhead cost that happens on a 10 minute time scale, which would limit how much we can safely scale the system.

What about faster confirmations?

While faster blocks would improve confirmation time, it cannot ultimately do it on a timescale that really enables many use cases. For any face to face interaction, the confirmation time needs to be lowered to 3s or less to be very impactful, something we cannot do with the block time. This is something that the Avalanche technology can achieve. The prototype that exists now is able to confirm transactions in less than 2s.

While some use cases such as arbitrage would benefit from this, it is probably not sufficiently aligned with the Core values of Bitcoin Cash to justify changing something as central as the block time.

What about difficulty adjustment?

Faster blocks can help design better difficulty adjustment algorithms because they provide more data that can be used by such algorithms. The obvious downside is that there is more data to process, which leads to more load on SPV systems, as well as seriously limiting what very lightweight systems such as smart cards can do.

While this is certainly not an impossible amount of data to process, people make assumptions when they decide to build on Bitcoin Cash, and breaking these assumptions is detrimental to the growth of the ecosystem.

Why is it harder to change the block time on an already deployed system?

I stated in this article that I would choose a block time shorter than 10 minutes if I were to build a new system from scratch. However, on a system such as Bitcoin Cash, there are already many existing users. Bitcoin Cash has a script system that has time based features, such as locking coins for a certain amount of time before they are spendable.

These features are essential for many smart contract systems, notably payment channels or recurring payment solutions such as Mecenas. These contracts do not have a source of time, and therefore use the blockchain itself as a clock. Changing the block time would therefore effectively change the speed at which time passes for all these contracts, breaking the system they are built upon.

To add to the challenge, Bitcoin Cash supports P2SH, which means we are not aware of all the scripts that are associated with existing coins. It is not possible to parse the blockchain and devise a system that would work for existing contracts, so we are forced to devise a system that will work for all contracts that could have been written. It is not certain that this can be achieved at all without serious downsides, but what is certain is that nobody has the time or resources required to make an honest attempt.

Without a solution to this problem, we do not have a very concrete proposal to change the block time we can discuss.

Conclusion

There are many challenges to changing the block time and some of them are unsolved at this time. Investing in solving these does not seem to me to be the right path considering the downsides and maximum gains in terms of confirmation time, and the existence of better alternatives.

With our current roadmap, we estimate that we can deliver avalanche in 2 years. However, we would like to deliver this much sooner if resources allow. After all, Avalabs does have a working implementation, so there are no reasons to expect avalanche to eternally be 18 month away.