It might be nice to have a thread dedicated to discussing proposals for implementing a built-in token protocol on Bitcoin Cash. I think @andrewstone’s Group Tokenization (prev. OP_GROUP) is the main public proposal currently, but if anyone knows of competing proposals, this may be a good place to discuss.
There’s some related discussion here (comparing Group Tokens to the more “userland” CashTokens idea):
However, it seems very possible a future BCH might support both 1) “parent transaction introspection” in the VM system (which can be used for CashTokens, but is also important for e.g. parallelizing covenant applications) and 2) a universal, reliable, built-in token system. Assuming it’s possible to do both, maybe this is a good place to collect discussion on (2).
A good starting argument I’ve seen in favor of a “built-in” protocol is @andrewstone’s comment here:
Disadvantages of implementing tokens in the blockchain script:
- Safety: every token can be implemented differently so really before holding a token every person should review that code (which may be closed source).
- Scalability (CPU): no matter how much more efficient the blockchain scripting language gets, its unlikely to exceed the efficiency of native code. Additionally, the native code can leverage miner consensus and therefore “do” a lot less – in this case just a simple sum and compare of token inputs and outputs.
- Scalability (Space): the scripts that implement and enforce token constraints will take up space in transactions.
So let’s talk product philosophy, because excepting BTC with its 1st mover advantages, blockchains are effectively products competing for users. Here’s a key product design idea:
If you can’t be better in all respects than an established competitor, then at least be different.
Why? Because your differences will mean that you are better at some things (while being worse at others). Ideally of course, you want to be better at MORE things then you are worse at. But even if you are worse at more things, your different product can find applications that specifically need what you are better at.
This is the philosophy I think we should use with Bitcoin Cash. Verses Bitcoin, we’ve made it worse on low end machines/internet connections to make it better at handling large volumes of transactions. Verses Ethereum, we shouldn’t make it a (worse) general purpose computer (and no, we are never going to slowly build BCH script into something that can out perform the ETH VM which is IIRC going to leverage web assembly). Instead, lets make it really good at handling crypto-financial computing. The way to do this is to have powerful primitives for that task. This is why I want super-efficient native tokens, rather than implementing them at the scripting layer.
Some initial comments and questions:
I definitely see the safety-value of reliable standards – we don’t want users to have to re-validate the implementation of every standardizable token.
I think a “userland” protocol design like SLP covers this, though. And I’m much more confident that bad design decisions in a userland protocol can be rectified – e.g. Ethereum now has ERC20, ERC721, ERC777, ERC1155, and more. If we needed to improve our standard (as Ethereum has demonstrated is likely), we’d need to do so on the consensus level every time, rather than allowing that experimentation to happen in less-dangerous userland.
Also, I expect the most important kinds of tokens are extremely hard to generalize: synthetic assets, “VoteCoins” in Hivemind-like prediction markets, permissions and shares in liquidity pools for BCH DEXs, etc.
These types of tokens need to interact with complex covenants, and I’m not confident that the current Group Tokenization spec applies to these cases. Group Tokenization Script Templates and Contract Encumbered Groups seem aimed here, but those solutions seem like a much more complex way to accomplish similar goals as CashToken’s parent transaction validation. (@andrewstone would you disagree?)
I’d almost prefer the Group Tokenization proposal focus more directly on the more easily standardizable token types: fixed-supply tokens, custodial stablecoins, loyalty tokens, etc. I think there’s a case to be made that inductive proofs are overkill for these applications, and a simple, miner-validated token scheme could save bandwidth (the CPU and Space Scalability points above).