How has BCH been performing since creation? Why is it important to also review the block-size limit of bitcoin transactions? In this article, we will talk about the effects of block-size modifications.
A brief history of Bitcoin’s Hard Fork
Bitcoin was perfect for speculative investors who fell in love with the long awaited solution to the potential security issue that centralized finance posed for users, by cutting off power from the middle man and putting it in the users’ hands.
However, this eureka moment was short-lived as the encoded default block-size of transactions quickly became an issue. Fixed at 1MB, the limited block sizes also mean that the transactions confirmed per second is also very limited, and to this effect a user can have a legit transaction remain unconfirmed for hours, and even days. This feature has become quite a turn-off especially for newer investors that never experienced the days of smoother flowing transactions due to lesser traffic. Despite having a visible effect only recently, the transactions block-size of bitcoin has always posed a scalability issue for bitcoin and plagued the blockchain network developers.
For a network that plans to contend with the standing financial system and become the globally accepted major means of transaction, a max limit of <10 transactions per second (tps) is a very weak response to Visa’s network handling 1,700 transactions per second (tps) on average with the capacity to handle >20,000 tps.
As the network gets more popular, it gets more congested with new users pouring in daily and as this happens the transactions take a longer time to complete, even with the rapidly increasing miner fees. Nothing is left to impress new users besides the asset’s potential value which is not 100% guaranteed as well.
A brief history of Bitcoin Cash since the hard fork
How was this issue resolved? Developers have been going back and forth on this ever since, and it was in the process of finding a lasting solution to Bitcoin’s scalability debate that the Bitcoin hard fork was performed and Bitcoin Cash (BCH) was created in August 2017 as an alternative and a replacement to the first idea Called SegWit2X (Segregated Witness).
This had the concept of distributing transaction content to maximize block space for relevant details of the transaction while sending the irrelevant bits (the witness) to a seperate cloud storage.
SegWit would’ve only given space for transactions up to 2MB compared to the original 1MB. In contrast Bitcoin Cash allowed up to 25,000 tps with an 8MB block size, later increased to 32MB.
However, according to bitinfocharts, on average Bitcoin Cash never had much cause to use up the 8MB block size for a very long time. It had only used up the block space a couple of times. The first time was to process 37,000 transactions at once on August 16th 2017, when the network recorded more than 80,000 unconfirmed transactions. The network had waited about 2 weeks, and then Boom! the number of transactions surged rapidly going from hundreds’ to thousands in a few hours.
After that, the network recorded some 2MB to 4MB transaction block-sizes which occasionally continued throughout the year 2017 and 2018 after the network experienced a higher transaction average on January 15th 2018, and the highest so far. The network also reportedly processed some 32MB transactions in November 2018, after the block-size limit was quadrupled (8MB x4).
Going into 2019, there was another drought of larger transaction block sizes with an average block-size of 170.14kb up until the year 2021. In fact, the Bitcoin network was processing bigger block-sizes on average as expected, up until February 2021 after the Bitcoin Cash network saw a gradual increase of average block-sizes into the year. The developers of the Bitcoin Cash network didn’t only modify the block size, they also did the same to the difficulty level, by making it readjustable so that the network can thrive irrespective of active miners on the network.
On May 15th 2018 at approximately 1:50 EDT, the Bitcoin Cash network had a major upgrade that increased block size from 8MB to 32MB. Although the network doesn’t often come across block-sizes close to this new limit, it has been useful a few times in decongesting the network rapidly, and proved effective. This batch of modifications on the network also added a few upgrades to areas like the Data-carrier-size, OP_Codes and Binary contracts.
All of these modifications meant that the Bitcoin Cash network got even faster at performing transactions compared to Bitcoin. But the various modifications left a group of community members disgruntled because they felt that any extra modifications besides transaction speed and size was not part of Satoshi Nakamoto’s original vision according to Bitcoin’s whitepaper.
This caused the group to split again in November 2018 and form a Bitcoin Cash hard fork named Bitcoin SV (BSV), SV meaning - Satoshi’s Vision.
Faster transactions will leave happy users, but it will also mean happy attackers, because of the large block-size in comparison with Bitcoin’s own network. Also BTC is way more popular than any other digital asset and so compared to BCH, the user adoption is doing numbers and this also has an effect on the price movement.
Does BTC’s block-size matter?
The block-size limit of transactions processed on the Bitcoin network is directly proportional to the number of transactions that the Bitcoin network can process in a space of 10 minutes (the time it takes to produce a block of transactions). This simply means that the block-size directly affects the transactions processed on the network. As Bitcoin remains the most popular crypto out there, it’s blockchain network reflects the same traffic and always runs at nearly full capacity.
When the network runs at the maximum allowed efficiency, it creates a longer wait period between transaction initiation and completion. That is when we start to witness unconfirmed transactions by their thousands.
Although the average size of a single bitcoin transaction is as low as a few hundred kilobytes, the network has gotten enough notoriety to have far more than the limited 1MB block-size of transactions initiated within ten minutes but due to this limit restriction, the network can only process about 5-7 transaction per second which should be somewhere >300 transactions in a minute.
This is minute compared to some other crypto blockchains that can process up to hundreds of thousands in a second. As it stands, Bitcoin processes the least amount of transactions per second compared to any other blockchain coming after it.
That being said, it’s beyond doubt that the block-size directly sways the speed of transactions on the Bitcoin network.
Does Bitcoin Still Need a Transaction Block-size Increase?
In 2015, before the SegWit proposal came to light, Gavin Andresen proposed an upgrade to the block-size limit on the Bitcoin network.
He came out publicly with his “bigger blocks” proposal in May 2015, giving a very detailed argument against various meaningful FAQs he received from developers and enthusiasts at that time, on why it was the perfect time to roll out bigger blocks.
He proposed an increase in block-size of up to 8MB, which was supposed to progressively increase by 40% after every 731days (two years). This progression would’ve continued till 2036 to make room for the projected increase in traffic and likewise in bandwidth and CPU and cost of storage so as to make sure that miners and developers even from all regions of the world having bandwidth restrictions can tag along.
Until SegWit came along, almost all the other proposals caught minor attention from the Bitcoin Core consensus. Some people may agree, but the majority usually disagreed and since no one can undermine the rest of the team, it has remained so. SegWit was almost a complete success, but further scrutiny dissuaded team members from giving their votes as they felt the upgrade would damage the core of bitcoin’s foundation and make the governing power centralised to some extent.
Even after the SegWit proposal was rejected, there is still the long-standing debate of why BTC block-size should be expanded to 8MB, or not. Arguments for this cause stated; a higher number of transactions processed per second, a less congested network and also the extemporaneous load that off-chain solutions would be challenged with if they were to take that route.
Developers in the opposite direction argued that increasing the block-size may have unforeseen consensus implications that could turn out catastrophic. In addition to that there will be more room for potential reorgs and double-spending from attackers, and in a not so distant future, when BTC gets a lot more global attraction, the block-size would eventually need a readjustment. According to them, increasing the block-size of BTC transactions was just putting away the inevitable and network traffic could easily be dealt with, by making mempool modifications.
The opposition also hammered on the fact that a move in this direction will hamper the trustless network brought about by Bitcoin’s decentralization. To begin with, full nodes will become a much more expensive venture to run and sustain and this will lead to a centralization of power with larger entities controlling full nodes with more power. Swoosh! Out the window goes the trustless factor.
Now you have to hope that whoever runs the most full nodes doesn’t become a villain overnight. Since running your own hash-power requires a full node, most miners may not be able to control theirs without forming a mining pool. Those that can sustain sufficiently on their own make larger miners have less hash-rates and when a single miner, or body owns larger hash rates than most, then the user needs more trust to use the network and it’s transacting asset.
So, why should the network expand the block size to 8MB? The question is pretty much answered at this point, but we are probably a few years away from the best solution for it. The network is very slow at this point, and transaction fees are going through the roof where a user will be charged as much as $15 for a $4 transaction. Increasing the transaction fees to get processed quickly is one solution that won’t work for traders moving small amounts of BTC.
For now, it is uncertain what the future holds as a lasting solution. With the help of Lightning nodes, transactions can be processed off-chain, at very fast speed, for a higher transaction fee, meaning that the user won’t have to wait for a complete block to be found before making their transaction. This is one of the various imperfect solutions, and most of the rest require hard-forks.
Will BTC transactions ever become as cheap or as fast as Credit card payments again? While trying to surmount scalability, will the evolution of the Bitcoin network also require modifications to the core system of governance? One thing for sure, is that the block-size needs to be modified to begin dealing with scalability issues but what we can’t put a finger on is when exactly this solution will arrive sooner or later. Either way, a solution has to come.