From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: vjudeu@gazeta•pl,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
Date: Fri, 17 Feb 2023 23:35:34 +0000 [thread overview]
Message-ID: <Y/APRs3IPYapIpGg@camus> (raw)
In-Reply-To: <177016307-23dca06637e70217317077657442d0d8@pmq7v.m5r2.onet>
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-02-17 23:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 12:34 alicexbt
2023-02-17 14:56 ` vjudeu
2023-02-17 23:35 ` Andrew Poelstra [this message]
2023-02-17 23:39 ` Andrew Poelstra
2023-02-18 9:48 ` vjudeu
2023-02-18 18:03 ` Russell O'Connor
2023-02-18 0:03 ` Peter Todd
2023-02-18 1:28 ` Andrew Poelstra
2023-02-22 16:39 ` Peter Todd
2023-02-19 0:33 ` alicexbt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y/APRs3IPYapIpGg@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=vjudeu@gazeta$(echo .)pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox