nostr:note10vg9vg5f3yyq6kgt06n0y36k23gdtt64dmjf66kld7uexu69tcnqsll834 This thread is really confusing because you’re both confidently saying directly contradictory things. But thank you for the information you’re providing.
Discussion
Basically, witness data is only necessary for proving *authorization to spend*. It can be discarded and it is what happens with pre-SegWit clients.
The witness merkle root is committed separately of the main merkle root.
Inscriptions store data in the witness which can be easily pruned, and also is cheaper (which does not matter, except for the fact that economic incentives will push people to use it).
OP_RETURN is committed to by the main block hash. Unlike the witness which can be separately downloaded and if needed ignored from the main block data, the OP_RETURN is part of the main transaction. This means you have to download OP_RETURNs to be able to verify a block and much more important guarantees like:
- no double spends
- conservation of supply
Assumevalid could be extended to not download witnesses on old blocks as they are only needed to prove the authorization to spend.
good chance this is a perfect encapsulation of the entire messy issue
the original point was “op_return was easier” for some cases where you needed just a little bit more data, as you did not need 2 txs.
it was never cheaper or better compared to inscriptions for mass data storage, and was in fact a major step back on that front
now all of this is moot because taproot annex exists which does the best of both worlds and is even more “prunable” as it is guaranteed useless
the fact that the limit was increased beyond a few KB feels even after user feedback feels like there is no regard for sensibility, and nuking op_return to 40 bytes like with knots is also pointless as it can’t fit enough data for some use cases
all this has done is one of the leading implementations being open arms to data storage which will encourage it, while leaving people with 2 shit choices
I also do not understand why some people feel the need to defend use cases they have no involvement in
there is 1 problem with inscriptions which is that it created a ton of dust outputs, but this is more of a problem with the fact ordinals encouraging 1 UTXO per inscribed “sat” as any other way was hard to manipulate by a wallet app
and that consolidating the 2nd tx output was not economical in terms of fees at high feerates, when your intention was to store data, compared to just leaving it be and forgetting about it