Join 41,912 users and earn money for participation

On the Bitcoin Cash block time

0 0 boost
Avatar for deadalnix
Written by
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
  126
6 months ago

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.

1
$ 0.00
+ $ 15.58 in other submissions
Avatar for deadalnix
Written by
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
  126
6 months ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

Dogecoin and Monacoin have no problem with 1 minute blocks.

Dogecoin is a very active network, they process a lot of transactions. There are no issues with the network so far. Its worths to decrease the block time. Securing the transaction in a block results in a trustable payment, its very ideal in trade, such as in shops, real life markets. I dont think there is any reason to keep the block time 10 minute long.

I think the network is ready for an one minute block-time upgrade. And by modifying this, the next halving can be sheduled with a 10 times multiplier to keep the time interval the same as before.

$ 0.00
6 months ago

You have to think about the future. What happens when blocks occupy several gigabytes? 1 TB? 10 minutes inter-block time decreases the number of orphan blocks.

$ 0.00
6 months ago

I did. Thats why i have recommended the block time decrease, and not the block size increase.

$ 0.00
5 months ago

And don't we all love Doge? Yes, agreed it's time for the blocks come faster. Yet maybe still there are some extra consideration on does it worth the trouble? But I think yes.

$ 0.00
6 months ago

Well informative post from @deadalnix thanks for letting us know about Bitcoin cash block time

$ 0.00
6 months ago

Lovely writeup

$ 0.00
6 months ago

Nice work done by you. This is encouraging as it will develop the BCH ecosystem when fully implemented. Hope the challenges will be overcome soon. Kudos to you.

$ 0.00
6 months ago

Thanks. That article was needed! I am becoming more and more pessimistic about BCH because of its funding problems and also because I don't see where it will fit in the crypto world.

I'd like to see shorter block times for the reasons you stated and I don't care if we break some contracts noone is using. I realize that there are other priorities now which is fine.

$ 0.00
6 months ago

Avalanche pre-consensus is likely the way to get there.

$ 0.00
6 months ago

This is great work

$ 0.00
6 months ago

Thanks for a well-written explaination of the pros and cons. I agree that shorter block time is not worth the problems it gives compared to other solutions (like Ava).

Question: I haven't had time to look at it myself, but are you familiar with Dash's "chainlocks" (I believe it is called) that offers near-instant (I suppose pre-consensus style) confirmation? What are your thoughts about that approach?

$ 0.00
6 months ago

thanks for this write-up

what other potential solutions exist for fast confirmations? why and how was avalanche chosen?

$ 0.00
6 months ago

Won't hurt to answer in writing as well as in a video AMA. I would like to see an answer also.

$ 0.00
6 months ago

great work from deadlnix thanks for posting such interesting article

$ 0.00
6 months ago

Thank you for all that you do! Hope this article can get to the Chinese community.

$ 0.05
6 months ago