Why I don't see the point of group-tokens

A couple of months ago we saw a revival of interest in the miner validated tokens idea for Bitcoin Cash. I ended up spending about 2 full time weeks investigating the proposals and the ideas behind them.

One of the proposals is Andrew Stone's GROUP, which got more airtime recently. As I spent time understanding the ideas behind it for those weeks, I realized that there is a lot of hype and not really all that much meat.

Take a look at what we have today:

SLP

This is the basic of tokens today on BCH. The Simple Ledger Protocol is great in that it is completely decentralized and does not require miners to approve what people are doing. We can receive new features without there being any need to ask permission for such upgrades and without miners needing new software.

The downside of SLP is that we need a service that extracts the SLP payment information from the blockchain. Any wallet or client technically could get this from a BCH node, but it is very impractical to do so. So, we have SLP servers and SLP databases that wallets and websites can use. These services have a large number of functions. They map token-ids to its name and trading-code but also provide icons, balances and many other details. And, naturally, they validate the data to be correct.

Group proposal

Group is a simple idea, it does not add the metadata in the comment field (op-return) of a transaction, but instead it stores the metadata in the output script of transactions. It also states that miners should do validation of correctness. Hence the term miner-validated.

Recently the group proposal has renamed its telegram channel to "SLP2.0", stating it as an upgrade to SLP as we have it today. But as we shall see, it is absolutely no such thing.

The basic idea of tokens is not really limited to being able to trade them. If that were the case we'd just all use satoshis. Instead the basic idea is that a token has meta-data. A name, a document-URL and other things to show why it has value and what you can do with it. More to the point, a token only has trading value because of its network effect, and for that network effect to be relevant you need to know the basic properties of this token.

A token-id on GROUP is just a long number, purposefully random. Which means that if I receive it, I need to actually take extra steps to know WHAT I just received. On SLP this is extended and you also get a name and an icon for that purpose. This is why Spice-coin and others are so much fun, it has a name and an icon. Not just a 256-bit number.

Just knowing these basic properties is very useful, but to make a judgment call on the value and relevance of a token you need more. For a value-holding token you likely want to know how many units there are in the world, and if there can be printed more by the owner. There are dozens such pieces of data that are really quite essential, because otherwise you just have the word of the sender. Nobody is going to memorize a 256-bit number.

So, Group solves the idea that an incoming transaction is legitimate in its statement of sending some tokens to you. And that is all it does.

Going back to the fact that the owner of Group is advertising it as "SLP2.0", that means that we would lose a lot of features. Wallets would no longer be able to name their tokens, show a fun icon, or do any other things that actually allows users to determine the value of the token they received.

SLP-Service (SLPDB)

To make SLP work we needed that extra service as I explained above. We end up with a system where the wallet or website talks to the middleware and this middleware talks to the full node.

To switch to the group proposal, the change for wallets and websites would be near zero. We still need the middleware for all the features that are part of SLP today which Group does not supply. As such the change is honestly just moving one feature from the middleware layer to the full node layer. The amount of trust in those middleware services is not going to change.

Downsides of miner-validated

The first possible time when miner validated tokens can become enabled is May 2022. More than a year in the future.

Similarly, any changes like new features and bugfixes need to wait an equally long time after that. Because innovation in the bottom layer just takes longer. People are also going to be much more conservative in what they want to do on the consensus layer. Any middleware layers innovation would out-compete all group-like solutions.

Real problem: lack of token infrastructure.

One of the main reasons token developers embraced the idea of a native token was because there is a serious shortage of good infrastructure for them. The middleware layer from the above graphic is short on manpower and coordination between big parties actually running these services is lacking. A stupid problem, for instance, is the coordination for which icon-images to use in the service.

While talking about this with stakeholders it became clear that the group proposal, with the telegram groupname "SLP2.0" is giving people a very wrong impression that it can solve the middleware problem. While in reality is makes it worse, as this old xkcd illustrates.

Adding a new way to store tokens doesn't solve the layer above. People will likely not just abandon the old, as the comic illustrates, and we instead now have to put more work into this middleware layer to support both.

With or without Group we still need those middleware servers. Users still require to know what token they just received and a random token-id is simply not sufficient to communicate that.

Conclusion

The idea of Group seems fun and cool, it feels good to make the miners do more validation. But a critical look at the full design of the SLP ecosystem shows that it doesn't actually solve the problems people are having today.