On May 15, 2018, the Bitcoin Cash (BCH) network upgraded the chain’s base block size from 8MB to 32MB. The software advancement makes blocks big enough to process lots of transactions over time — which gives developers plenty of breathing room to adjust the size if it starts getting closer to its limit. Unfortunately, many misdirected individuals assume the BCH chain will start processing 32MB blocks right away, which could lead to a blockchain chain that’s much larger in gigabyte size and takes longer to download. However, this is not the case right now at all, because BCH miners process blocks that are often still under 1MB, as the 32MB code is only set to ensure the network is capable in the future.
After the Bitcoin Cash network upgraded yesterday and even before the fork, a few misguided individuals asked why there was a need to raise the block size fourfold when 8MB blocks were not filling just yet. The reason developers raised the limit to 32MB is likely because the software is perfectly capable of handling such a task in the future. Right now block size limits are set by the miner, and developers are there to help set the capacity so blocks cannot get full in the immediate future, and fees will remain low for quite some time. Unfortunately for the Bitcoin Core (BTC) network, Core developers let the block size fill beyond capacity, and fees became unreliable during the last quarter of 2017. The 32MB BCH block size adjustment ensures this will not happen to the BCH network down the road, even when transaction usage becomes as extreme as 2017’s last quarter.
Looking at BCH blocks on Coin Dance — a website which records BCH chain data currently shows that mining limits are being set by the mining pool. Over the past nine months, there have been a few 2,4, and 8MB blocks processed, but typically blocks have been a megabyte or less. So in essence, once miners decide its necessary to increase the block sizes they process, they will do so based on transactions and adoption increasing over time. In fact, current data also shows the Bitcoin Core (BTC) chain is still 34.4GB larger than the Bitcoin Cash chain.
At the moment Bitcoin Cash transactions per day are less than BTC as there are roughly 20-25,000 daily BCH transactions. But there’s also been a misdirected notion that the BCH chain isn’t getting much use, but this is simply untrue as data shows over the past nine months that BCH daily transaction percentage rates have increased. The decentralized currency BCH has seen a steady incline (186%) of use since the August 1 fork and the expansion of BCH transactions are now only 5-10,000 transactions less per day than the Litecoin (LTC) network — a cryptocurrency that has been around for 7 years. This is due in part to many Bitcoin Cash-based on-chain platforms like the tipping bot Tippr, the social media apps Memo and Blockpress, and other applications that help increase BCH usage.
Essentially the bottom line is the software is now capable of processing 32MB blocks as it was previously capable of 8MB blocks. So far BCH miners had proven the capability of mining much larger blocks than 1MB multiple times, clearing thousands of transactions from the mempool. After the successful fork on May 15, some BCH supporters are already asking developers to remove the block size limit entirely.
Moreover, we know from testing that the Bitcoin software is capable of processing gigabyte blocks, and research studies further suggest the network could handle terabyte blocks as well. Unlike other digital asset developers, BCH programmers have set the bar high for capacity based on the known advancements in scaling a cryptocurrency network. Instead of saying “we don’t need to scale now,” the 32MB increase establishes a base block size that can efficiently handle 32X more transactions than the BTC network’s highest daily transaction rate recorded this past December.
What do you think about the 32MB block size upgrade? Do you think that the developers should remove the capacity limit entirely? Let us know your thoughts in the comments below.
Written by Jamie Redman