Bitcoin Cash (BCH) Comes of Age – Second Hard-fork in the Works

Wrought in the fiery ovens of acrimony, Bitcoin Cash (BCH) has long been considered a mere altcoin spun off the main BTC blockchain.

It has also been a very contentious subject for all of its existence, as its creators/backers consider it a more pure embodiment of Satoshi Nakamoto’s original vision, than BTC itself.

How is BCH different from BTC though and what changes will this second hard-fork usher in?

A bit of BCH History

On August 1, 2017, BCH split off the main BTC blockchain, through a hard-fork that ushered in a series of rather radical changes, meant to address the scalability issues that were seriously impacting BTC’s usability at the time.

The most significant change was to increase the block size to 8MB, thus cramming much more transaction-data into each one and increasing the overall efficiency of the network.

The move was deemed way too bold by the majority of BTC core developers.

Another BCH improvement was doing away with SegWit completely.

Though technically an altcoin, BCH is different from what the industry usually categorizes under that designation. Its transaction history is the same as BTC’s, that is up until the point where the split occurred.

Another major change ushered in by BCH was to introduce several compatible software implementations.

Indeed, one of the major complaints of BCH developers was the fact that Bitcoin Core was such a dominant force on the BTC network.

They would make sure the same type of status-quo would not occur on the BCH network.

Besides BitcoinABC, the Bitcoin Classic and Bitcoin Unlimited implementations were added.

These approaches – also focused on the increasing of the block-size – surfaced more or less independently, but they eventually added BCH compatibility and joined the bandwagon.

BCH’s next hard-fork pushes the envelope on block-size further, adds smart contracts

As a matter of fact, to simply call the next hard fork’s block-size goals “pushing the envelope” may be a bit of an understatement.

Developers are looking to boost block-size from the current 8MB to 32MB, effectively quadrupling it.

The move might be an aggressive one, but that’s the approach BCH has set out from the get-go, so in that regard, it shouldn’t be surprising at all.

There’s wide support for this aggressive approach too. According to BitcoinABC’s Joshua Yabut, block-size increases are hardly even controversial anymore.

While the advantages such a block-size increase entails are obvious, there a number of other improvements lined up for the upcoming hard-fork, the effects of which are less spectacular, but can indeed be quite impactful in the future.

The additional changes are all aimed at improving the capabilities of the BCH blockchain in various ways, making it clear that the people behind it are set to compete in the future.

Increasing the size of the OP_RETURN field, from 80 to 220 bytes may not look like a big deal at first glance and it is apparently also easy to implement.

Its impact may be significant though, in light of the fact that there are services out there which use this field for rights management, asset creation and other such purposes.

Bitcoin’s rich scripting language

Some of the features that will be added with the fork however will go directly against BCH’s mantra of staying as true to Satoshi Nakamoto’s original vision as possible – or so it would seem at first glance.

For instance, smart contracts will return.

Now then, Nakamoto actually had these built in at the very beginning, but due to security concerns, he did away with them later.

Smart contracts can make it a lot more interesting to pass tokens between users, by impacting the way these transfers are handled.

While some think the original issues which warranted the stripping of these protocols from the BTC code still persist, developers think they have had plenty of time to perfect them and to plug up all vulnerabilities.

nChain coder Steve Shadders wrote a blog post on this issue, in which he details all the op codes that were presumably disabled due to lack of time and way too much caution. Apparently, these codes were – even back then – disabled with possible re-enabling further down the line in mind, as the use of virtual currency would become more complex.

Shadders argues that the fact that BTC was built upon a rich scripting language, clearly points to Nakamoto’s intention to re-activate this part of the code as the use of the currency would call for more complex protocols of transfer in the future.

If that is indeed the case – and it likely is – it begs the question: why are only parts of this powerful script re-activated?

The answer might be more caution, and an affinity towards a gradual approach.

As long as current needs are properly addressed, while ensuring that innovation is covered as well, there’s no reason for the developers to get ahead of themselves.

Furthermore, they will in fact get other chances in the future to add what they deem necessary at that time, knowing already what they will have learned from the aftermath of this fork.

There is another hard fork planned for October 2018.

Bitcoin Cash’s foray into the realm of smart contracts may be an interesting experiment that may draw some conclusions for Bitcoin as well.

BCH is essentially acting as a guinea-pig in this instance. If its smart contracts work out, BTC developers will know that they too can resort to similar solutions. If some sort of unreckoned-with gap causes a meltdown in BCH, the appropriate conclusions will again be drawn.

Will this hard fork result in the birth of yet another altcoin?

No.

If you are rubbing your greedy little hands in anticipation of yet another free-crypto windfall, you can forget about it.

There seems to be general consensus and support for the planned changes, so no one will continue running the old code after the fork.

Still, there is a minority that has voiced concerns about the planned fork, but those concerns are mainly about the fact that the planned tweaks were not agreed upon by the whole community.

This way BCH’s governance model may suffer, with consequences for the future.

As said though, this minority is rather insignificant and not particularly vocal either.

All BCH implementations have jumped onboard the fork, and all have prepared the upgraded code.

Nodes, miners, exchanges, as well as wallet providers have signaled their willingness to tag along, so smooth sailing is what this will probably be.

Indeed, all of the entities named above (including wallet providers) will have to upgrade to continue supporting and handling BCH, so it will take an effort on their part as well.

Skilled politics were indeed involved in the cobbling-together of this rather surprising consensus.

Developers agreed to drop some of the more controversial issues from the fork, like that of OP_GROUP, an opcode used for the facilitation of asset creation on the network, for now.

This though, as well as some other similar issues, may resurface come the network’s next planned hard fork.

The bottom line

The ambitious nature of these changes cannot be denied. BCH is on the warpath and it is looking to compete. Therefore, the impact of these tweaks on its price is likely to be a positive one.

Best BitcoinCash Exchanges

Binance – International

Changelly – International

Coinbase – United States

Best BitcoinCash Wallets

Ledger Nano S

BitcoinCash Scams

BitcoinCasino.us

BitcoinGiants

Coinreum

Crypto Robot

E&E Mining Club

HashMiner.info

Kite Bitcoin

Livia Coins