Bitcoin Cash plans the next hard fork and storms straight into a controversy. It's all about a proposal to bring native tokens to the blockchain. While the community is celebrating the dispute and is looking forward to reactivating numerous script commands, there are also doubts about the role of nChain's patents in decision-making.
Bitcoin Cash wanted a decentralized, uncensored discussion of the development. Now the community gets to feel how exhausting that can be.
The involved developer team, such as XT, Unlimited and ABC, have agreed there should be regular protocol upgrades via hard fork. The first hard fork should be determined in mid-May and later activated. However, if the intention was to establish a framework to plan such regular hard forks peacefully and contemplatively - then success will be modest. Because the discussion was neither constructive nor peaceful.
At issue is the reactivation of disabled Op_Codes from Bitcoin's scripting language, increasing the maximum block size to 32 megabytes and increasing the limit for Op_Return content to 80 bytes. When exactly and how the hard fork should take place is not clear. It is anticipated that hard fork will take place on May 15, but there is no official announcement that it will actually be. On February 15, this was "Feature Freeze" - from this day on, the deadline for recording new features was in the debate.
Op_Group: A competitor to ERC20?
The example of Op_Group shows that the planning process is anything but satisfactory. With this new Op_Code, Andrew Stone of Bitcoin Unlimited has proposed a way to bring native tokens to the Bitcoin Cash blockchain. Anyone who has ever dealt with tokens, Ethereums ERC20, ICOs and Colored Coins knows that this can be a big deal. Among other things, it makes it possible to bring tokens into SPV wallets and process them independently of external protocols, such as colored coins or counterparties.
If Bitcoin Cash wants to keep up with Ethereum for tokens, something like Op_Group is absolutely necessary. As a result, Andrew Stone's proposal was quite sympathetic, for example, by OpenBazaars Chris Pacia, and hard fork in May seemed to be a great opportunity to implement it in a solid and straightforward manner. Since Andrew Stone had already published his concept in October 2017, there should have been plenty of time to test and think it through.
However, Bitcoin ABC, Bitcoin Cash's reference software, Op_Group, is unlikely to be included in the list of upgrades that will be eligible for hard fork in May. The reasons are not completely transparent. ABC's Shammah Chancellor made a list of nine conditions for perfect tokens and stated that Op_Group did not fulfill them. Craig Steven Wright, the well-known alleged Satoshi and chief developer of nChain, announced via Twitter that Op_Group was unnecessary and not sufficiently tested. Jonard Fyookball, chief developer of Electron Cash, said Op_Group was potentially dangerous because, unlike other scripts, it changed transactions outside the script interpreter. To introduce this without extensive testing is too great a risk.
On the other hand, it is also said that Op_Group has never been discussed, and that there have been no attempts by Bitcoin Unlimited to make it a candidate for the hard fork. Which somehow makes sense, since Op_Group can also be introduced via soft fork. Either way, all this does not sound like sunshine and constructive cooperation. Also, Bitcoin Unlimited's Andrew Stone challenges the criticism of Bitcoin ABC, showing that there is not really any consensus here.
Satoshis lost Op_codes
It is a shame that OP_Group does not fit into the hard fork features in a way that is not transparent, especially because it is the only feature that has an easy-to-recognize added value for users. Native tokens on the blockchain are awesome and necessary if Bitcoin Cash ever intends to compete with Ethereum.
Significantly less obvious is the benefit of having nine OP_Codes to be reactivated. Satoshi implemented these codes in the original design, but after one of them had a security vulnerability, all Op_Codes that you did not really need were disabled. Bitcoin Cash now wants to re-enable as many as possible. Discussions include Op_Mod, Op_Div, Op_Cat, Op_Split, Op_and, Op_or, Op_Xor, Op_num2bin and Op_bin2num. These codes represent various commands for the scripting language of transactions that can be used to create various smart contracts. They allow simple operations, such as the concatenation of two variables.
But nobody seems to have a concrete application in mind. At least none of the developers could tell me exactly what to do with the Op_Codes, except that they enable a lot more commands and smart contracts. The most specific applications I was able to tease out were a lottery on blockchain and the reinvention of multisig. There has also been no public discussion of the risks associated with Op_Codes, even though the developers have set up various measures and tests. Nevertheless, it is relatively unclear to the community for what purpose to take which risks.
The role of nChain and the patents
One of the most unpleasant aspects of hard fork are the doubts of what role nChain plays. As a reminder, nChain is the company of Craig Steven Wright, through whom he has filed more than 200 patents. Allegedly, these patents are intended to protect the technologies developed by Craig Wright only from being used on other chains than Bitcoin Cash. Even if this were so - I do not know if that is legally possible - this would be consistently criticized. Because Bitcoin Cash defines itself as having split off from Bitcoin through a hard fork.
nChain has now made a significant impact on the ecosystem of Bitcoin Cash. It supports, among others, Yours and Electron Cash and has participated in the negotiations for hard fork. The fact that nChain has several patents on tokens on a blockchain (here, here or here) makes it at least a bit questionable that the company is involved in a decision-making process that Op_Group has at least not supported. Also a suspicion that the now to be reactivated Op_Codes are already part of applications that nChain patented or would like to patent, has not been refuted or even refuted.
Even if all those doubts turn out to be unfounded, if nChain's patents had nothing to do with them, but nothing at all about the Hardfork decisions, even then there would be a fierce connotation that Bitcoin Cash would allow a company with such a patent obsession has gained such influence in the ecosystem.
Quite apart from that, the cryptocurrency has yet to practice the matter of public, decentralized planning and discussion of hard forks. Otherwise, this is a recipe for a disaster.
After months of waiting, the time has come: Bitcoin Core has released a new version of the client, which SegWit has integrated into the user interface. This could be the long awaited breakthrough for SegWit. Especially since Coinbase and Bitfinex are starting to switch to SegWit.
SegWit, the protocol extension, which is also an increase in block size, was already activated at the end of August 2017. But the implementation of the new transaction format has been extremely sluggish so far and has barely reached more than 15 percent after about half a year. One of the reasons may have been that hardly a wallet supports SegWit. This is changing now.
The new release of the most important Bitcoin software, Bitcoin-Core 0.16.0, brings SegWit into the user interface of the client for the first time. By default, new addresses and change addresses are created as a P2SH SegWit address. These addresses are in the same format as the previous addresses, but start with a 3, as it is known from Multisig addresses.
Alternatively, you can now generate "bech32" addresses by ticking in the appropriate place. These addresses start with "bc1", are a little bit longer and consist of small letters only. I already wrote about the advantages of the new format when Electrum became the first wallet to integrate the new format. Since Core now also allows to send bitcoins to a bech32 address, it might make sense to use SegWit with Electrum.
Alternatively, you can now generate "bech32" addresses by ticking in the appropriate place. These addresses start with "bc1", are a little bit longer and consist of small letters only. I already wrote about the advantages of the new format when Electrum became the first wallet to integrate the new format. Since Core now also allows to send bitcoins to a bech32 address, it should finally make sense to use SegWit with Electrum.
In addition to the dozens of other small bugfixes and minor improvements, it is likely to be significant that Core 0.16.0 makes Replace By Fee (RBF) the standard. This will be a relief to anyone who has ever had a transaction in MemPool - but it may not be helpful if you want to pay without waiting for a confirmation. Here you have to turn off the option manually, which is very easy to do with another tick box.
The fact that the most important Bitcoin software now supports SegWit, could be a milestone for the widespread application of the new transaction format. After all, Core is the basis of countless platforms and other software. Equally helpful is the fact that the major American currency exchange and online wallet Coinbase since this week begins to integrate SegWit, and also the large stock exchange Bitfinex began a few days ago to use SegWit.
Image Sources:
- Article headers created by myself
Have a nice day!
ⓁⓄⓥⒺ & ⓁⒾⒼⒽⓉ
Best regards
