The latest "Group" proposal (v4.2) is more than just "tokenization". It got simpler and more powerful at the same time. It now enables generic BCH output groups that can be used to create persistent Script covenant contracts that can prove their genuineness. This is something that current contracts cannot do, even with the new Introspection opcodes. Group would make it possible because the
groupID is a commitment to the whole genesis transaction, but this is not a post about that.
Introspection made it possible to have outputs be dependent, owned by other outputs. The "sticker" contract is a simple example of that. Here I want to show what is possible if we define the owner as any output member of some group.
In other words, with Group it would be possible to write a contract that requires a specific token to be spent. In effect, the token's group becomes the owner of the so dependent output. The redeem script is very simple:
That's it? That's it. What this Script means in human language is this: "Tell me the index of the input where a member of my owner group is being spent. I will then verify that it indeed matches my owner group, and if yes I will allow you to spend from me".
<0x8837...> is the
groupID and here it works like an address. Difference is, the "address" can change owners independent of this output. The public keys of group members are attached to other outputs, and any one of them can be spent alongside this one to take the funds.
The signature is then just this (if owner is being spent as index 0 input):
The input 0 could be some P2PKH group token, where the spender could spend both outputs, and send the token change back to some new address. Even if he changes the address, it would be the same token, and the token could be used to spend from the above contract here.
This makes it possible to have a single payment address, the contract, and then spend any number of UTXOs sent to it by spending a single P2PKH output, and updating it with the new address at the same time.
This makes it possible to reuse a P2SH address without ever having to reuse the key! This is because token is the key, and token's owner can change on each spend.