There is a clear market for tokens. Cryptocurrency is a quarter trillion dollar market and we can see that all kinds of projects are being developed and promoted. In addition, the popularity of "piggybacking" on solid blockchains is obvious (ERC20 tokens on ETH being the obvious example).
It is good for the BCH blockchain to get some of that market share. It would mean more publicity for BCH, more popularity, more usage, and more value. BCH needs every competitive advantage that it can get, as long as we're not doing anything to jeopardize the basic use case of peer to peer electronic cash.

Use Cases

Despite all the scams and frauds we see in the larger cryptocurrency community, there are legitimate uses for tokens. Even as some developers express doubt over the use-cases for tokens, they are clearly identified in both the GROUP proposal and the Tokeda proposal.
As many of the use-cases have been discussed, I won't waste time reiterating them, but we can see the market demanding and using tokens more. The Binance and CoinEX exchanges have their own tokens now.

The Current Debate

In the BCH development community, the current debate is between Andrew Stone's GROUP proposal and adopting one or more token proposals that don't require any BCH protocol change (such as Tokeda).
In basic terms, GROUP expands the transaction layer of the protocol to allow tokens by adding a special output to a transaction called a group authority UTXO. The GROUP proposal is the evolution of OP_GROUP. I had previously criticized OP_GROUP for breaking the abstraction layer between script and consensus. GROUP proposal fixes this concern.
My other chief concern would be if this proposal changes the economic incentives for miners. If enforcing the GROUP consensus rules is not more computationally expensive on a per byte basis, then I would argue that the economic incentives have not changed, since fees in Bitcoin are priced in bytes.
Determining whether it or isn't actually more computationally expensive would require analyzing and/or testing a specific reference implementation of the proposal.
Unlike with OP_GROUP, I have not heard technical arguments that point out something specifically wrong with the GROUP proposal. The main concern that other developers have is that the change is somewhat substantial to the BCH protocol. This naturally comes with risks of unknowns, along with technical complications, technical debt, and "unhardening" of the protocol.
A question was raised how GROUP will affect UTXO growth, and I haven't seen an analysis of this.

Risk vs. Reward

Token proposals need to be evaluated on a risk/reward basis. How much benefit does each proposal bring to BCH, and how risky is each one? Proposals that do not require modifications to the BCH protocol essentially have zero risk, since they aren't changing anything. So the question then becomes: How much risk does GROUP represent, and what does it provide that is better than the alternatives?
The main benefit of GROUP over other proposals seems to be that it is "SPV friendly". To understand what this means, you should understand the SPV security model. With SPV, a user can determine if a transaction is valid by checking the transaction against the merkle branch and the block headers.
Presumably, GROUP supports SPV because transactions that move tokens are enforced by miners; therefore if the token trasnfer is part of the transaction, and the transaction is part of the block, then the token transfer is inferred to be valid.

Alternative SPV token models

In the absence of something like GROUP, the challenge is that verifying if a token transfer is valid requires parsing the entire chain of transactions back to the origin of issuance. For token proposals that don't modify the BCH protocol, how can we accomplish this? One way is to have service nodes ran by the issuers or others that want to support the token ecosystem.
One such class of service provider could be BitDB-powered nodes.

Permissionless vs Permissioned Tokens

There is some talk of a 'permissioned' token scheme where the token issuer signs off on transfers. By providing a signature at each transaction, this solves the SPV question. The argument in favor of this scheme is that a token issuer already needs to be trusted to provide whatever value their token represents, so nothing is lost by also relying on them for transfers.
I find these arguments to be specious.
Just because the token issuer needs to be trusted to redeem the token does not mean there isn't a value in making transfers permissionless.
Also, the whole point of using a blockchain is to allow distributed consensus. If instead, consensus depends on what a central authority decides, why use a blockchain?
This logic is reflected in the reality of the markets. Permissioned tokens on a public blockchain do not even exist. There's zero demand or market for it. (At least no one so far has given me any examples. Please correct me if I'm wrong).
On the other hand, there's a quarter trillion dollar market for crypto tokens. Promoting the idea that the market really wants permissioned tokens over permissionless tokens when the reality says the opposite is in the territory of delusion.
However, it should also be pointed out that the need to support permissionless tokens does not necessarily mean we need GROUP.

A Universal Token Standard for BCH

