Web-Wallet Providers Divided over Andresen’s 20 MB Block Size Increase Proposal
Of all Bitcoin web-wallet providers as listed on bitcoin.org, Blockchain.info, Coinbase and Xapo are in favor of raising Bitcoin's block size limit from 1 to 20 megabytes as advised by Bitcoin Core developer Gavin Andresen, while Coinkite and GreenAddress have come out against the proposal.
This means that Bitcoin's major wallet providers based on venture capital investments as well as the total amount of users – Blockchain.info, Coinbase and Xapo - all agree on Andresen's proposal to raise the maximum size of Bitcoin blocks to 20 megabytes. But with Coinkite and GreenAddress opposing the idea, an industry consensus remains out of reach.
Interestingly, both the proponents and opponents of Andresen’s proposal cite centralization of Bitcoin as their main concern.
Xapo
Xapo founder and CEO Wences Casares explained to Cointelegraph why his company is in favor of an increased maximum block size limit. Echoing Andresen’s concerns, Casares believes that the need for off-chain transactions - that a smaller maximum block size would require - will centralize the Bitcoin ecosystem.
Casares:
“We support Gavin's proposal as we think it is important for Bitcoin's growth and development to get ahead of this hard cap before it is a problem. Many of us are already circumventing this by processing as many transactions as possible off the blockchain which makes Bitcoin more centralized, not less.”
Coinbase
While Coinbase did not respond to Cointelegraph's inquiry, the company has tweeted out in support of Andresen's proposal last month:
Lets plan for success. Coinbase supports increasing the maximum block size t.co/JoP4ATw4ux
— Coinbase (@coinbase) May 6, 2015Moreover, Coinbase co-founder and CEO Brian Armstrong sent out a series of tweets supporting Andresen's proposal as well. In these tweets, Armstrong argued that the proposed twenty megabyte limit is “quite conservative,” as he believes the maximum block size could probably be “100 megabytes or even one gigabyte if needed.”
Additionally, Armstrong explained why Coinbase is in support of an increased block size limit. In his tweets, he argued that Coinbase will “favor decentralization for bitcoin's growth and success,” despite the fact that Coinbase could benefit from an increased need for off-chain transactions.
Furthermore, agreeing with Andresen and Casares, Armstrong believes that “small block sizes will (...) increase centralization right now” precisely because it makes “off blockchain [transactions] more attractive.”
Blockchain.info
When asked on their stance on the issue, Blockchain.info, referred to a recent tweet by CEO Peter Smith, in which he too comes out in agreement with Andresen:
It is time to increase the block size. Agree with @gavinandresen post at t.co/G3J6bqgchu 1/2
— Peter Smith (@OneMorePeter) May 5, 2015Opponents: GreenAddress & Coinkite
But not all web-wallet services support Andresen's proposal. Both GreenAddress and Coinkite have come out against raising the block size limit to 20 MB. While both agree that one megabyte blocks will probably be too small in the longer term, GreenAddress as well as Coinkite believe that a 20 megabyte cap would be too big a jump for now.
Speaking to Cointelegraph, Coinkite Founder and CTO Peter D. Gray explained:
“I'm glad that Gavin has raised this issue and offered a concrete proposal. However, as discussed on the developers’ mailing list, everyone else seems to want gradual growth and not a single large-size step-increase. Coinkite does support a block size increase, although I'm not sure how urgent an issue it is. I feel personally, that 20 megabytes is too big in the short term.”
Additionally, Gray suggested that raising the block size limit would not improve Bitcoin's decentralized nature. Instead, he believes alternative solutions to increase the network's scalability should be sought after. “I would like to see Bitcoin be more decentralized,” added Gray. “However, I'm not convinced that the block size debate addresses those concerns.” He added:
“We feel the way forward is side chains and other bitcoin-related cryptocurrency options that leverage the bitcoin blockchain but do not rely on it for confirmation speed or transaction size limits.”
While GreenAddress has not directly responded to Cointelegraph, the company has previously gone to Twitter in opposition of Andresen's proposals.
At this time, GreenAddress is also opposed to increasing the block size limit as per Gavin's proposal
— GreenAddress (@GreenAddress) May 31, 2015Moreover, GreenAddress posted an elaborate argumentation on Reddit:
“GreenAddress is against immediately increasing the block size with disregards to centralization issues, especially without consensus. We don't think one megabyte is a magic number or the final answer but increasing to 20 megabytes today doesn't make the blockchain scale on its own, you still need likes of lightening network, payment channels and who knows, maybe sidechains or treechains. In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs.”
Bitcoin-Xt
While Xapo, Coinbase and Blockchain.info have come out in support of Andresen's proposed increase of the blocksize limit, all three have so far refrained from any comments regarding his suggested shift from Bitcoin Core to Bitcoin-Xt in order to allow for bigger blocks.
GreenAddress and Coinkite did not specifically state whether or not they would potentially adopt Bitcoin-Xt either, but Gray did explain why he believes such a choice is ultimately up to Bitcoin miners.
Gray:
“I think if no consensus is found, that we probably will not have a fork. If the major Bitcoin miners do not endorse the new specification, and Bitcoin-Xt goes in some other direction, then it would become an altcoin, and 'not bitcoin'. For hard-fork decisions like this one on the table, the miners have basically all the power needed to set policy. And that's how it should be.”
Cointelegraph reached out to BitGo, Circle, Coinapult and Hive as well, but received no response at press time.