OP_GROUP is a proposal to implement representative tokens — also named “colored coins” within the bitcoin community. There have been some objections to the proposal for different reasons. However, there is an additional concern that merits discussion.

Minor or Radical Change?

The argument has been made that OP_GROUP is a small and unobtrusive change. It is, after all, only 50 lines of code. However there is something unique about OP_GROUP that should give the community cause to examine it very closely. Until recently the script interpreter was, by design, a firewalled black box. A script will run INSIDE the interpreter and it will either pass or fail. That is the extent of the interaction between bitcoin and the underlying scripts.

No op code has the ability to interact across the boundary between interpreter and the rest of Bitcoin. Even OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY are not really exceptions, because the scripts using them are only dependent on the coins being spent and the transactions spending the coins. And certainly, they do not allow the script itself to export anything other than the pass/fail result that it usually does.

OP_GROUP takes this one significant step further and in fact, that is its entire purpose. As a script operator it essentially does nothing. Inside the interpreter it is effectively a NO_OP. That is the reason it can be enabled as a soft fork. Its actual purpose is to change the way transactions are interpreted OUTSIDE the interpreter. That is a significant change to Bitcoin design at a fundamental level.

Once an op code reaches outside the interpreter, its impacts are no longer contained with the firewall. It is reaching potentially into the incentive model and likely other unknown places. This is unprecedented in Bitcoin.

Is OP_GROUP Safe?

Crossing that boundary means that technical arguments for its safety within script are no longer satisfactory. It is no longer just a case of asking “Will this break something that currently works?” or “Will this create pitfalls for the unwary script author?”. We should ask: “How will this change the very nature of Bitcoin?”.

Its impact on miners, incentive models, and future changes all must be examined thoroughly. In fact, this raises a broader question about the development philosophy of Bitcoin. The strict boundary between interpreter and the rest of the world is one of the safety features of Bitcoin that sets it apart from blockchains that are focused on non-cash utility.

If, how and why we allow crossing that boundary is something that should be part of the public discourse and hopefully settled before possibly doing it.

In Simple Terms: It’s About Miner Validation.

Different proposals naturally have trade-offs. OP_GROUP attempts to provide a simple tokenization scheme using a single op code, but adds additional consensus rules that miners must enforce.

The OP_GROUP spec lists this “miner validation” as an implied benefit, but as discussed earlier, it has serious implications. Other colored coins proposals do not require miner validation because the blockchain is already securing the coins that are being colored against double-spends.

In other colored coin systems, wallets can validate the correct token balances without additional help from miners by following the chain of transactions from the token’s original issuance. This may present an issue to SPV wallets, but the challenges can be handled.

Weighing the Risks and Rewards of Protocol Changes

There is fairly broad agreement in the Bitcoin Cash community that the primary use case is cash… and that we can add other utility to the chain on the strict condition that there is no possibility of compromising that primary use-case.

Who is in a position to say that for sure? In the absence of certainty, we should be using a “risk/reward” filter for any protocol changes. OP_GROUP lacks basic functionality such as verifiable supply limits, while risking the introduction of major changes.

All changes to Bitcoin Cash so far have either been restoring the original design or fixing critical issues (DAA, CashAddr). Bug fixes require a less rigorous vetting process than feature requests. Not only do they offer higher rewards in the form of resolving a critical problem, but also their behavior is far better understood, since they are a part of existing functionality. Usually the only behavior that is altered in the bug fix is for the unanticipated edge case, a tiny fraction of total behavior of a feature.

If we’re not fixing something that is broken, we have the luxury of taking the time to test and analyze extensively, which is appropriate for a much wider scope of behavior, including a whole new set of edge cases. It is incumbent upon the reviewers to understand the broader implications for the design and until that happens the default position should be ‘no change’.

To do otherwise would be irresponsible because it implies accepting an unknown risk to the primary use case of Bitcoin Cash.