When CoinTelegraph asked the Bitcoin Wallet software providers listed on bitcoin.org, they showed broad support for increasing the Bitcoin block size limit from 1 to 20 MB.

The teams behind Bitcoin Wallet, Bread Wallet, Coinomi, mSIGNA, Electrum, MultiBit and Armory all indicated they support Gavin Andresen's proposal to increase the block size, which would allow for a greater number of transactions to be handled by the Bitcoin network. GreenAddress was the only opponent, as covered on Monday regarding web-wallet providers' stance on the block size issue.

Most of the software providers acknowledged that raising the block-size limit would come with a trade-off, as the increased hardware and bandwidth requirements could result in a loss in full nodes. None of them believed 20 MB would lead to a problematic level of centralization.

Some developers, however, shared a concern with critics of the increased limit that there will be a need for some scarcity in Bitcoin blocks in the long run, in order for a fee market to emerge. Bitcoin miners need to earn enough income in order to keep the network safe. Finally, several of the providers indicated they support a switch from Bitcoin core to Bitcoin-Xt in order to allow for bigger blocks, if no consensus among core developers can be found.

Increase

Many gave two reasons for their support of the proposed block size increase. First, most of them said it is necessary to allow users to continue to make cheap use of the blockchain.

Second, some echoed the concerns of Mike Hearn, Bitcoin-Xt developer and prominent proponent of the increase. They said they believe that the inability of miners to validate all transactions due to small blocks could lead to chaotic situations for Bitcoin as a whole, as payments could become stuck on the network. MultiBit developer Jim Burton told CT:

“Gavin presented his reasoning for 20 megabyte blocks at the recent DevCore London that I attended, and he has a convincing argument. We need bigger blocks in Bitcoin to enable the regular Jo to stay on chain and not be forced to off-chain solutions.”

Armory core developer Alan Reiner said on the Bitcoin development mailing list:

“Seven transactions per second is pathetic for a global transaction system. It is a couple orders of magnitude too low for any meaningful commercial activity to occur. If we continue with a cap of seven transactions forever, Bitcoin will fail. Or at best, it will fail to be useful for the vast majority of the world — which probably leads to failure.”

Electrum lead developer Thomas Voegtlin also agreed with an increase before the current 1 MB blocks are filled up. He told CT:

“I do support an increase of the maximum block size, because it is safer than doing nothing and reaching full blocks. Indeed, I fail to see how reaching full blocks would result in a working fee market; I believe that idea is ideologically driven wishful thinking. If blocks reach full capacity, we are more likely to see users being annoyed and stopping using Bitcoin.”



Centralization

Perhaps the most important argument against raising the limit was that the need for additional hardware and bandwidth in order to run a full Bitcoin node would lead to an increase in centralization of the Bitcoin ecosystem.

Most of the wallet software providers did not share this concern, however. They either believed that the risk is being blown out of proportion by opponents of the increase, or that it is a small trade-off that is worth the benefits of bigger blocks. BreadWallet co-founder and CEO Voisine said:

“I think these concerns are not justified. Just as bitcoin mining pools allow many more people to participate in mining, there are plenty of promising future developments like the lightning network, blockchain sharding, and other techniques to continue to allow people with fewer resources to participate in the network, without resorting to the drastic measures like introducing unpredictable transaction failures.”

Similarly, Coinomi founder John L. Jegutanis explained:

“I am not worried about centralization at all. Bigger blocks will surely strain the network infrastructure, but even now the nodes that run on home ADSLs are not contributing to the network. Running a pruned node will help alleviate some of the pain.”

MultiBit's Burton did agree that a higher block-size limit might lead to a loss in decentralization on the network, but considered it a fair trade-off. He said:

“Personally I think 20 MB blocks will be OK from the decentralization perspective though it will of course knock some nodes off the network due to, say, bandwidth caps. I think 20 MB is an acceptable compromise between the need for more transactions and keeping Bitcoin decentralized.”

Original Intent




