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)
met
2. (SPV wallets)
met
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.
7. (allowances)
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.
8. (escrow)
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.

 

$10.75
$20.15
Comments
  earned 65.0¢
Hi Andrew. Regarding #3 and 4 - just yesterday I sent you an email to your gmail account with an idea that I think solves this issue. I'd love for you to read it, and see if you agree. Let me know if I should resend it. To everyone else - I'll write an article on it at a later date, it's not intended to be secret, but it's not ready yet for publication.
75.0¢
   3yr ago
25.0¢ 25.0¢ 25.0¢
  spent 10.0¢
Where can we more information about OP_GROUP and the ongoing May fork discussion? I would like to follow the technical developments more closely than just browsing Reddit.
0.0¢
   3yr ago
  spent 10.0¢

0.0¢
   3yr ago
  earned 0.0¢
I would like to add that the members of Bitcoin Unlimited voted over Andrew Stone's "BUIP077: Enable representative tokens via OP_GROUP on Bitcoin Cash" last december.
https://bitco.in/forum/threads/buip077-passed-enable-representative-tokens-via-op_group-on-bitcoin-cash.7501/ The proposal passed with 19 votes for, 0 votes against and 3 votes abstained.
The discussions and votes were public and transparent. No Chatham house rules.
10.0¢
   3yr ago
10.0¢
  spent 10.0¢
If i am a miner, how do i mine btc cash unlimited client? Which pool do i join?
0.0¢
   3yr ago
  earned 50.0¢
I'm concerned that BitcoinABC might be trying to scuttle OP_GROUP because there is some kind of personal interest in Counterparty Cash. Since Counterparty Cash requires some kind of specialized token to function, this motivation could be financial.
If this is the case, then BitcoinABC is making a decision as bad as Blockstream made when they refused to allow larger block sizes in order to push sidechains as a scaling method that they could monetize.
If BitcoinABC is honorable, they'll add OP_GROUP as well as support Counterparty Cash. The ecosystem and market will make the decision on what method of creating tokens is the best. If they keep fighting against OP_GROUP for selfish reasons, then we need to throw more support into the other Bitcoin Cash clients and limit BitcoinABC's power within the Bitcoin Cash community.
60.0¢
   3yr ago
25.0¢ 25.0¢ 10.0¢
  spent 10.0¢
What is Bitcoin Cash's core strength vs other coins? For a while it was the low fee coin, but now that is in question. What problem does or will Bitcoin Cash solve better then all other coins?
0.0¢
   3yr ago
  spent 10.0¢
Here's my idea for implementing Administrative Tokens using OP_GROUP.
It allows for token minting and melting capabilities to be transferred.
0.0¢
   3yr ago
  spent 10.0¢
I think #5 is an important requirement that needs more consideration. IMO it is not outside the scope. I do not have full technical understanding, but consider the following scenario:
We all want Bitcoin Cash to be the world currency in future. To begin with, imagine, a government of one of the smaller, crypto-friendly countries, issues their currency as a colored coin. It goes into wide use within that country with millions of people using it everyday. A tether-like hack (cause shit happens) could put the whole system in danger. If a bitcoin level hard-fork is necessary to undo the damage, it puts Bitcoin Cash in difficult spot. (1) Bitcoin Cash cannot say that it won't hard-fork to undo the damage -- other countries will not sign up and also (2) Bitcoin Cash should not hard-fork -- cause it sets wrong precedent for future.
This is just a random thought. Not sure how much of this is feasible or if it is already preventable.
0.0¢
   3yr ago
  spent 10.0¢

0.0¢
   3yr ago
  spent 10.0¢
Would the ability to recall tokens (and only if tokens were minted as recallable) solve the "Ability to rotate token issuing key material." when paired with the Administrative Token scheme? (https://www.yours.org/content/op_group---introducing-administrative-tokens-f7584a9fc397)
A recalled token would leave behind a transaction on the blockchain showing that the tokens were recalled/melted by a party other than the owners, would it not?
0.0¢
   3yr ago