Join 74,253 users and earn money for participation

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

13 379 exc boost
Avatar for TomZ
Written by   338
5 months ago

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.

20
$ 112.70
$ 64.00 from @Ellie
$ 34.20 from Anonymous user(s)
A
$ 10.12 from @TheRandomRewarder
+ 9
Avatar for TomZ
Written by   338
5 months ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

History: the SLP metadata format originated with the group token proposal.

Today: Group on BCH will match SLP's metadata format.

The metadata format is not consensus-related so does not appear in the consensus change specification, except for one detail which does appear: the contents of the OP_RETURN (i.e. the metadata/ hash of the metadata) is hashed (plus other things) to form the groupId. This allows the metadata to be provided trustlessly to clients who can then prove that this must be the data associated with a particular group.

$ 5.00
5 months ago

I'm happy you commented and pointed this out, but not sure why you felt the need to point this out. This is well known and assumed.

Just like in SLP the way to find out the name of a token you just received is to ask a middleware to provide it for you. This doesn't change, and you still need that middleware. Which is the core of the argument.

$ 0.00
5 months ago

Tom, I think you made this incorrect statement:

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.

Can you please explain what you’re talking about here? As you said, middleware would provide this information, so there’s no features being lost.

$ 5.00
5 months ago

SLP is an entire stack, it includes the middleware.

Group, labeled SLP2.0, does not replace that stack. Does not make that entire stack miner-validated. Does not remove the need for the middleware.

It is like saying a new type of engine can be advertised as a new car. It mixes up scope and is false advertising meant to oversell the solution for something it can not do.

$ 0.00
5 months ago

Thanks for evaluating OP_GROUP, I think positive and polite criticism is healthy for protocol design.

I have spent a lot of time writing applications that use SLP, and knowing whether a token is valid is the hard/frustrating part--not retrieving the metadata. The apps I've built do not query for a token name (ANYONE can mint a token that has the name "Verde Points" or "Dublin Token")--they MUST have the 256 bit identifier hard coded. So the problem remains the same.

That being said, what I'm taking away from this article is that the metadata component of SLP is (perhaps accidentally) being left by the wayside. I don't see an argument against OP_GROUP personally, I see a perspective and component that hasn't been addressed yet.

$ 5.01
5 months ago

knowing whether a token is valid is the hard/frustrating part

Why don't you just ask an SLP validating node? (marked as middleware in the article)

$ 0.00
5 months ago

Thanks for this, Tom, and for the time you have spent vetting these proposals.

Any middleware layers innovation would out-compete all group-like solutions.

Aren't those innovations compounded rather than competing? Since, as you say, the middleware layers are needed either way. I am glad you wrote this analysis and it does seem true that Group will complicate token innovations that would happen anyway without it. A pillar of your argument, however, is that Group itself is a very simple change, with most of the complexity in the middleware, so I am not sure how big a deal accounting for it in future upgrade plans will be. It seems right for you to say that changes to Group will take much longer to achieve, but wouldn't innovation on the db layer be able to proceed in the meantime? Is there a reason to wait on Group?

$ 0.00
5 months ago

A pillar of your argument, however, is that Group itself is a very simple change

What I tried to explain is that the group itself is making changes in parts that already work just fine. I didn't mean to say its simple, just that its a solved problem its trying to solve again in a different way.

And in the last part I investigate where the real pain points are, which are wallets and missing features in the middleware.

It seems right for you to say that changes to Group will take much longer to achieve, but wouldn't innovation on the db layer be able to proceed in the meantime?

new features would stop being able to be added the moment people decide to use Group.

Is there a reason to wait on Group?

I encourage everyone to just ignore group and continue to improve SLP and wallet supports. Something we need either way.

But, as soon as someone makes their token Group based they will no longer be able to make use of new innovations in SLP. So there is a risk that group is out-dated the moment it will be made available.

$ 0.00
5 months ago

Tom, in my mind the whole issue boils down to trust and ease of use for the end-users. A highly competitive token system would require a user experience that is fast and does not force users to self validate tokens.

We can’t delegate validation to middleware because the middleware can return a false positive validation result, and this results in destroying all of the user’s tokens.

$ 5.00
5 months ago

The only part of the token ecosystem you can move to a full node is the transfer of token-amounts. Group moves nothing else there.

So while you worry about getting false info for a transfer, you miss that with group you still can get false info about the token itself being moved. Your wallet can not show you anything other than a purposefully random 32 byte ID. Is that really the "spice token" you wanted to use?

Point here is that in security the weakest link makes the entire system crash, enforcing one part of it while ignoring others doesn't solve the issue. You are chasing an illusoin of security and making stuff overly complex as a result.

$ 0.00
5 months ago

Wow i was amaze with this. Oh i wish for it. Tyank you bitcoincash fly high

$ 0.00
5 months ago

Re. “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.”

I did not create nor change the name of that Telegram group to SLP2.0 so that’s not being fair. It was Paul Wasensteiner who made the initiative to rename it to SLP2.0 and nobody in that group (including you) seemed to mind at the time.

I then asked James Cramer about it to clarify and got the impression there was agreement forming around it so I just went along with it in casual talk.

The Group CHIP nowhere refers to it as SLP2.0, and it won’t ever because while GROUP enables a functionality, SLP can choose to use it or not use it, and some other token ecosystem could freely form around Group, but it is my impression that SLP folks want to use GROUP. Instead of speculation, it would be good to ask them?

Also, middleware development is permissionless, and once building blocks are available on the base layer, anyone will be free to use them as they see fit and build whatever they want with them. Group is an enabler, not a full-stack solution.

$ 0.00
5 months ago

I did not []

no, as you so clearly state, you are not the one this referred to.

$ 0.00
5 months ago