Something like BitDB could be used to allow SPV wallets easy access to token balances could perhaps accomplish what GROUP seeks to do without a protocol change.
But there needs to be probably be ONE agreed upon standard. With tokens, the scaling burden on a BitDB style node is multiplied. Instead of maintaining one UTXO set, it now needs to support "N" UTXO sets, where N is the number of unique tokens. This is not unfathomable, but at the very least there should be a universal method used across all tokens so that the same rules could be easily applied to the meta data.

Conclusion

Whether or not we should change the BCH protocol to add GROUP is a risk/reward question and a matter of opinion.
Part of what made ERC20 so successful is how easy it is for anyone to create and issue a token, and for the ecosystem to support it. The BCH protocol already allows colored coins but no one uses it because the ecosystem doesn't support it.
One nice thing about GROUP is that by adding it to the protocol, the ecosystem would more easily adapt to support it, and you could argue that this also part of the ERC20 success.
However, this is not a strict necessity.
The ecosystem could adapt by convention, perhaps driven by a service provider such as BitDB. I would personally recommend we explore such an option. In any case, I believe BCH would greatly benefit from a universal method for doing SPV-friendly, permissionless tokens.
 

$13.25
$13.50

Reviews
21 of 21 reviewers say it's worth paying for

0 of 21 reviewers say it's not worth paying for
Comments
  earned 10.0¢
+100 on the absurdity of permissioned-transfer tokens. There are things that are obviously better off centralized, and that's one of them.
35.0¢
   2wk ago
25.0¢ 10.0¢ 25.0¢
  earned 0.0¢
Just a thought, but permissioned tokens could be used by an authority to a trust agreement. In a typical trust, the trust actual has title to the assets, but also distributes to beneficiaries. It does not seem like a stretch to think that there is some place for these capabilities, but I don't think that this is the lion share of the market for token use.
0.0¢
   2wk ago
  spent 25.0¢
"there's a quarter trillion dollar market for crypto tokens."
lets not forget that's 100% ALL nothing but hot air without a single sensible end user product. (yes markets are often delusional) Permission-less transfer with permissioned redemption really seems to make no sense. All of those tokens would work better centralized.
That said, sure, let's do tokens ..whatever helps to gain more market share :)
0.0¢
   2wk ago
25.0¢
  earned 0.0¢
Also, it seems to me that the Holy Grail in token talk would be to have tokens able to appear in wallets, where the wallet could query a database and show the type of token that it is, distinguishing it from plain vanilla BCH. I also think said tokens need to act as bearer instruments, so that once conveyed to another party, said party picks up with the rights associated with said token, whether it be quarterly dividends or a free ice cream. At least these are the use cases that I want beyond cash.
Thank you for your work!!
0.0¢
   2wk ago
  spent 25.0¢
In addition to risk assessments, I think protocol level changes demand risk mitigation such as ensuring libraries exist for all popular languages to support the change. Anyone using 3rd party, or internal proprietary libraries which de-serialize transactions and decode outputs are going to need to be updated. I'm happy to have BCH aggressively developed, but changes such as GROUP (which I'm supportive of) externalize development efforts to all the services in the community. Not everyone has the same amount of in-house talent, budget, or time to turn on a dime and modify sensitive code, and to properly test changes. I don't want to slow BCH down; it is imperative that we charge forward. I just ask that those who are making the decisions to change the protocol do so with ample lead time, and assess how broadly the changes will be supported by the body of software tools (not just full nodes.)
0.0¢
   2wk ago
25.0¢
  spent 25.0¢
I think the core difference between permissioned and permission-less is the notion of transfer without the middleman. BCH is built with the hardcoded rule that transfers must not require any middleman. It seems to me that the new group proposal is generic enough to support both models.
With the new group proposal, an address may hold BCH, tokens and token group authorities. If we view token transfer as an authority, we could see that BCH is similar to any other token with few exceptions. All addresses with bch balance have the transfer authority as the default, which makes it permission-less. Permissioned tokens on the other hand strict control which addresses can perform the transfers—only the issuer controlled addresses has the trans authority; holder addresses onl has redeem authority.
So perhaps, we should explore the possibility of supporting both models simultaneously.

0.0¢
   2wk ago
25.0¢
  earned 0.0¢
