I've been trying to understand if a Script covenant could be created using Script and new Introspection opcodes. There I realized it's impossible because the locking script can't access the full parent TX, it can access just the outputs. Proving something about the inputs which created an output would require the whole TX as proof. That's why PMv3 was proposed, to bridge the gap by compressing the proof down to fixed size, and I think it finally "clicked" with me (see below) so I can now better reason about different approaches.

Group Tokenization works another way. It hardcodes token behavior into consensus, so from the point of view of Script there's no need to prove that a group token is genuine or that it behaved according to some rules, same like it doesn't need to prove that BCH it operates on is genuine and that it behaved. Its existence is proof enough. What I only recently realized is that it's possible to craft a sticky Script, one that sticks to the token and which can prove it was stuck to the token at genesis and prove that it couldn't have possibly been unstuck and re-stuck to it. By proving this, it also proves that it was respecting all the token rules since genesis.

It is possible because latest group consensus specification locks the authority (aka baton) output down to exactly 1 UTXO. This makes a token backed by BCH possible. While the baton would be locked in the covenant (P2SH), note that tokens themselves would be free P2PKH citizens and use "normal" BCH addresses! Maybe an easy SmartBCH bridge could be created this way, too! Adding some more of genesis TX contents to the tokenID preimage could allow a token authority to prove it was created by another token’s authority.

Script Covenant Template using Introspection and Group Token's Authority

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

It also assumes that introspection opcodes for reading Group annotation will be added:
- OP_TOKENID,
- OP_TOKENQTY, and
- OP_TOKENXTRA,
all with variations for accessing different TX local outputs.

Recall that at any token's genesis an unique tokenID is generated by hashing a preimage consisting of:

• The vout index of the genesis output being generated;
• First input's prevout TXID;
• First input's prevout output index;
• Genesis output's group token annotation, with tokenID omitted;
• Genesis output's pubKeyScript.

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 authorities, it takes very little to prove that a pubKeyScript set at genesis couldn't have possibly been changed since genesis.

Redeem script:
OP_DUP OP_DUP
OP_OUTPUTBYTECODE OP_INPUTINDEX OP_UTXOBYTECODE OP_EQUAL // I must be carried forward...
OP_SWAP
OP_OUTPUTTOKENQTY OP_NOT OP_AND // ... to a token authority output... OP_SWAP OP_OUTPUTTOKENID OP_TOKENID OP_EQUAL OP_AND// ...with the same tokenID as me.
OP_SWAP
OP_INPUTINDEX OP_UTXOBYTECODE OP_CAT OP_HASH256 // Also, my pubKeyScript...
OP_TOKENID OP_EQUAL OP_AND // ...must be the same as set on my token's genesis.
OP_SWAP... // any other conditions.

Signature script:
<...><genOutputIndex/genTXID/genVout/genGroup><outputIndex>

This contract "header" proves the stickiness of the contract, and is of fixed size (24 opcodes signature). Any other smart contract feature (like a contract to control the BCH/token ratio, or just the BCH balance of the authority output for a smart BCH vault) can be added on top of it.

PMv3 Approach

Here's the key to understanding it:

"Detached proofs allow the unlocking bytecode of a particular input to be provided as a hash in the transaction hash preimage (TXID/Outpoint Transaction Hash calculation)."

It compresses signature scripts of the TXID preimage because the signature scripts stop being a part of it, just their hash will be there. It will allow the next TX to reconstruct the whole parent TX and verify against the prevout's TXID. Because grandparent TXID is part of the preimage, successful reconstruction will prove which TXID was the grandparent. For reconstruction to be small it must be designed to be small: all inputs must be small or use detached proofs, and outputs are accessible from local scope. With this approach, there's no choice but to introduce a new TX format, because right now there's no place to hide the signature script where it won't get hashed for the TXID.