Store Stacks tx hash in UTXO set?

[Hero-Gamer]

Just observing the recent STAMPs hype and wondering. And sorry for the dumb non-techy brain question below..

• Is there any learning we can take from the recent STAMPs movement? Specifically the "prunability" of the hash of anchor block header we store in OP_RETURN at the moment. (& sBTC store in OP_DROP?)
• Is there a world which we can store whatever stacks data we wanna stored in Bitcoin's UTXO set like STAMPs? More been thrown around as "unprunable" (using 1 of 3 multisig or something. 2 keys out of 3 are image encoded. )
• So Stacks' hash history become even more censorship resilient vs OP_RETURN & OP_DROP which can be pruned easier relatively speaking vs UTXO set?
• I do have to caveat, someone wrote me, "unspendable utxo’s can technically be pruned". But I'd assume it's just very very hard to prune on mass? But others wrote some opposing thoughts:
  • This guy says "unspendable utxo’s can technically be pruned": https://twitter.com/bitcoinbugsy/status/1643422942531821569
  • This guy says "STAMPs are objectively more mutable": https://twitter.com/markgoodw_in/status/1643621437612216321
  • This guy who works at mempool.space said "Stamp data outputs are spendable, and therefore can't be pruned." https://twitter.com/mononautical/status/1643624367450988551
• So far the best take I've seen that summarizes approaches' nuances is from the mempool.space guy: https://twitter.com/mononautical/status/1643640930581245952 & this guy's comment: https://twitter.com/jdogresorg/status/1643644597606969344

If the data size we are storing is not a lot, just a hash, and frequency of storing is only every 10 minutes average, understand it will probably cost higher to store data in UTXO set, but how much more higher in absolute term?

Maybe this is only the current most fancy approach and new more unprunable ideas might move quickly from here.. and probably many other tech/blockchain readability/interoperability considerations out there.
Just wanna put this thought out there nevertheless.

For me, it's not about the exact UTXO approach, as it seems it can be more interpreted more or less prunable.
For me the goal is simply to explore around increasing the permanence & data availability (well, at least that HASH. Not talking about the rest.) technically & feasibly from existing, however approach that may be. 🙏

[igorsyl]

Is there any learning we can take from the recent STAMPs movement? Specifically the "prunability" of the hash of anchor block header we store in OP_RETURN at the moment. (& sBTC store in OP_DROP?)

In terms of durability: OP_DROP (Stamps) > OP_RETURN (Stacks) > Witness data (Inscriptions).

Is there a world which we can store whatever stacks data we wanna stored in Bitcoin's UTXO set like STAMPs? More been thrown around as "unprunable" (using 1 of 3 "fake" multisig or something)

Yes, this can be an sBTC feature. cc @andrerserrano

So Stacks' hash history become even more censorship resilient vs OP_RETURN & OP_DROP which can be pruned easier relatively speaking vs UTXO set?

I believe we cannot use OP_DROP to replace OP_RETURN mining bid transactions. OP_DROP data is hashed while OP_RETURN is available unhashed. cc @netrome

I do have to caveat, someone wrote me, "unspendable utxo’s can technically be pruned". But I'd assume it's just very very hard to prune on mass? But others wrote some opposing thoughts:

Yes, Witness data (and I believe OP_RETURN data) is susceptible to prunning. @jcnelson shared this doc on Soft state in this doc.

Would appreciate a check over all of this from @kantai and @jcnelson to ensure I'm not communicating non-sense :)

Thanks @Hero-Gamer for opening this Discussion! I think a table infographic comparing Witness, OP_RETURN and OP_DROP data storage mechanisms would be cool.

[jcnelson]

In terms of durability: OP_DROP (Stamps) > OP_RETURN (Stacks) > Witness data (Inscriptions).

OP_DROP and OP_RETURN are both part of the block data, and are guaranteed to be stored forever.

I believe we cannot use OP_DROP to replace OP_RETURN mining bid transactions. OP_DROP data is hashed while OP_RETURN is available unhashed. cc @netrome

We could, but it would require two transactions per block-commit (one to send the p2sh address for the script, and one to disclose the OP_DROP payload), and it wouldn't gain us anything. OP_DROP can correspond to any length of data, not just the size of a hash.

Yes, Witness data (and I believe OP_RETURN data) is susceptible to prunning. @jcnelson shared this doc on Soft state in this doc.

Neither OP_RETURN nor OP_DROP data is prunable. OP_RETURN data is not indexed by the node's UTXO database (since it can't be spent), but its contents must be replicated forever in order for the block to be validated.