BCH developer Amaury Séchet seemingly exposed a secret about the coin’s block size? Cointelegraph speaks to Roger Ver.
Those who have followed the Bitcoin saga from the very beginning know that it’s a mistake in 2019 to only pay attention to the so-called “grandfather cryptocurrency,” as that would mean ignoring Bitcoin’s many relatives (and competitors) that share the same DNA. Bitcoin Cash (BCH), when it comes down to brass tacks, is similar to Bitcoin in most ways, but with one large distinction — it’s bigger block size of 32 megabytes. This is a result of BCH innovator Roger Ver’s idea that scaling should be possible on-chain, without third-party accelerators like the Lightning Network.
This project’s proposed solution to the decade-long debate on decentralized network scaling recently took a bit of egg to the face, when lead developer Amaury Séchet suggested on Reddit that he believes BCH miners are unwilling to process blocks any bigger than 2MB in size.
The claim has been mischaracterized since, but the limits on Bitcoin Cash’s capacity might be relevant after all. Making block size the epicenter of the scaling debate complicates the problem with economics (see below), and the ease with which blockchains multiply may have also impeded the industry as a whole.
Are BCH limits self-imposed?
In April 2009, Satoshi Nakamoto posted to Bitcointalk.org, writing: “The existing Visa credit card network processes about 15 million internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost.”
The next year, the debate began with Jeff Garzik, who posted his desire to see Bitcoin “at least match PayPal’s average transaction rate” and suggested a patch — which later failed to win support — for scaling up the network. Bitcoin still hasn’t reached consensus on the matter, which is why so many projects have sprouted off of it — e.g., BCH, Bitcoin Gold (BCG), Bitcoin SV (BSV) — and on top of it, such as the Lightning Network.
Related: Lightning Network, Explained
An issue that wasn’t anticipated in the early community was that implementing larger blocks does indeed make the chain “wider” and thereby faster — but given the need to simultaneously update every node on the ledger, it also puts greater strain on participants. Larger blocks require more resources from everyone, meaning individual PCs become outpowered.
Therefore, powering the blockchain inevitably lands in the hands of those who have consolidated PC power, invariably resulting in centralization. With a dearth of machines capable of this kind of power anyway, it’s no wonder that the network almost never mines blocks of maximum size, and the average block size largely strays toward 1MB or less. Few have asked if it matters.
Economic entanglement
Block size also throws an economic wrench into the problem, though in the end, it may stem from the idea that a desire for gains in fiat value limits blockchain efficacy, due to the desire for participants to “break even” on cost. It’s true that the hard-forked BCH can technically process a 32MB block, but it does not matter when most miners are unwilling to raise their block size limit.
Related: Bitcoin Block Size, Explained
Block size, like any decentralized idea, is somewhat of a two-way street that must be agreed upon by those who support the network. Miners — and many who are part of the biggest BCH mining pools — don’t have much incentive to allow larger blocks because their fees don’t scale well with block size.
Mining software allows miners to accept or reject payments based on the size of the attached fee, which is itself set by BCH wallets and wallet owners who wish to prioritize their transactions accordingly. Many miners won’t process transactions that don’t have a hefty fee reward, as these can be as low as a single Satoshi, the smallest divisible unit for Bitcoin, and are instead incentivized by the block reward only.
The mempool (i.e., the “waiting room” for transactions in the BCH queue) therefore spikes to over 1,000 regularly, showing the direct effect of soft-capping by mining pools like Antminer, BTC.com and Bitcoin.com. It’s a business risk, as one Redditor pointed out, and somewhat of a paradox: Why would miners tax their hardware exponentially for a minute financial gain, even if it radically advances the ability of their underlying instrument?
With mining already centralized due to the ASIC arms race and profitability, miners get to make this decision anyway. Big blocks such as those supported by BCH naturally delegate the network’s burden to these miners, who begin needing better hardware to support the expectation of faster and cheaper transactions. Smaller blocks put the financial onus on users via fees. If you’re a miner with the ability to determine your software’s max block size, there’s no question which choice you’ll make.
Developers and BCH leaders speak out
The limelight on Bitcoin Cash isn’t going unaddressed. Concerning both the potential impediment that speculation over the scaling competition represents and the real muscle behind larger blocks, BCH developers and even its outspoken founder, Roger Ver, have a lot to say. Asked if Bitcoin Cash truly has a 2MB limit, Ver noted in a conversation with Cointelegraph:
“I’m already working directly with payment companies that expect to reach close to 100 transactions per second with 100M+ users around the world. If BCH had a 2MB limit, they wouldn’t be interested in it, and for this same reason they aren’t considering BTC either.”
There will always be those who are critical of a blockchain solution for its approach to decentralization, or for compromising on relevant principles for speed and mainstream appeal. The ball is in Bitcoin Cash’s court — though, in characteristic fashion, its leader was quick to extinguish doubts and tout the strengths of the product. Ver concluded:
“The 1MB block size limit and censorship of discussion clearly have already set the industry back by close to half a decade, and more mischaracterization of Amaury’s post winds the clock back further. Bitcoin Cash’s block size restriction isn’t true.”
