Bitcoin Experts Weigh In on Hard-Fork Debate
Bitcoin scalability and how to ensure Bitcoin will be able to support a larger and larger user base has been discussed since its inception in 2009. For the longest time, Bitcoin has been able to make due with its current 1MB limit. However, as more transactions are made per second, and the block size limit has remained the same, network congestion has gone up.
The most common solution many refer to is to just increase the block size. It is the simplest change to implement, as there is only a single line of code in Bitcoin Core that dictates the maximum block size. It helps alleviate the network congestion by increasing Bitcoins maximum transactions per second capacity, but it comes with its caveats.
First, while changing the maximum block size would only take changing a single line of code, it would require a hard fork. Hard forks are something that should not be taken lightly if the Ethereum situation has taught us anything, with Andreas Antonopolous commenting recently in an interview,
“Even though a 2MB HF seems like an “easy” solution, it is not easy. As we have seen in Ethereum, a Hard Fork (HF) can cause enormous disruption to exchanges and other services. Bitcoin’s economy is MUCH larger and we need to be much more careful with a HF.”
Second, raising the block limit effectively makes running a full node more expensive as more resources are required to download every block and transaction to check them against Bitcoin’s consensus rules. By increasing the barrier of entry, fewer individuals would run a full node, thus weakening decentralization and increasing the amount of trust required in Bitcoin.
Moreover, in the grand scheme of things, it would not be a long-term solution. Andreas Antonopoulos weighed in on this topic too,
“Scaling will be solved by many different solutions, not just a hard-fork. If Core fails to provide good solutions for scaling, they will lose power to alternative implementations. Until now, the community and market is accepting Core’s roadmap and following their code.”
Also, Antonopolous stated he anticipates a higher block size limit within the next two years,
“I expect we will see a higher block size limit in the next 2 years. HF scaling, Segwit and LN network are ALL needed to scale and will all be implemented in the next 2 years. In addition, more scaling solutions will be used (Schnorr signatures, compact blocks, FIBRE and others)…”
While the Lightning Network, as well as other off-chain transactions through the use of sidechains, will also greatly help alleviate the problem of Bitcoin scalability, both are far away from being ready for public use.
A solution that could be mainnet-ready very soon is upon us, however. Segregated Witness, referred to as segwit for short, is scheduled to for testnest release in Bitcoin Core v0.13.0, with mainnet release in Bitcoin Core v0.13.1.
Segwit basically separates the signatures and the transaction data, allowing the signatures to be processed independently of the transaction data. This allows more transactions to be conducted in the same 1MB limit.
Peter Todd in a recent blog post goes into detail about the additional benefits segwit brings to the table as well as stating that Segwit increases the Blocksize to 4MB, however since this would only be a hard fork, only witness data can take advantage of the extra space. Regardless, this will help increase the amount of transactions per block, and afford Bitcoin development some time to progressing towards a long term scaling solution.
“A significant concern with any block size increase, including segwit, is that the higher bandwidth requirements will encourage centralization of hashing power due to the disproportionate effect higher latency has on stale rates between large and small miners.”
Todd then goes on to state work by Matt Corallo has done to mitigate this effect, developing the aforementioned FIBRE network, and Todd himself will be researching this issue further. With progress being made on several fronts, the outlook for the scaling and hard-fork for Bitcoin is positive. As long as the community can achieve consensus and stick to the plan, Bitcoin’s hard-fork will stand in stark contrast to Ethereum’s. Antonopolous expressed his optimism,
“Before planning a 2MB HF, we need to fix several other issues which can be fixed by Segregated Witness (for example, scaling of signature verification). I think the current plan is good: to do segwit first, improve the relay network, implement compact blocks and other small changes followed by a carefully planned HF to 2MB in the next 18 months”
