As opposing sides in Bitcoin's long-lasting scaling dispute seem to be inching closer, one of the remaining sources of contention is not whether, but how to achieve a small block size bump.
The Bitcoin Core development team wants to increase the maximum block capacity through a SegregatedWitnesssoft fork, which has since been embraced by a large part of Bitcoin’s development community and a significant segment of the Bitcoin industry.
Others, like CEO of major payment processor BitPay Stephen Pair, believe the perceived benefits of soft forks over hard forks are being overstated.
Speaking to Bitcoin Magazine, Pair explained:
“I think soft forks aren't the panacea that many people perceive them to be. It's true that not all nodes on the network need to upgrade at the same time with a soft fork. But once the majority of hashing power has adopted new consensus rules, anyone running a full node should probably want to upgrade to validate the new transaction semantics. And this is especially true when you consider that SPV-nodes make the assumption that peers are performing full validation to keep miners in check.”
A centerpiece of Bitcoin Core’s scalability “road map,” Segregated Witness is set to increase the effective block size to some 1.6 megabytes to 2 megabytes by moving signature data into a new data structure. Pair is skeptical, however, that Segregated Witness should be considered a short-term scaling solution.
“Segregated Witness would completely change the structure of a Bitcoin transaction, and shouldn't be rushed,” Pair said. “It needs a lot of time to be tested and widely supported. I'm not certain how contorted the implementation has to be to deploy it as a soft fork, but this is code we'll have to live with for a long time. The more complex the Bitcoin validation code becomes, the more vulnerable it will be to various types of attack. A cleaner implementation done as a hard fork might be preferable.”
On Hard Forks
Pair himself initially signed an industry letter in support of BIP 101, the proposal by former Bitcoin Core lead developer Gavin Andresen intended to increase the block size limit to 8 megabytes, then doubling every other year for the next 20 years. He later said he preferred Blockstream president Adam Back's “BIP 248,” an informal proposal to raise the limit to 8 megabytes over four years. And more recently, Pair pitched his own solution: a dynamic block size cap to automatically re-adjust based on recent transaction volume. Additionally, the BitPay CEO is willing to accept a one-time block size increase, such as a hard fork block size limit increase as proposed by Bitcoin Classic.
Pair did add, however, that a hard fork shouldn't be thought of too lightly:
“The big risk of a hard fork is that non-upgraded nodes would go off on a defunct fork and they would be vulnerable to double-spend attacks. With a hard fork, you need to make sure people have plenty of time to upgrade. There is a need to come up with good engineering solutions to managing either type of fork; Version Bits as described in BIP-9 is a good start.”
On Firm Forks
An alternative proposal to increase the block size limit is sometimes referred to as a “firm fork” or a “soft hardfork.” This could allow a majority of miners to change any consensus rules, including those that would typically require a hard fork. But as opposed to both hard forks and soft forks, it would render non-upgraded nodes completely unable to detect any new transactions.
“While the additional complexity of implementing it may not be worth the effort, you could perform a hard fork where miners effectively DOS old nodes by merge mining empty blocks under the old consensus rules,” Pair explained. “I think that would make hard forks a lot safer. People will still have to upgrade, but for those that neglect to upgrade, it will be immediately apparent as it will seem that no transactions are being included in their chain.”
This proposal has itself sparked some controversy, to the point where some dubbed it an “evil soft fork.” Since users would no longer be able to opt-out of a change, they'd have to follow the rules as decided on by miners – or create a new chain.
Pair is not too worried about these consequences, however:
“A user would either want to follow the longest chain, or explicitly go off on a weaker fork. Either way, he would need to upgrade. A firm fork would ensure that the old chain is no longer functional. But whether it's hard forks or soft forks or firm forks... the important thing is that we, as a community, need to become proficient at managing changes of consensus rules.”