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¢
   4mo 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¢
   4mo 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¢
   4mo 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¢
   4mo ago
25.0¢ 2.0¢ 25.0¢ 25.0¢
  earned 23.0¢
>Naturally, a redeemable token inherently requires trust that the token will be redeemed by its issuer.
This is retarded. Tokens issued by a central issuer need not "redeem" its value at that central point. I've given some examples on Reddit:
------
Any token use that has a decentralized "redeeming" system will require trustless token transfers . Consider:

  • A token that is issued once by a game developer, but then was set loose in said game as competitive rewards. More tokens give you better gear, and is "enforced" only by common game clients instead of by a central server.
  • A discount token issue by a bazaar co-operative periodically. Individual vendors in the bazaar can honor tokens without consulting a central authority.
  • A country wishing to issue an entire fiat system, implemented as bearer instruments (instead of permissioned system), on the chain.
25.0¢
   4mo ago
2.0¢ 25.0¢
  earned 23.0¢
This is a black-and-white view that applies equally to Bitcoin Cash. Since BCH tokens can be traced (are not technically fungible), it would be possible for an authority to announce that tokens at some address are valueless and require that all exchanges and merchants comply or be fined. This is why fungibility improvements to BCH are extremely important, and any such fungibility improvements will naturally also benefit Group tokens. But techniques to increase fungibility already exist, and techniques to create compliance havoc given such an announcement (such as sending dust from the illegal UTXO to millions of known addresses) have been invented.
In practice, one use of tokens is stock. And that use is so large that even a fraction of it would justify enabling tokens on Bitcoin Cash. In this application the redemption argument is frankly jaw droppingly ignorant and specifically the "straw man" fallacy, because stock is almost never redeemed (only during bankruptcy, and in that case its redemption value is generally near zero so why bother). It is bought and sold in exchanges worldwide, similar to BCH. And actually, the Group proposal includes a P2P, pseudo-anonymous, uncensorable, exchange mechanism.
Also, "deferred trust" is incredibly valuable, although its benefits are clearly unknown to many in that meeting. For example, a token-based bond transfered to an individual (say an individual without legal access foreign markets) can be transfered (sold) back to another individual who is capable of redeeming it.
In contrast, a system where an authority must "OK" every transaction is a perfect place for an intervention where identified accounts, AKA whitelisting, are mandated.

25.0¢
   4mo ago
2.0¢ 25.0¢
  earned 0.0¢
Response to Andrew Stone’s comment
This is a black-and-white view that applies equally to Bitcoin Cash. Since BCH tokens can be traced (are not technically fungible), it would be possible for an authority to announce that tokens at some address are valueless and require that all exchanges and merchants comply or be fined.
This does not apply equally to tokens and Bitcoin Cash itself, because Bitcoin Cash does not have such a central authority. Nation states may exercise some control, but only within their borders. The crucial difference is that tokens are far more centralised than Bitcoin Cash, with usually just one central issuer with full authority in the entire world.
This is why fungibility improvements to BCH are extremely important, and any such fungibility improvements will naturally also benefit Group tokens. But techniques to increase fungibility already exist, and techniques to create compliance havoc given such an announcement (such as sending dust from the illegal UTXO to millions of known addresses) have been invented.
If we want to make a redeemable token permissionless to transfer, fungibility is indeed critical. Perfect fungibility makes it impossible to approve or deny transfers on a case-by-case basis, because you cannot see what is going on. But this applies to GROUP as well as to Tokeda: with strong fungibility, the issuer can only sign all transactions because he does not know which transactions to refuse. Compliance havoc does not apply to the issuer himself, and can furthermore be prevented with timely action; if needed, the entire chain of descendent transactions can be reversed.
In practice, one use of tokens is stock. And that use is so large that even a fraction of it would justify enabling tokens on Bitcoin Cash. In this application the redemption argument is frankly jaw droppingly ignorant and specifically the "straw man" fallacy, because stock is almost never redeemed (only during bankruptcy, and in that case its redemption value is generally near zero so why bother). It is bought and sold in exchanges worldwide, similar to BCH. And actually, the Group proposal includes a P2P, pseudo-anonymous, uncensorable, exchange mechanism.
The stock example is practically the same as the other examples. Yes, there is no literal redemption, but surely you want to collect dividends or exercise voting rights - which is basically the same as redemption, except that you get to keep the stock. Can a blockchain cryptographically enforce dividends are paid fairly? No. Can a blockchain cryptographically enforce your vote is counted? No. It is the exact same trusted setup. If the company does not recognise the validity of a stock, e.g. because they did not agree with a transfer, then you need help from either a court or public outrage. But Bitcoin Cash miners cannot help you.
Also, "deferred trust" is incredibly valuable, although its benefits are clearly unknown to many in that meeting. For example, a token-based bond transfered to an individual (say an individual without legal access foreign markets) can be transfered (sold) back to another individual who is capable of redeeming it.
In contrast, a system where an authority must "OK" every transaction is a perfect place for an intervention where identified accounts, AKA whitelisting, are mandated.
If identification is mandated upon transfer, GROUP cannot be used. If identification is not mandated upon transfer, the bond example works even on a system like Tokeda, because the issuer has no reason to not sign the transaction. So the question remains what the "deferred trust" offered by GROUP is unique.
0.0¢
   4mo ago