[CHIP] Unforgeable Groups V6.0 Decentralized Applications on Bitcoin Cash

About a week ago Jason had pinged me and gave me a heads up that he's working on something, and today he has announced that something, and it resembles Group Tokens quite a bit, which is great! Great because he built it from scratch and independently arrived to something very similar, and to me it's a validation of the Group approach :)

I am also thankful to him, because his ping prompted me to revisit Thomas Zander's idea of using the TXID as the groupID (or categoryID), and looking at that part of "idea space" again, I discovered something better than I could have imagined, a facility that could seamlessly let us transition from contract to contract from commitment to commitment from token to token.

I held off broadly announcing V6.0 because I was waiting to see what Jason's been working on, and I find it cool that it's so similar, because its an independent validation of the Group approach :)

I've been bouncing Group for months now, and we really worked hard to making the consensus layer as simple as possible, and I think that with V6.0 we can implement everything CT2.0 promises while keeping consensus layer simple and using Script for the flexibility it provides.

Without furder ado, copying the announcement from research forum.

MAJOR UPDATE - 6.0

This was prompted by exchanging notes with @bitjson and revisiting @tom 's idea of declaring the genesis, and it enables group tokens to interact so much better with Script!

Changes:

• Whole new approach to group genesis: instead of inferring it from the TX, it will be explicitly declared as an input prefix that can use the same byte because it will be exclusive to input context.
• One more introspection opcode to access the genesis input's generated groupID preimage.
• Change group amount format from VarInt to fixed width uint.

Instead of inferring genesis from orphan outputs and allowing orphans only if the groupID matches the hash, we require the genesis to be declared on the inputs, conceptually similar to a coinbase input. A new introspection opcode is added to access the input's genesis preimage. Advantages:

• enables flexibility in deciding which input will be a genesis input
• enables flexibility in deciding which input's prevout will be committed to for later use in smart contracts
• enables better interaction with contracts requiring or verifying the genesis operation
• removes malleability from group genesis (outputs are signed, and orphans disallowed)
• more consistent with Bitcoin design (coinbase input)
• enables versioning the genesis preimage construction without having to spend scarce group type bits which will be reserved for potential "super-contract" optimizations in the future
• opens the path to a future upgrade where user-defined parts of the genesis TX could be appended to the preimage
• enables a dedicated genesis nonce field which simplifies grinding the group type, making the group type encoding time-space trade-off more convenient
• opens the path to synergies with detached proofs and signatures, where hash of the real unlocking script could be appended to the groupID preimage

Example - "Jason's Challenge" Contract - Link to Bitauth IDE Template

The user pays 10,000 satoshis to get a token. They can transfer that token to use 2-of-3, then back to single sig, then deposit the token and get back their 10,000 satoshis from the parent covenant.

There are 2 contracts:

1. NFT, placed on the prevout which will be spent as group genesis input and generate the NFT. The prevout script will require that 10,000 sats are paid into a fixed P2SH address (depository corporation covenant). Only the 1st spend is from a P2SH, the genesis input spend: the NFT can then be moved to an ordinary P2PKH and still be able to reclaim the 10,000 by burning itself in the same TX as any covenant UTXO.

2. The depository corporation covenant is an anyone-can-spend kind of thing, but it requires any NFT that can satisfy the proof of payment at genesis to be burned to an OP_RETURN. The NFT's genesis script is verified to match the template hardcoded in the P2SH covenant.

Not only does this create a BCH-backed NFT, it also lets NFT holders reclaim the BCH from any covenant UTXO :) I suspect there's a way to make some kind of BCH mixer based on this.

PS, for comparing the 2 proposals, consider how CT2.0 and Group map to each other:

<category_id> -> groupID <has_nonfungible> -> groupType commitment_length, commitment -> subGroup (dropped feature) amount -> groupAmount

and we worked for months on simplifying group, so we have only 1 groupType and any custom behavior should be done by Script

and now this proposal introduces 5 types on the consensus layer...

PPS We can have "standard" tokens, a P2SH covenant can require a particular genesis setup, and indexers could scan that one P2SH address and auto-magically add tokens to their database whenever someone spends from the covenant

Preview: https://ide.bitauth.com/import-gist/e81d32df9fa36c4fa961e8065e5a01a1