How do you respond to people who say of not in op returns then data is stored in more harmful ways that can’t be pruned? (Genuinely interested not trying to be provocative)
That argument assumes restrictive OP_RETURN causes worse storage methods. But BIP-110 addresses both:
Rule 7 specifically targets the "more harmful ways" - it patches CVE-2023-50428, which stops data embedding in Tapscript witness space (the "fake public key" workaround) with 99.8% precision and zero false positives .
So BIP-110 isn't just "83 bytes or nothing" - it's comprehensive: OP_RETURN limits plus restrictions on the UTXO-bloating alternatives.
The "they'll just store it worse" argument is a false choice. It's like saying "we must allow burning down the house so people don't burn down the garage." Core v30's unlimited OP_RETURN doesn't stop people from using witness data anyway - ordinals still use it because it's cheaper for certain data types.
If the concern is UTXO bloat, the solution is restricting both, not enabling one to prevent the other. That's what BIP-110 actually does - Lopp just omits Rule 7 when making this argument.
Rule 7 specifically targets the "more harmful ways" - it patches CVE-2023-50428, which stops data embedding in Tapscript witness space (the "fake public key" workaround) with 99.8% precision and zero false positives .
So BIP-110 isn't just "83 bytes or nothing" - it's comprehensive: OP_RETURN limits plus restrictions on the UTXO-bloating alternatives.
The "they'll just store it worse" argument is a false choice. It's like saying "we must allow burning down the house so people don't burn down the garage." Core v30's unlimited OP_RETURN doesn't stop people from using witness data anyway - ordinals still use it because it's cheaper for certain data types.
If the concern is UTXO bloat, the solution is restricting both, not enabling one to prevent the other. That's what BIP-110 actually does - Lopp just omits Rule 7 when making this argument.
1❤️1