Bitcoin Cash is embarking on what some would call a radical journey by reinstating a number of OP_Codes that facilitate ethereum like smart contracts through a scripting language, although they are quite a bit more limited than eth’s Turing complete capabilities.
That such scripts should be reinstated, as long as it is safe to do so, all seem to agree, at least in principle. Some progress therefore has been made, with agreement reached to include quite a few of them in a May 2018 upgrade.
Specifically, they have agreed to re-instate nine such ops. Some of which have to do with calculations and other more wider coding aspects as briefly described in the bitcoin wiki and as somewhat described by an apparent developer.
No one seems to have much complaint about those agreed OPs, except for perhaps general nervousness regarding review and testing, especially considering they were disabled.
Drama, however, is afoot over OP-Group. This is a proposal by Bitcoin Unlimited as detailed at a high level by Andrew Stone, BU’s lead maintainer, in an October 2017 article.
Basically, it allows for a satoshi to become a token so that like eth tokens the satoshi can represent all sorts of things. Cryptonize.it, a Bitcoin Cash spending hub where you can buy a variety of goods, has one use for it: reward tokens.
The co-founder of Cryptonize has been very vocal regarding the exclusion of OP-Group from the May upgrade, which would push it back to November. He says that would give an unfair advantage to CounterParty Cash (CPC), which he argues is a second layer protocol that uses BCH only as storage.
As opposed to OP-Group, which fully integrates the tokens, making them not much different than BCH itself as far as security and other blockchain qualities are concerned.
He further accuses Amaury Séchet of giving priority to CounterParty which, Cryptonize says, has a partnership with Séchet.
In a response, Séchet did not appear to deny there is such partnership, stating instead he is willing to partner with anyone who wants to further Bitcoin Cash as he clearly believes CounterParty does.
Generally, there does not appear to be any criticism of CounterParty Cash itself, or any that is relevant. The point of contention appears to be that some suspect BitcoinABC might be moving in a direction where only CPC’s functionalities are available.
And more widely it seems there is some general apprehension that the delay to November is a stalling tactic that eventually might lead to the shelving of OP-Group entirely.
Séchet’s public response has been that the proposal is not sufficiently tested. Stone says there is a full node implementation of it. We quote Freetrader, a bitcoin dev that was working on a BCH like fork since 2016, who we think might be impartial. He says:
“It does not seem fair to me to argue that OP_GROUP potentially unlocks some unanticipated risky system behavior and therefore needs more thorough examination, when the draft document on the other new opcodes does not address broader interaction risks but only narrow technical risks.”
The somewhat official response to OP_Group is provided by a Bitcoin ABC dev in a fairly lengthy statement which does not appear to have any concerns about testing, but instead seems to say it doesn’t meet certain criteria. Stone responds in disagreement.
Séchet says “If counterparty breaks, only counterparty breaks. If OP_GROUP breaks, bitcoin cash breaks.” Bitcoin Unlimited supporters have responded with a call to revolt.
Those are the facts as we see them. What exactly is going on we do not quite know, with all of this starting somewhat suddenly yesterday after the decision on what OPs to include was made.
And the reason we do not know is because none of this seems to have been discussed publicly, so we have to rely on she said, he said.
Bitcoin Cash development has apparently descended into Telegram workgroups with summaries published under Chatham House rules where you can not name who said what, only what was said. There is no used mailing-list, there is no video or log we can go back to.
We have not been invited to this group. Doubt any journalist has. There is, therefore, no transparency. No impartial individual that can say this went wrong here.
As such, what we can say is that this method of Telegram working groups is what has gone wrong. Discussions should be fully public, or at least journalists should be invited so that when relevant they can go back to primary sources rather than relying on interested parties commentaries.
In regards to OP_Group itself, we do not have a view where timing is concerned, but if some from BU think matters have gone to a stage of considering “revolt,” then we’d assume they feel unheard.
And considering there appears to be a lack of communication, that’s not very surprising. We can not, for example, find any detailed explanation of each of the OP-codes that are to be reinstated with stated reasons why they were disabled and how such concerns were addressed.
We understand such process took place on Telegram, but unless there was a security reason for it, we don’t see why this shouldn’t be open to all so that there can be public peer review.
Eventually that of course will happen when it comes to Github pull requests, but public discussions might have avoided what now some appear to see as a need to use public pressure.
Ultimately, despite some shortcomings, we do find the drama to be a sign that plenty are keeping an eye and that the matter needs more public discussion.
Moreover, we do much prefer these new discussions on scripts and metatokens and OP-Codes and so on, than the tired and very much dead discussion over the blocksize.
So if it makes everyone forget about what is now very much history and makes them all move on to busy new things, we might perhaps see it with hindsight as the best thing to have happened to BCH since the August 1st fork.
Because we do think it is very exciting Bitcoin Cash will get these new capabilities, just as we think the process needs to be much more improved.