CHIP 2021-02 Group Tokenization for Bitcoin Cash

Have you considered allowing miners to claim excess tokens? The rule could be that the coinbase outputs can include token outputs. Given that burning tokens normally isn’t allowed, I guess the point is moot.

It would move the tokens to nearer equal status to BCH, and that may be undesirable.

Hi thanks for reading! Note that line will only hold until we introduce the MELT authority later in the document. Before that we’re describing only a minimal token system. In technical description, we’re introducing the whole system bottom-up, building it up from the minimal system which is just the TRANSFER+GENESIS where you can do minting exactly 1 time, and there you can only transfer and freely melt. Then we introduce MINT to let you mint later and transfer ownership of minting capability, and then we introduce MELT and set the balancing rule to == so no more accidental melts. With MELT authority there is clear intent and authority to melt, which makes auditing the “official” supply easy while also preventing accidental burns by users. Finally, the BATON makes the distinction between one-time use authorities, and those that are allowed to be transferred.

This is not-applicable to the scope of the proposal, and as you said it may be undesirable. In an old draft, I did ponder a hypothetical solution where tokens would be really equal, and it would have problems.

While tokens can be plugged into all interfaces where BCH can, they’re not really equal and shouldn’t be – because we need the incentives around BCH not only for the blockchain to work, but for the whole ecosystem to align their incentives and share the same goal, and also for security because the price will not just have an impact for lives of everyone holding BCH, it will also have an impact on increasing our % of the SHA256 hash-power.

Adding token based transaction fees would be of moderate complexity. It is conceptually pretty simple and doesn’t have to many side effects.

Miners could be paid from multiple sources. It could make tx fees/tipping miners less hassle for users. OTOH, it removes the need to obtain BCH to pay tx fees.

Minting tokens to pay miners would be a free rider problem though. All tokens benefit from the security of paying miners with minted tokens but only some tokens pay towards it.

Having a primary currency that all the tokens reference seems reasonable.

Your point that having BCH in every output ensures the incentive to consolidate outputs is a good point. This can be maintained even if tokens can be paid as tx fees.

I agree that keeping things simple is better though.

1 Like

True, it could be as simple as introducing another authority, e.g. a FEE authority which would work exactly like MELT but the excess wouldn’t be destroyed and instead would be claimed by miners. Just to be clear, I have no intention of including such a feature in the current proposal, because assessing the impact could detract the proposal from moving forward.

Glad we agree here!

After a days long discussion with Emil Oldenburg, I accepted his proposal to simplify the authority system to just one UTXO per tokenID, now called the baton output, have fixed minting capacity, and add lockable metadata fields to the baton. I believe that this will give the CHIP wider acceptance, make it more friendly for full stack product builders, address previous concerns about complexity, and make it more defensible and likely to be activated.

More details here: New Group Tokenization Scheme - One Token Standard (WIP)

and it’s already been implemented into the CHIP, which is still WIP and now the Specification needs to be rewritten too.

I would like the ability to provably back tokens with BCH similar to how ETH contracts can have coins deposited into them. There are 4 prerequisites to having this functionality thought and I have made a new issue in on gitlab for each one. Issues 30, 31, 32, and 33.

To summarise here the following 4 features are needed

  1. infinite mint capability
  2. Separate MELT and MINT permissions
  3. Allow for fenced BCH groups
  4. Subgroups

The least trivial of those changes is subgroups. Subgroups are required because a fenced BCH group can not also have a token, the token needs to be a subgroup of the fence to have the token be backed by BCH (or the token can be the main group and the fenced bch group can be the subgroup).

I’ll add back 1. & 2. to the proposal, IMO there isn’t a strong argument NOT to have them, as you say they’re trivial to implement, and having them has its merits.

Best I got against 1. was sum overflow, but isn’t this, like, trivial to guard against? As for 2., it’s rather awkward NOT to have it which I realized while trying to write a spec where 0-flag baton could still melt even when MINT was given up.

3. and 4. require some additional logic circuits on the consensus layer, but the bulk of the cost would be on other layers: block explorers, wallets, etc. would have to deal with more kinds of tokens, check for token balance in 2 places instead of 1 (BCH amount for colored / tokenAmount for others), and so on.

Compared with some pure Script solution the advantage of 3. and 4. would be that we could lock only their authority UTXO in a Script covenant and have it be publicly accessible to apply BCH coloring or token coloring (subgroups) if the right stuff was presented to the TX, so only such operations would have to be P2SH. The tokens themselves would remain P2PKH so could move more easily on the blockchain and be more widely supported by wallets etc.

If anyone wants to weigh in, here are the threads for each feature:
1. infinite MINT, 2. MELT flag, 3. fence/coloredBCH, 4. subgroups/coloredTokens

The other applications need to add support for a new token scheme regardless of which is used.
There is only one kind of token in op_group. the only difference between a group and a subgroup is the group ID of a subgroup will indicate a parent group and applications will have to parse the groupids anyway. At most subgroups are asking the wallets to make an indication of a relationship between two groups and not much else.
Fenced BCH values are in the same location as regular BCH transaction values.

