pull down to refresh

To my understanding, it is this opcode that allows for ordinals.
Incorrect. OP_RETURN is not usable for ordinals because the outputs are unspendable. So you cant transfer that rare numbered sat because it will error out when you try. What this allows is inscription of data other than transactional data, without needing the script interpreter (it basically errors out on the first byte of the script, which is OP_RETURN itself)
The important thing is that you can, after hashing, completely discard the UTXO because its not spendable. And thus it doesn't pollute Bitcoin Core's (and forks like knots and libre) utxo db. From memory I do think that libbitcoin indexes them but even if, would be easy to prune them if you don't need them.
The current limit was imposed because it was deemed enough for counterparty back in the day. The reason to expand it (or drop the limit) is because Citrea threatens to circumvent it and fill up the utxo db with fake keys.
So I'd wrongly assumed... Thanks for correcting me on that score. I guess I'm still just trying to make out what this script is used for. At any rate, this is a great learning opportunity, as I find the controversy makes it hard to look away.
reply
99 sats \ 2 replies \ @optimism 17h
It's literally used to tag transactions with data. It's still bloat. But it's pruneable.
The biggest risk besides the bloat is the same as with ordinal inscriptions though, what @theariard underlined: "value" that is not native to the L1. However, its debatable if that is prevented with 80 bytes - counterparty still operates on 80b today and your rare pepe transaction with exactly that externally perceived value "fits" in there.
People will abuse it. It will hurt. Will that hurt more than abuse of data structures in practice? Probably not, because ordinals already does this anyway.
reply
Jason Hughes is saying on X that merging this turns bitcoin into a shitcoin 👀