On Feb 15 some Bitcoin Cash developers had a meeting to discuss features for the May 2018 upgrade. Although this meeting is not authoritative (because ultimately majority hash power determines the fork) it was pretty important. A major topic of dissension was my proposed OP_GROUP feature. Although this meeting took place under the "Chatham house rules", I can self-report that I asked dissenters to produce a clear and public written document specifying their concerns, and why they oppose including OP_GROUP in the next upgrade.
I am therefore pretty sure that the document "On Representative Tokens (Colored Coins)" represents the reasons why the ABC client seems to be currently planning to NOT include OP_GROUP in the May upgrade (yet the document does not say so explicitly so forgive me in advance if I am wrong, but that was the strong impression received during the upgrade meeting last week).
But I believe that tokens and OP_GROUP is a very important feature needed to drive adoption of Bitcoin Cash, so it is not respectful to the community to leave its status ambiguous.
I would like to refute the arguments contained in the document.
But before I get into specifics, the most important idea to remember is that although OP_GROUP is a single, simple opcode that enables tremendous functionality, it is also just a first step. It will not perfectly meet the requirements of every tokenization system. But Bitcoin Cash Script and OP_GROUP can be extended to meet these requirements as they become apparent. It is therefore a first step in the right direction -- by integrating tokens with Bitcoin Cash Script rather then create a parallel system, new features apply to both the native token and to representative tokens.
Once tokenization happens, the second step can add additional great features -- perhaps covenants, group control scripts, or something we haven't considered yet. But these features are all additional code, testing, and complexity. We will not move from zero to every imaginable token feature in one release, and doing so would be irresponsible.
On the 9 requirements:
1. (issue and destroy tokens)
2. (SPV wallets)
3. and 4. (rotation, revocation, and backup of administrator keys)
Potential solutions are: A trezor in a safe for safety-deposit box, Shamir's secret sharing, wrapping the key in an encrypted envelope, or destroying the key are all options. Yes, some are not as secure as an on-blockchain solution because the key must ultimately be reconstructed on a single computer. But physical security can mitigate that risk for the short duration that the key exists.
It would be great to have these features on-chain, but should the protocol developer eliminate all tokens simply because administrator key rotation is not available on-chain? Are these even really needed for every token type? What about short lived tokens (like stock options), or rentals? Can we even sit here and enumerate all possible uses of OP_GROUP?
And these features are not without cost -- they open up new attack vectors. For example, attacker could rotate or revoke the admistrator's keys leaving himself in sole control.
5. (recall tokens)
In my opinion, this "feature" drives a stake into the heart of ownership. 100 shares of X may be worth nothing, but you should be able to prove that you currently own 100 pieces of that nothing! One tremendous advantage of putting stock on the blockchain is to roll back the current situation where the individual does not actually own any stock. The reality (in the USA at least) is that your broker owns the stock and you get a promise. So enabling arbitrary token recall undermines one of the main reasons to place securities on the blockchain. Tether was unfortunately hacked and 30 million USDT printed, but the best solution may not be to undermine the concept of ownership for all future token holders.
Regardless of your opinion on ownership, requiring this feature is pushing a business model decision onto all token administrators. I suggest that the token administrator should be allowed to choose the best solution for its token.
The Tether hack problem has a solution using OP_GROUP today. To mint tokens in the OP_GROUP system, the administrator (or thief) must first send satoshi to an address controlled by the administrator's key. Only can that satoshi be minted by spending to a grouped address. Therefore, an administrator monitoring the bitcoin network for unauthorized mint operations could spend these (pre-mint) satoshis to another address in his own wallet, stealing the attacker's funds and halting the minting process. This is an example of "reactive security" similar to what is employed by the lightning network.
And, in the near future, some very interesting possibilities are possible with Covenants, including onchain "smarter contracts" that enforce arbitrary administrator policies, and "vaults" that could delay the minting process and therefore allowing arbitrary time for the administrator to spend pre-mint satoshis.
6. (verifiable supply limits)
Most current securities do not have supply limits -- or rather changing the supply limit often just takes a boardroom vote. So how can we use this missing feature as an argument to not deploy OP_GROUP?
And although supply limits would be nice, are they in reality polite fiction for may use cases? For example, even if TOK is limited to 10000 units, the issuing company could simply issue 10000 units of TOK2 with the same rights as TOK.
Ultimately a blockchain cannot be used enforce laws -- and your recourse as a token holder is legal not technical.
But as the expressiveness of Bitcoin Cash Script grows, we may be able to add this feature. For example, Chris Pacia noted that it can be solved given an opcode that reports the chain height OP_CHAINHEIGHT). This is a general purpose opcode that may be useful in many other scripts, tokenized and not.
Allowances are details about the object being represented by the underlying token. For example, allowances may specify the range of quality allowed in the delivered underlying commodity. In the OP_GROUP system, the specific legal details of a token can be specified in a signed document specified by URI in the OP_RETURN field of the minting transaction.
Its questionable whether operations on allowances will ever be usefully expressible in a blockchain. To do so, one must first solve the fundamental question of importing accurate data on, say, the number of broken chicken eggs in a shipment of 1000 cartons. You can watch a lawyer's take on the problem here.
Any grouped output can be spent to a N-of-M multisig in the exact same way that escrow of BCH is implemented today.
9. (Transferable only under rules specified by a smart contract)
Today using OP_GROUP, an administrator can easily maintain complete control of tokens by only minting to a 2-of-2 multisig address, where the administrator is one signer. The administrator subsequently refuses to sign any subsequent transfer that does not follow his rules, including that all outputs are to a 2-of-2 multisig address where the administrator is one signer (to enforce the same on future transfers). This is a centralized solution.
In the future, deployment of covenants into Bitcoin Cash would enable smart contract enforcement in a decentralized fashion.