There is no such thing as permissionless transfer of redeemable tokens

This article was originally published in 2018 on Yours.org.

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.