A small tweak to bitcoin could have a big impact.
This has been the central point of contention in bitcoin’s “block size debate“, a long-running dispute over whether to lift a hardcoded limit on the amount of data that can be included in each block of transactions.
One side sees increasing the block size as an easy way to boost the number of transactions processed on the network, potentially expanding bitcoin’s user base. Those opposed to the move worry about the consequences (think centralization and instability) of such a change, or at least question the need to lift the block size in the near-term.
There are other pieces to bitcoin that can be changed or moved around, and any change can make a big difference for the overall health of the network – good or bad.
One data-heavy presentation from the developer conference Scaling Bitcoin earlier this month explored how changing parameters can affect the network, like how a tweak to the frequency at which blocks are created might be one way to easily grow transaction capacity.
Using data pulled from their open source simulator of a proof-of-work blockchain (bitcoin and ethereum are two such blockchains), researchers from ETH Zürich argued that bitcoin could securely reduce its block time from 10 to 1 minute.
The idea is that the change doesn’t impact security negatively, but still boosts the possible number of transactions on the network. So, the argument goes, it’s better overall.
Arthur Gervais, a PhD student in the Institute of Information Security at ETH Zürich, told CoinDesk:
”According to my research the one-minute block interval seems like the most plausible. I don’t mean that it provides sufficient security, but that it would provide the same security as bitcoin has today.”
How does this approach grow capacity? The logic is simple: More blocks mean more transactions.
The research effort joins a number of other ideas focused on increasing bitcoin’s transaction capacity, including SegWit, Lightning, and other proposals from Scaling Bitcoin, such as Schnorr signatures and the ambitious plan to reshuffle bitcoin via client-side validation. Alternative bitcoin implementations, including Unlimited and Classic, seek to scale by raising the block size cap.
The ‘block time’ debate?
Tweaking a parameter to boost capacity – does that remind you of anything?
Bitcoin’s block size, mentioned before, has long been discussed as a way to expand capacity. So, does this mean that we’ll be moving on from the “block size debate” to the “block time debate”?
Not according to Gervais. He sees his project more as a way to compare blockchains with objective measures, and to gauge how changes could affect bitcoin, so that developers can make clearer decisions.
“If people want to scale without sacrificing security, they have several options. I think it’s always good to have the choice. That’s why we’ve been doing this work,” he said.
Gervais continued:
“There has not been a sufficient understanding of the implications of changes to the – not only block size or block time – but security provisions in general. People are creating all these new altcoins and blockchains and I think we first need to take a step back and see what can be done with the current systems.”
Others also had a cautious attitude toward a lower block time interval.
“From my perspective these are propositions that are high risk while having uncertain rewards,” said Alexandre Bergeron, who consults for bitcoin companies. “It is one of those proposition that may sound good on paper yet have considerable impact network wise and come with unintended consequences.”
He argued that the combination of game theory and financial incentives holding bitcoin together is a “balancing act.” It’s another lesson in measuring tradeoffs; developers think that the network requires a specific mix of settings and parameters, or security of the overall network might be compromised.
“We still have a long way to go until we can be comfortable with our assumptions about the incentives already in place,” Bergeron added, concluding that these sorts of changes are a “long-term venture.”
Gervais maintains that it’s a possible way to help to scale bitcoin, but he isn’t necessarily pushing for the change.
“We have no public opinion on what should or shouldn’t be done,” he said.
All possible cases
Besides some vague notion that it will leave funds safe, what does blockchain security mean in cryptocurrency?
If conditions aren’t right, weird behavior that makes the network less secure can become more prevalent. These events include double spending (a user’s ability to spend their bitcoins more than once) or selfish mining (when a miner can cheat to earn more bitcoins at the expense of other miners).
The “stale rate” represents how often miners find blocks that aren’t ultimately added to the blockchain. Too many stale blocks can potentially lead to increased mining centralization and can make the blockchain easier to attack.
So, by looking at the stale block rate, engineers can determine how well it would affect the blockchain’s security. If this number is higher, that’s a point of insecurity.
That’s what Gervais and the rest of the Zurich-based research team did to determine that a one minute block interval is the most feasible.
“We simulated all possible cases,” Gervais said.
The experimental results show how the team measured block sizes from 0.1MB to 16MB and block intervals going from 0.5 seconds to 25 minutes, looking to see how the stale block rate changed at each and every level.
But still, as with many other blockchain setting changes, the story is complicated.
Bitcoin Core contributor Greg Maxwell was skeptical, advocating for a longer block time on reddit. He argued that the block time question is tricky, because if it’s too low, then the network could see a quick drop-off in security.
“Since we can only get it approximately right, we should strongly prefer being slightly too long vs slightly too short,” he said. Maxwell also highlighted how, in some cases, it takes longer for blocks to propagate across the network – something a higher block time can help with.