The idea here is similar to the generic data import proposal from Jude/Pavi, where a specially crafted OP_RETURN would result in miner's putting data into a clarity smart contract. (GitHub issue)
Miners would be the only ones who can write to it, and it would be available to Stacks contracts similar to how the boot contracts are now. The design would be simple: a preamble to identify the tx and a blob of data.
This sounds very similar to how Ordinal Theory defines their Bitcoin scripts with OP_PUSH, e.g.
Instead of using OP_RETURN, Hank recommended OP_DROP in the Stacks forum and a few conversations, which allows the data to be appended to a valid transaction.
One example was including a SIP-018 signed message, which the user could implicitly sign by sending dust to it.
What if we used an approach that combined the use of OP_DROP for our purposes and the standard inscription script?
This could be done manually at first and interpreted by a client, and if fed directly into a Clarity contract by miners, would create a valid index on both networks where data would be accessible directly to Clarity contracts without having to query Bitcoin transactions or state.
The idea here is similar to the generic data import proposal from Jude/Pavi, where a specially crafted OP_RETURN would result in miner's putting data into a clarity smart contract. (GitHub issue)
Miners would be the only ones who can write to it, and it would be available to Stacks contracts similar to how the boot contracts are now. The design would be simple: a preamble to identify the tx and a blob of data.
This sounds very similar to how Ordinal Theory defines their Bitcoin scripts with OP_PUSH, e.g.
Instead of using OP_RETURN, Hank recommended OP_DROP in the Stacks forum and a few conversations, which allows the data to be appended to a valid transaction.
One example was including a SIP-018 signed message, which the user could implicitly sign by sending dust to it.
Another example from the Magic protocol:
What if we used an approach that combined the use of OP_DROP for our purposes and the standard inscription script?
This could be done manually at first and interpreted by a client, and if fed directly into a Clarity contract by miners, would create a valid index on both networks where data would be accessible directly to Clarity contracts without having to query Bitcoin transactions or state.