Assuming parsing group tokens is already implemented, the additional burden of checking for fenced bch and subgroups consists of a couple more if statements.

1 Like

@Griffith I worked out an example of how you could create backed tokens even without the “fence” feature. It is possible as a consequence of locking the authority (aka baton) to exactly 1 UTXO in the “base” proposal. Maybe an easy SmartBCH bridge could be created this way, too! Including hash of the first prevout output in the tokenID preimage could allow a token authority to prove it was created by another token’s authority.

Token Group Script Covenant

The below example requires CHIP-2021-02: Native Introspection Opcodes.

It also assumes that introspection opcodes for reading Group annotation will be added:

    all with variations for accessing different TX local outputs.

Recall that tokenID is generated by hashing a preimage consisting of parts of that token’s genesis transaction:

  1. Hash of first input’s prevout output;
  2. First input’s prevout TXID;
  3. First input’s prevout output index;
  4. Output index of the genesis output being generated.
  5. The genesis output being generated with tokenID left out;

Recall that consensus also enforces that:

  • The genesis output must be of token authority type;
  • When an authority output is spent, it can create any number of ordinary token outputs but only one authority output.

Because of consensus rules placed on token genesis and token authorities, it takes little to prove that a pubKeyScript placed on a token authority is the same as the one set at genesis and that it couldn’t have been tampered with.
The pubKeyScript only has to prove that it’s been tied to the token authority output since genesis, and such proof will be of fixed size.

Redeem script:
OP_OUTPUTTOKENQTY OP_NOT OP_AND // … to a token authority output…
OP_OUTPUTTOKENID OP_TOKENID OP_EQUAL OP_AND// … with the same tokenID as me.
OP_TOKENID OP_EQUAL OP_AND // … must be the same as set on my token’s genesis.
OP_SWAP<...>OP_AND // Any other conditions.


The genDataHeader part of the signature is the tokenID preimage with genesis pubKeyScript left out, and the outputIndex refers to the “change” output of the token authority being spent.

The size of the above covenant boilerplate code is given below:

6   Signature push opcodes (3+1+1+1)
1   OP_0
25  Redeem script boilerplate code
63  Covenant proof part of signature, assuming NULL metadata.

Because token authorities can be created with or without capability to mint tokens, such covenanted output could be used as:

  • As NFT with a BCH balance entirely controlled by the covenant;
  • As a token authority with variable BCH balance.

When used as a NFT the covenant could serve as BCH vault, requiring arbitrary proofs to add or remove BCH.

When used with token minting and melting capability, the covenant could require BCH to be paid in/out of the covenant which would make tokens backed by BCH possible where such tokens would remain free P2PKH citizens.

Covenanted Ordinary Token Outputs

If the covenant is placed at token’s genesis then it is possible to envelop ordinary token outputs in the covenant by extending the code above to require indexes of a number of ordinary token outputs.

The covenant could then verify that it’s being passed on to them and tally up the balances in order to verify that outputs haven’t been omitted.

This would allow fanning out of covenanted outputs.

The above would work only with finite mint tokens.

For infinite mint the covenant would have to enforce that the total number of outputs in a transaction matches the number of provided indexes.

Supporting covenanted outputs merging would be achieved the same way, by requiring indexes of a number of inputs to be included in the balance calculation.

For example, this could be used to implement “colored” BCH where the covenant could enforce tokenQty == satoshiAmount.

It could also allow any owner to burn the color and reclaim the BCH by coding the covenant so that it allows being spent to a token OP_RETURN under some conditions.

MAJOR UPDATE - 4.0 Unforgeable Groups for Bitcoin Cash

This was prompted by some discussions I had with @im_uname and after realizing that the groupID can be used as a “witness” to construct unforgeable Script covenants. These would then let us implement all advanced supply and metadata management features from within Script, while letting token amounts be free P2PKH citizens, giving us the best of both worlds, consensus and Script.

Also, pure witness mode is supported, which would enable fixed-size inductive proof covenant contracts that would work the same as PMv3 “detached witness” examples but reconstructing the groupID witness instead of TXID as proof.

4.0 Unforgeable Groups

  • Simplified the output format and consensus layer
  • Generalized output groups as “carried witness”, having only the GENESIS rule enforced
  • Amount field is now optional and indicated using the LSB of groupID so the whole group must have or not have it
  • Native token groups and Satoshi token groups (aka “holds BCH”) are then a more restricted variant of a generalized group, having token logic enforced over respective amount fields, and NFT logic enforced over amountless token groups.
  • 0-amount indicates “singulary” i.e. an infinite source or an infinite sink which allows token amount creation and destruction
  • Any advanced features, such as metadata updating, are to be implemented using unforgeable Script covenants, as demonstrated in the examples section
  • Reworked CHIP sections