The content of redeemScripts are another script, which is then executed. Its contents are then also subject to the same OP_PUSHDATA* restrictions. Restricting it is not only unnecessary, but would reduce the ability to make use of the intended script capabilities, and could impact legitimate real-world usage.
By excluding BIP-16, you've missed that one doesn't need taproot for inscriptions, because the redeemscript can be inscribed. This was originally thought up by counterparty in 2015 or so, but they decided against adoption. It has been used on shitcoins though, a lot: I was told back in late 2024 that Dogecoin had seen about 100GB of jpegs and BRC-20 transactions inscribed into redeemscripts at the time. They use pushdata concatenation after the content-type, and a protocol extension to chain multiple inputs on a 520 byte redeemscript limit. This means that your proposal currently exempts a known source of abuse that will simply be shifted to by any spammer.
I've verified this back in the day, but to be absolutely sure that I am not mistaken, I did it again: Here's the first tx I could find on there earlier today with an inscribed redeemscript, and here's the scriptSig asm:
See the problem? You cannot exclude p2sh and p2wsh and claim there will be no inscriptions, and even if you would ban OP_IF in these scripts too, a spammer could put counterparty-style multisig inside a p2sh leaving a large chunk of inscribable bytes per input that cannot be stopped without nuking non-schnorr multisig.
Therefore, my first point was that your proposal is incomplete and I think that it stays true as long as you don't (partially) nuke BIP-16. And if you do nuke it, then many cannot support the proposal because LN uses p2wsh multisig.
Worse, the overhead on chained p2sh inscription spam is said to be very high, so the option provided by Core v30 to just allow large(r) OP_RETURN becomes much less harmful in lieu of addressing redeemscript inscription. I hope that this also illustrates that this isn't something we can easily make watertight, and although I'm personally not a fan of the decision to do default unrestricted datacarrier policy, I do think that it signals that everything has tradeoffs.
However, there is not enough urgency, in my view, to skip the important process of building consensus among the community. Bitcoiners need to agree that this change is the correct one.
Great! I agree. Here's what I think:
Build consensus without forced signaling and with at least a supermajority target (but I'd still urge for 95% to not change too much at once). This way you can make your statement by measuring the true support for anti-abuse measures in an anti-fragile way. Even if it fails to activate with a high percentage, the signal is still clear that a permanent solution is desired, and your mission succeeded?
You will need to either make the solution permanent (very hard, everyone is aware), or reduce the duration significantly to reduce risk and harm. Reduce it to a couple epochs of 2016 blocks?
This way, your proposal can generate maximum signal, minimum risk and introduce limited fragility. It may become a conversation instead of a highly toxic pissing contest then. I'd still not run your activation client because I still don't like the tradeoffs, but I'd look into at least porting it out of the Knots codebase into something a bit more clean, even if just for myself.
Effective?Effective?
By excluding BIP-16, you've missed that one doesn't need taproot for inscriptions, because the redeemscript can be inscribed. This was originally thought up by counterparty in 2015 or so, but they decided against adoption. It has been used on shitcoins though, a lot: I was told back in late 2024 that Dogecoin had seen about 100GB of jpegs and BRC-20 transactions inscribed into redeemscripts at the time. They use pushdata concatenation after the content-type, and a protocol extension to chain multiple inputs on a 520 byte redeemscript limit. This means that your proposal currently exempts a known source of abuse that will simply be shifted to by any spammer.
I've verified this back in the day, but to be absolutely sure that I am not mistaken, I did it again: Here's the first tx I could find on there earlier today with an inscribed redeemscript, and here's the
scriptSigasm:6f7264 OP_1 746578742f706c61696e OP_0 363033343436342e646f67656d6170 6d6d750a756f6b6b367a6d6e6d337555See the problem? You cannot exclude
p2shandp2wshand claim there will be no inscriptions, and even if you would banOP_IFin these scripts too, a spammer could put counterparty-style multisig inside ap2shleaving a large chunk of inscribable bytes per input that cannot be stopped without nuking non-schnorr multisig.Therefore, my first point was that your proposal is incomplete and I think that it stays true as long as you don't (partially) nuke BIP-16. And if you do nuke it, then many cannot support the proposal because LN uses
p2wshmultisig.Worse, the overhead on chained p2sh inscription spam is said to be very high, so the option provided by Core v30 to just allow large(r)
OP_RETURNbecomes much less harmful in lieu of addressing redeemscript inscription. I hope that this also illustrates that this isn't something we can easily make watertight, and although I'm personally not a fan of the decision to do default unrestricted datacarrier policy, I do think that it signals that everything has tradeoffs.Get agreement?Get agreement?
Great! I agree. Here's what I think:
This way, your proposal can generate maximum signal, minimum risk and introduce limited fragility. It may become a conversation instead of a highly toxic pissing contest then. I'd still not run your activation client because I still don't like the tradeoffs, but I'd look into at least porting it out of the Knots codebase into something a bit more clean, even if just for myself.
TLDR; Force bad, measurement good.