Introducing Group Tokens for Bitcoin Cash

What is "Group Tokenization for Bitcoin Cash"?

It's a Bitcoin Cash improvement proposal (CHIP) to enable simple native tokens, aspiring to be activated in May 2023.

What do you mean "native"?

This means tokens imlemented as a hardcoded feature provided by the Bitcoin Cash blockchain, like the native currency BCH. Token checks and balances are enforced the same way as for BCH, and with tokens a few new "buttons" are provided to manage token supply and metadata.

Why would we want native tokens?

Because it fits well into Bitcoin Cash UTXO model, so such tokens could use all blockchain features available to BCH: 0-conf, SPV, Script, and SIGHASH.

What this means is:

• Easy for usage, because no new address format required and a single address can receive multiple tokens.

• Easy to upgrade wallets and middleware because token transactions are built the same as BCH transactions.

• Easy to parse the blockchain and build databases to track token stats.

• Fully compatible with 0-conf and SPV wallets.

• Scaling function, the "big O", unchanged.

• Cheap on node resources, almost as cheap as BCH. Think of them as heavier BCH outputs.

• Fast as BCH, secure as BCH, and almost as cheap to transact with.

• Atomic swaps and token CashFusion possible through existing BCH transaction signing mechanism.

• Can be locked with any Bitcoin Cash Script and because of that

• they could benefit from other upgrades (Introspection and PMv3).

How do these tokens work?

Let's first go over how Bitcoin Cash transactions work. Imagine BCH as gold sand packaged in transparent bags, each grain being one satoshi. The bag ties are locked with combination locks, most common type of lock called an address. The bags themselves are called transaction outputs. When we make a transaction, we're instructing the blockchain to repackage the gold sand into new bags with new locks. Some sand is taken as fee for this repackaging service, and the blockchain will refuse to pack too small amounts of sand - a requirement known as the dust limit.

Imagine tokens as synthetic sand, with color unique for each distinct token. We require it to always come packed in a separate bag, tied together with a bag of BCH, and locked with the same lock.

How is this synthetic sand first created, though? The blockchain produces it on demand if some requirements are met. As with any other transaction, you present unlocked bags and state your demands. To create a token, you must present just enough BCH to pay the fee and fill the small bag of BCH to accompany the token bag, that's it. The first bag of a new color will be a special grain of an unique, randomly assigned color.

To create token sand, you must present it to the blockchain.

With this, we illustrated the main token operations: genesis, minting, and transfer of tokens.

Recall that tokens are dual-currency outputs, always carrying at least a minimum BCH amount and some token amount. Should a token become worthless, users can burn all their token bags and reclaim the pure BCH.

If the special grain is thrown away (burned), then the token supply will be locked forever.

OK but I don't care about tokens, I only care about BCH

That's fine, but maybe others will care and have an use, and enabling tokens wouldn't hurt BCH holders. We can't force people to want to exclusively use BCH. If they have a need for other currencies, even if we don't offer tokens, they'll use them on other blockchains.

I believe we're moving into an era of tokenization of everything. It started with Ethereum and it's only been ramping up. Supporting tokens on Bitcoin Cash blockchain means BCH gets to capture a little value from every token resident, as it would create a little additional demand for BCH. Will it add up to anything significant, who knows? Why not spread our bets?

Fine, but we already have SLP

SLP has an architectural flaw where middleware failure can cause total loss of funds to a 100% compliant wallet. No wonder it never really took off when there are user-friendly solutions on other blockchains without this flaw.

I elaborated on this here: https://read.cash/@bitcoincashautist/some-comments-on-bch-network-discussion-on-group-tokenization-afae5ea3

SLP did good in one way though, it showed there's interest in having tokens on Bitcoin Cash!

Fine, but we now have SmartBCH

Great! With this we get a fully featured smart contract machine powered by BCH that could compete in the DeFi market. It's still another blockhain, and will require separate infrasctructure.

Whichever solution becomes popular it will bring adoption to BCH. Success of one doesn't exclude the other, and BCH would benefit from both finding their uses.

And besides, they're not targeting the same market. Native tokens should be really convenient for transparent CeFi, powered by a decentralized, PoW secured blockchain - powered by Bitcoin!

What about PMv3, it can give us CashTokens, can it not?

PMv3 gives us something better - native covenant support, and if a covenant can lock BCH, it can lock native tokens too! This proposal is not really a competing proposal, it's supplementing because native tokens can be used inside PMv3 covenants. I want both, here's why.

Sure, with covenant support you could code a Script contract called CashTokens, and it's an interesting demonstration of what covenant can do. Being that, they'd be awkward because keeping track of such token balances is done somewhere inside a complex lock placed on a pure BCH bag, known as the locking Script. Such tokens don't come with the same benefits as native tokens, and they have limitations due to their architecture.

What about scaling?

It scales, just a little fixed amount of data and work per BCH UTXO carrying a token.

Imagine you had a pure BCH transaction with 10 BCH bags in, and 5 BCH bags out. The blockchain needs to visit and weigh 15 bags, check 10 locks, and create 5 new locks.

With tokens, it'd need to visit 15 pairs of bags, but still check the same 10 locks, and create 5 new ones. There's no double job, the node weighs BCH amount in each bag once, and token amount once. The weighing operation is very cheap because it's just basic arithmetics when coded.

What about UTXO consolidation?

Every token UTXO carries some BCH. If a token becomes a zombie, it can be burned and BCH reclaimed.

What about UTXO growth?

What about it? It grows proportionally to number of locks placed on bags, nothing changes there. More users, more locks. And remember, there always must be a small BCH bag attached to each lock so... if it grows, it'd be a good problem to have?