The GROUP protocol the way you describe it certainly reads to be a safer direction.
TOKEDA, perhaps, not so much:
--------- "For token proposals that don't modify the BCH protocol, how can we accomplish this? One way is to have service nodes ran by the issuers or others that want to support the token ecosystem. "
This particular point has the look and feel of something susceptible to serious problems. If the GROUP proposal does not require or suggest "service node" arrangements upon which financial values are dependent then perhaps it a more reliable choice.
"Service nodes" for non-financial things like memo.cash lend themselves less to being part of a fragile exposure to threats. Absent any direct financial value altering, they can in may ways be regarded as benign.
"service nodes" which may be able in some manner to rescale financial values referred to by token values are possibly not benign: How they function (or more importantly, malfunction) could possibly effect the basic market value of BCH.
Something that has immediate (and possibly substantially higher) value dependent upon externally coupled dependencies (redolent of things like LN and SEGWIT) seems perhaps to be an unfortunate direction to pursue. --------- From the TOKEDA link, this particular thought reads like it needs some serious reconsideration:
"Also, by using multiple signatures, Tokeda offers the possibility to the issuer to delegate the relaying work to specialized trusted companies who would execute the mundane token relay transactions."
That right there triggers OCD hesitation loops. --------
On the GROUP implementation, building DAG capabilities (as discussed in the link) into BCH is indeed exciting.
The TOKEDA paper does note that "OpCodes stay forever" which needs to be carefully considered before any commitment to GROUP.
I do hope a lot of thought and reconsideration goes into whatever is chosen, and that a lot of experience is learned from the ETH/ETC devs who, to their credit, have already dealt with such coding.
---------- as written by @bvk: "So perhaps, we should explore the possibility of supporting both models simultaneously." We probably will, anyway. -----------
Keep writing !
25.0¢
   2wk ago
25.0¢ 25.0¢
  spent 25.0¢
I'm definitely for Tokeda - purely voluntary. We can at least try what works before going to radical and risky things like "group". I am actually very confident that Tokeda is just hands down "correct". But sure, long and thorough (uncensored) discussion needs to be had.
Basically separating out the strict UTXO set of BCH outputs for use as money from a potentially enourmous superset of UTX (whole transaction + metadata) for tokens attached to this UTXO set... basically creates an economy around bitcoin cash rather than clogging up the money of bitcoin cash and --> harming scalability by orders of magnitude (in 'group'). This is already how OP_RETURN works today with ability for pruning as/when the need arises. We just need to give it time - we still don't even have good development tools to make this process easy! This is how memo.cash and blockpress work currently (OP_RETURN prefixes etc. and querying of the metadata)
The miners are not going to be forced to persist all of this metadata in the future (which is a good thing) but if economic incentives are aligned then (for a fee) many miners et al. will specialise in persisting this metadata. (I think this is the basic idea). If you cannot afford to pay (because you are not profitable enough per byte used) - your idea / business etc. is meant to die in the market so that UTX storage space can be recycled for use by someone worthy - this is capitalism. Specialization and aligned economic incentives - maybe metadata will be slightly more sat/byte because it must be persisted potentially forever whereas the UTXO set is a bit more nimble and can be consolidated into larger bitcoins to reduce the size (also can be economically incentivised behaviour to join rather than split coins). Tokeda is high functioning. Simple. Scalable. No change to protocol needed. And also adaptable with the ability to add new features as your token grows in value and useage. At some point, blockchains need to interact with the real world. Tokeda seems to be cognisant of this fact. I am very concerned about the risks of 'group' personally. The whole point of bitcoin cash was for scaling p2p cash for the whole world - we currently have a REACHABLE TARGET of 500GB to 1 TB and I have no interest in simply replicating ethereum and ruining this linchpin of BCH... just go buy ethereum! (They are already having major major issues with scaling because of their core design and they will continue to churn through far far more blockchain space for the same utility vs Tokeda concept). Tokeda is perfectly aligned with everything that bitcoin cash stands for. I think that 'group' potentially threatens it and could turn us into a poorly-scaling ethereum wannabe. We can be 100x bigger than ethereum if we do this right. Ethereum tokens could even be copied and ownership ported over to bitcoin cash (because we will have such abundance of future capacity with Tokeda... if you're willing to pay for it)
Bitcoin is an economic system first and foremost that happens to use cryptography and computers to make it work. We cannot just hold miners hostage to store every last scrap of metadata on the blockchain forever - scaling through lean UTXO consolidation will be set back by orders of magnitude... will tremendously hurt scalability. We have to keep the metadata prunable as with OP_RETURN and have voluntary protocols for creating tokens and utilizing efficient, lean BCH as the cash system to make it all possible. Bitcoin as cash for the world cannot ever be jepordised again. 'Group' would be an irreversible error in my opinion and can never be undone
0.0¢
   1wk ago
25.0¢