7 Points about Block Times (and Network Topology)
It's important that the Bitcoin Cash community doesn't conflate "the original vision" of Bitcoin with "the original design specification" of Bitcoin.
We need a strong, unified community around the vision of peer-to-peer electronic cash. That means the end-product has low transaction fees, a limited supply, no middle-men, is fast and reliable, and is easy to use for everybody on earth. That's what we mean by "the original vision," and that doesn't mean "the exact technical implementation of v0.1 of Bitcoin." The technical details are only relevant as a means to the end of global p2p money.
We forked away from BTC because the Core developers abandoned the original vision - not because they abandoned the original design implementation. They changed p2p cash into a "store of value" token that is intentionally built around high-fees to access the blockchain. That's not what I signed up for, and it's not what I wrote my Bitcoin book about in 2014.
If it were possible for the Core developers to actually create a product in line with the vision, I think most Bitcoin Cashers would support them and celebrate their creation.
However, we will run into big issues if we conflate "returning to, and sticking with, the original vision" with "returning to, and sticking with, the original implementation."
One parameter which has caused controversy is the block time. I do not think a 10min block time is essential to Bitcoin's design. The block time is a means to an end. If the technology and user experience can be improved by reducing the block time, without significant risk, it should be reduced.
However, I don't claim to be a technical guy. So I've asked a Bitcoin dev with much deeper knowledge about the topic, and I want to summarize his points. Devs might find these claims valuable.
All feedback/questions/criticism is welcome:
1) A 10-minute block time is not an essential, set-in-stone parameter. It's preferable to make it as low as possible, but no lower. 1 minute, or even 30 second blocks, could work in the right circumstances.
2) The optimal block time depends on the network topology.
3) If the topology is a mesh network, the block time should remain at 10 minutes.
4) If the topology is a small world network, the block time can be reduced substantially.
5) Bitcoin is not "inherently" a mesh network or a small world. It can be either.
6) The code which determines the network structure is at the client-level, not the protocol-level. Changing it does not require protocol changes.
7) A small-world network is superior to a mesh network, with few drawbacks. Regardless of Bitcoin's current topology, it should end up being upgraded to a small-world. Which means at some point, Bitcoin's block time should end up being reduced.
If these claims are true - if the block time is a safe parameter to tweak - we shouldn't worry that Bitcoin is being hijacked, as it was by the Core developers. Bitcoin with 1min blocks is still Bitcoin, just upgraded - like when we finally increased the blocksize cap, which was also a non-essential parameter.
I would like to hear other old-timers opinions on this issue. The blocksize war is finally over, and many of the bad actors have been left behind. I'm not sure we can withstand a block time war.
1 of 1 reviewers say it's worth paying for
0 of 1 reviewers say it's not worth paying for