Most share a somewhat conservative sentiment, preferring to refrain from drastic changes to the mechanics of Bitcoin, or they wanted to keep the system close to one envisioned by Satoshi Nakamoto. Andreas Schildbach, lead developer of Bitcoin Wallet for Android and Blackberry, said:

“The hard limit is just meant as a last barrier for spam attacks, nothing else. The soft limit is what limits blocks in reality, and that can be decided by each miner separately. Currently, most miners still use 0.75 MB, so it's very unlikely the 20 MB will be used right from the point where the hard limit is increased.”

Similarly, Armory's Reiner posted on the Bitcoin development mailing list:

“Satoshi didn't believe one megabyte blocks were the correct answer. I personally think this is critical to Bitcoin's long-term future. And I'm not sure what else Gavin could've done to push this along in a meaningful way.”



BreadWallet's Voisine said:

“The proposed increase is the simplest and most conservative course of action to keep the network behaving the same as it does today, as usage continues to grow. With over US$3 billion of value being stored in bitcoin, it is reckless to introduce drastic changes to how the network functions.”

Others, however, believe that Bitcoin will need to see drastic changes at some point in the future, and believe an increased block size limit is merely a temporary solution.

Electrum's Voegtlin told CT:

“I believe the issue of long-term mining incentives will require a fundamental change to the Bitcoin protocol. That problem is less urgent, but more important than the maximum block size. I would like a solution to be adopted as soon as possible, ideally together with the block size increase. As long as that issue is not resolved, I do not think it is reasonable to consider Bitcoin as an investment opportunity.”

Bitcoin-Xt

Several developers indicated that a switch from Bitcoin core to Bitcoin-Xt for the main implementation as suggested by Andresen, would be supported by their software. Some have even made the switch already, yet others say that it would ultimately be up to individual users to make the decision whether to support 20 MB blocks. Coinomi's Jegutanis told CT:

“Personally, I support Gavin and Mike Hearn with their effort to deploy the new 20 MB blocks. We already moved all our bitcoin nodes to the Bitcoin-Xt to show support. The increase of the block size makes sense even if you had deployed the lightning network, it will scale even more.”



Likewise, MultiBit's Burton suggested he had no problem with connecting to Bitcoin-Xt. He said:

“At MultiBit, we like the Bitcoin-Xt fork Mike Hearn has made. It supports his Lighthouse project, which is a great piece of enabling software. MultiBit connects directly to the Bitcoin network and will work with both Bitcoin core and Bitcoin-Xt.”

Similarly, co-CEO and CTO of Ciphrex Eric Lombrozo said:

“Our software can just as easily support any maximum block size. We’ll support whatever maximum block size our users want. On a technical level, we can support either 1 MB and 20 MB block sizes with the change of a single configuration parameter. We’ll make it easy for our users to pick whatever they want.”

Politics

Finally, some of the wallet providers indicated there might be a much bigger issue at stake. Ciphrex's Lombrozo, in particular, pointed out that the real problem might not be the maximum block size by itself, but the lack of a streamlined governing model for Bitcoin in order to collectively make decisions like these. He said:

“We believe the fundamental issue here is that, as Bitcoin Core developers, we’ve so far failed to develop a good metaconsensus and formal forking and merging process to decide these kinds of issues. The block size limit is just the one of many controversies that will arise regarding changes to the protocol and, in particular, to the consensus rules. Everyone saw this one coming. Unfortunately after over six years of Bitcoin, we still don’t have a process to agree on these kinds of things.”

He added:

“Rather than avoiding network forks like the plague, perhaps we should design for them. However, forks are the easy part. It’s merging and reconciling them that seems to be really, really hard. It’s this latter part that needs considerable work. There are a few proposals out there — for instance sidechains — that at least address some of the technical hurdles that might arise in being able to have consensus that can span multiple chains. However, this still leaves open the question of how we ultimately end up converging upon a new consensus protocol. In particular, migrating applications to a new consensus protocol seems far from trivial in the general case.”



CoinTelegraph reached out to AirBitz, BitGo, Bither, Hive, Mycelium, and Ninki, but received no responses by the time of publication.

Original article posted here.