I was toying with Introspection opcodes and made a contract that must replicate itself and is owned by another output. Resembles something? An NFT?

Yes, the contract behaves like an NFT, however, if you receive it you can't tell which one is it. Anyone can copy the contract and make a brand new one with the same code. How to know which one is real? They'd all be the same NFT contract, but each would have a different genesis TX. So, you must follow the chain back to the genesis TX to find out, and we can then consider the NFT genesis TXID as its ID. Problem is, users would have to go back and look for the genesis TX, or some server would have to keep track of which UTXO is which NFT.

So, how to have contracts that can prove their ancestry?

What if the UTXO could prove its own genesis and save the users the trouble and avoid the need for indexers? It could, by coding the contract so that it can either be spent if the specific TXID is the parent or if the parent was spent by spending the contract and not some other contract. Problem with this is that the proof grows with each transaction because each TX must embed the previous TX as proof, which Jason had already demonstrated. Because of that, with my example contract, we can only make 2 transactions as the proof would already get too big for the 3rd :(

Here's a working example on testnet4:

1. Create the contract
2. First spend (genesis)
3. Second spend (previous TX embedded as proof)
4. Nope, can't do it, because the TX No. 3 is of 713 bytes and it can't fit on the stack to get hashed for the proof.

Code, in human-readable form: bitauth scratchpad link

This is why we need either the "detached proof" feature of PMv3 or the "carried digest" feature of Group which is newly introduced, tokenless, generic feature intended for use with contracts and addressing the same problem. Either one would allow us to have fixed size proofs, so every TX would be of same size, and open a whole new class of contracts!

• PMv3 would achieve it by changing the TXID preimage so that input bytecodes are first hashed individually before getting hashed for the TXID. That would compress them and then we'd only need to put input hashes in the proof instead of the whole parent TX.
• Group would achieve it by having the proof of genesis (groupID) be carried with descendant outputs. The proof would then have to provide only the compressed genesis TX, as demonstrated here.