I've watched a large part of the July 5th discussion on the GROUP proposal for tokens on Bitcoin Cash, which sort-of devolved into Andrew Stone and Emil Oldenburg versus (most of) the rest. I think I've figured out the fundamental argument why "the rest" opposes GROUP, which surfaced roughly halfway the video and I'll explain below.

The only trustless token is a non-redeemable token

The landscape of possible token use cases can roughly be divided into tokens that are redeemable for something and tokens that are not. I'll focus on the former first.
Naturally, a redeemable token inherently requires trust that the token will be redeemed by its issuer. The primary argued benefit of the GROUP proposal compared to non-protocol-layer alternatives like Tokeda, is that GROUP can remove some of the trust, by (optionally) removing some of the token management duties from the issuer and simply letting Bitcoin Cash miners handle things.
One particular example recurring in the discussion is the approval of transactions. With Tokeda, the token issuer (or delegate thereof) must approve every transaction involving the token, whereas with GROUP, it is possible to remove the token issuer from this process and leave it entirely to the miners. Thus, it is argued, we no longer need to trust the issuer with the processing of transactions.
...But did we really remove any trust at all?
We are talking about redeemable tokens here. If the issuer disagrees with a transaction, he can simply track the transacted token from there on and refuse to redeem it later, thereby invalidating the transaction after-the-fact. This is not just theoretical; it is exactly what Tether did when funds where stolen from its treasury.
You can try to hard-code rules with GROUP all you want, you can scream "code is law" all you want, you can have miners validate rules all you want, you can point to what transaction is in the blockchain all you want, but at the end of the day, the issuer can always change any rule he wants, even retroactively. He who controls the redemption process, controls the token - this is an unavoidable economic truth. All your base are belong to the issuer; face it and deal with it. A token cannot possibly be more decentralised than the number of places it can be redeemed. A redeemable token cannot have permissionless transactions by its very nature. And if the issuer does not redeem what is rightfully yours, it is always you who has to file a lawsuit.

Issuers freezing tokens is actually a good thing

Once you understand that no matter what, the issuer can refuse transactions anyway, it makes no sense to make futile attempts to prevent this.
While not mentioned in the discussion, when you think about it, it is actually a good thing that the issuer always validates token transactions. If the issuer is not going to redeem a particular token, it's better for the ecosystem if we know it as soon as possible. Specifically, having the issuer approve token transactions has the following advantages:
  • It means you immediately know whether the issuer accepts the transaction, instead of only finding out much later when one tries to redeem the transacted token.
  • It means that when you receive a valid token, the issuer explicitly acknowledges your ownership of it, i.e. your right to redeem. This e.g. avoids the need for exchanges to check deposited tokens against a blacklist that must be kept up-to-date.
  • It means that if someone tries to send you an invalid token, you are immediately aware that it's worthless. (In the video, Oldenburg complains "but then the value would immediately drop to zero...", which is exactly what the value of an unredeemable redeemable token is supposed to do.)
  • It means that invalid tokens are removed from circulation immediately, instead of lingering in the hands of unaware bagholders.
  • It means the entire userbase of the token can immediately detect when the issuer refuses any transaction.
  • It means token transactions automatically stop when its issuer ceases operation, preventing useless transaction load on the blockchain (part of Ethereum's congestion problem).
  • It means transactions can be paused when the issuer has technical problems.

The capability to freeze tokens is not a burden on the issuer either. If the issuer does not care about transactions, he only needs to run a full node that automatically approves all token transactions it sees. For the really non-technical, this task can be trustlessly delegated to a specialised organisation that potentially manages lots of tokens simultaneously.

A protocol change for a hypothetical Caribbean island

Of course, there is still the case of tokens that are non-redeemable by design, i.e. tokens that intend to be a decentralised currency. These use cases seem to be very rare however. Usually, one can simply use BCH directly for such purposes. (Note that transaction fees are paid in BCH in all proposals.)
One other example use case in the non-redeemable category mentioned during the discussion is a small country, e.g. a Caribbean island, that wants to put its national currency on the Bitcoin Cash blockchain. This is completely hypothetical however, and hardly a reason to change the Bitcoin Cash protocol with GROUP now.
Overall, GROUP is thus an (arguably complex) protocol change proposed to remove trust compared to non-protocol-layer solutions, but in the vast majority of imaginable token use cases (redeemable tokens) it provides no clear advantage. In my opinion, "the rest" was rightfully pushing back against GROUP in the discussion. For now, we are probably better off further developing (software for) non-protocol-layer token solutions, and stop making the mistake to consider those second-class solutions.
 

$1.75
25.0¢
Comments
  earned 83.0¢
There is a middle ground here... solutions that do not require protocol changes and also do not require permission to transfer. My thoughts on 'permissioned tokens': https://www.yours.org/content/thoughts-on-tokens-for-bch-a6be7e2ba463
85.0¢
   5d ago
2.0¢ 25.0¢ 25.0¢ 25.0¢ 10.0¢
  earned 8.0¢
There's another name for a non-redeemable token: cryptocurrency.

10.0¢
   4d ago
2.0¢ 10.0¢
  earned 8.0¢
I appreciate your classifications of redeemable/non-redeemable tokens. We need these kinds of frameworks/terms to think and rationalize.
But your article displays a binary thinking. It reminds me very much of the Core philosophy.
To quote Gavin Andresen who probably quoted Voltaire, Confucius and Shakespeare (Nice appeal to authority, huh?): Perfect is the enemy of good.
Ask yourself: What can the bitcoin (BCH of course) blockchain provide for Tokeda or GROUP? The bitcoin invention creates censorship resistant transactions. And a sound monetary policy.
A token piggybacking BCH will not have a sound monetary policy. Because it's ruled by prone to credit printing humans, not competing miners. But the transactions could be censorship resistant to some degree. That's what the blockchain can provide. Why do Tokeda need a blockchain at all, if all transactions at all times are controlled and approved by the token issuer? Why not just a database? GROUP provides the opposite. Lack of central control (yes, to a certain degree). That's the value proposition. Some entities/companies will see the strength of not censoring transactions of the tokens they issue. Others will want to have total control. I think the most successful companies will be the ones that give their customers options and freedom. They will love the lack of detailed control over consumer choices, and have happy, long term customers. They will use GROUP to achieve this.
The losing companies want to control their customers. They will use Tokeda to manage their stupid slaves for their profit. Both strategies have been proven to work under different circumstances. It all boils down to two different business philosophies.
10.0¢
   4d ago
2.0¢ 10.0¢
  earned 73.0¢
OP_Group - totally delivers permissions transfer. With Cash Shuffle transfer will be also untraceable.
Counterparty, Tokeda - requires to run servers that are middlemen in EVERY transfer of tokens there is - when servers'll go down - transfer will STOP.
Somehow proponents of Tokeda are very opposed on-chain solution (reeks of lightning vs block increase conflict) - despite both solutions can and will coexist (IMO OP_Group is superior since it is backed by the best network in the world and Ctrpty/tokeda by brandless unknown noones )
Title says one (complete false) thing - you are discussing other issue: Trust that issuer will redeem tokens. Reeks of blockstream tactics.
ANSWER: If company will refuse its obligation - it'll get sued and sued hard.
75.0¢
   4d ago
25.0¢ 2.0¢ 25.0¢ 25.0¢