On Fri, Feb 17, 2023 at 03:56:31PM +0100, vjudeu via bitcoin-dev wrote: > > [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831 > > I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. > Because "OP_FALSE OP_IF <anything> OP_ENDIF" is effectively the same as > "OP_NOP", and putting NOPs in many places is considered non-standard. The > same is true for "OP_TRUE OP_NOTIF <anything> OP_ENDIF", and also there are > many variants, where someone could use "OP_FALSE OP_NOT" instead of > "OP_TRUE", or check if "2+2==4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" > (instead of putting "OP_TRUE"). >
If you ban any of these specific script fragments then spammers will just use `IF <anything> ENDIF` and provide the `FALSE` as a zero push. And banning *this* would ban legitimate use cases. You could try statically analyze `<anything>` to determine whether the IF branch could ever be taken. For example there is no path through the "inscription script" that would result in all the crap being dropped by the end of the script, violating the CLEANSTACK rule. This sort of filtering, assuming it could be reliably and efficiently done, would at least force inscription scripts to be "plausible", and would greatly increase their space cost by e.g. requiring OP_DROP to be added somewhere hundreds of times. -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
