There has been a lot of discussion about OP_GROUP. I think we need to activate OP_GROUP as soon as possible (when miners and wallet devs are ready), even though there has been some criticism. Jonald Fyookball posted his arguments, although I disagree with his conclusions.

Jonald writes:

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.

I would argue that OP_GROUP does not change this. OP_GROUP is a NO_OP, or “no operation”. It doesn't affect the script. This is the controversial part, that an op-code is added, but it doesn't affect the validation part of it. What OP_GROUP does is not anything to the script, but adds an attribute to the output, called group . The group identifier would not be used when validating the script itself, but would instead be added as a linked attribute in the input. This linked attribute itself is what the miner and the wallet are validating, not the actual script. The op-code does not escape the black box in any way, it's just viewed from the outside in order to add this attribute.

Andrew Stone has posted a reply to Jonald here . Andrew stated that we already have functions that parse the script and then add attributes to the output. Currently it's isStandard(), if it returns true, the attribute "non standard" is added to the output. Adding getGroup() would not be much different.

The OP_GROUP should not be viewed as a op-code proposal. If you are limited to only discussing scripting and op-codes, the change is very small. "NO_OP7 shall be renamed to OP_GROUP and reserved from being used for other purposes" . The rest belongs in the consensus department of what constitutes a valid transaction.

An input has very few attributes, it's mostly linked output and script signature data. Normally block explorers add these extra linked data, such as address, value, and script. With OP_GROUP, block explorers would need to add a new attribute, group , to it.

In a block explorer, it would look something like this:

{ "inputs": [ { "outpoint": XXXXXXXXXX, "value": 1000000, "address" : "1MKtZDfbAGpFV57Y1DYstnvedV5EBZ3jqL", "group" : "THX65YUkpxVnsZuPv4tC5UjNCGWezuoatz", "linkedScript": <group> OP_GROUP OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG } ], "outputs": [ { "value": 1000000, "address" : "14guwitDYbNAC4ENQYqhErDdco5dncNxWm", "group" : "THX65YUkpxVnsZuPv4tC5UjNCGWezuoatz" "script": <group> OP_GROUP OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG } ] }

In this example, I'm using network address 65 as the prefix for the HASH160 group identifier, it gives the address the initial character "T", for token. Since a HASH160 can originate from both P2PKH and P2SH, there is a need to serialize the identifier into something that everyone knows is a token group.

This may sound like a hack to some people, and as both Andrew Stone and Tom Zander write , it would be ideal to add the group identifier as an output attribute directly instead of in the script. However, by doing so, we introduce a much bigger change which would break wallets even worse. The current OP_GROUP proposal requires all wallets to discard colored outputs from coin selection and wallet balance. That's a quick code change, and if a wallet chooses not to support colored coins, they can simply disregard the outputs. It's a change that only takes a few minutes.

"Perfect is the enemy of done" , is a good old saying. Even though the group identifier would be better suited to be in the output as an attribute, it would be a more invasive and disruptive change that would require all wallets and block explorers to update their code. It would require more testing and take much longer to implement, and it can only be done as a hard fork.

There are many other token standards out there, but all OP_RETURN based standards require client validation instead of miner validation, which requires full nodes. It would require SPV wallets to rely on third party services to implement those coins, if they are even going to implement them at all.

OP_GROUP, being native on "layer 1", has the best chance of getting adopted by every wallet, partially because it would be mandatory for every wallet to update their software in some capacity due to it's soft fork nature (which would be true even if it's activated at the same time as a hard fork), but also because every wallet can adopt it. The Bitcoin.com Wallet, Copay, and Electron can, without much trouble, also implement Counterparty and Omni because they rely on full nodes separated from the user's client, and I would love to have all kinds of token protocols supported in most wallets. We don't have to only choose one.

When Bitcoin Cash was created there were many cases of coins being sent to the wrong chain. A similar issue could arise with OP_RETURN tokens if they become widely used, if a client would allow sending tokens to a wallet that does not support the protocol, making them difficult or impossible to claim. With native tokens using the OP_GROUP, we would avoid this since all wallets can support it. The OP_GROUP based token only does one thing, which is what we want in this case. Most additional features that could be added would be in issuing of the tokens, but those changes would all be in the P2SH domain, and would be independent of the token handling itself.