Persistent Data Sticker Contract
Local transaction introspection will make it possible to design a contract owned by another contract. Here we present one such contract that:
1. Hardcodes some data inside its redeem script.
2. Requires no signature.
3. Requires self-replication.
4. Requires that another contract from the same parent TX is spent from.
With only 1., 2., and 3. the contract would be an anyone-can-spend persistent data entity. With 4., another contract becomes the owner by transitive relation.
Redeem script:
<sticker> OP_DROP
// This is my data
<1> OP_OUTPUTBYTECODE <1> OP_UTXOBYTECODE OP_EQUAL
// I couldn't have changed my data from when it was first set
<1> OP_INPUTINDEX OP_EQUAL
<1> OP_OUTPOINTINDEX <1> OP_EQUAL
<2> OP_OUTPOINTINDEX <2> OP_EQUAL
<1> OP_OUTPOINTTXHASH <2> OP_OUTPOINTTXHASH OP_EQUAL
// My owner got spent, therefore I can be spent
OP_AND OP_AND OP_AND OP_AND
Signature script:
NULL
For the sticker to be spendable its owner must be spent in the same TX. The sticker will be replicated as the 1st output, and the 2nd output will become the new owner.
The sticker proves only that it couldn't have changed its data from when it was first set, but it can't prove when the data was set or which owner originally set it. It can't prove that it's not a new instance created in the parent TX. To prove genesis would require tracing the whole chain back to genesis.
License
CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
After I read your article, it shows that you are expert when we talks about bitcoin cash. Thank you for the information. 🤗