From: vjudeu@gazeta•pl
To: Andrew Poelstra <apoelstra@wpsoftware•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
Date: Sat, 18 Feb 2023 10:48:02 +0100 [thread overview]
Message-ID: <177848612-ad2b15230d78bcd732bbe8621af89a1e@pmq3v.m5r2.onet> (raw)
In-Reply-To: <Y/AQH9s7RN14uKvE@camus>
> By standardness rules (where you can have up to 80-byte pushes), a little over 1%. By consensus (520-byte pushes) less than 0.2%.
Note that instead of "OP_DROP OP_DROP", people can use "OP_2DROP", so the number of dropping opcodes could be halved.
> I mean, they'd provide the `FALSE` as a separate witness element rather than being part of the witnessScript.
That means people can still reject an official alternative (for example commitments), so a different approach is needed to fight that spam. Assuming that transactions will be sent directly to the miners, they will be included, that way or another. So, the solution should assume that we will have large NOPs in the chain. And then, if we want to deal with them, some kind of pruning is needed. Switching from witness to non-witness node is not an option, because it would require additional witness validation, and because rules for OP_RETURN can be also lifted.
So, how to prune the Script? In a typical hash function, like SHA-256, data are splitted into smaller chunks, and then processed linearly. I think it is possible to store the first and the last chunk, and keep the internal state of SHA-256, before entering the last chunk. In this way, it should be possible to prune those OP_NOPs. Because that solution will also cover raw scripts (people can switch to them if witness will be more restricted than now).
Also, it gives us a hint, that if any Script upgrade will be considered in the future, we can think about doing it in a way, where unused parts can be pruned, without invalidating signatures.
On 2023-02-18 00:39:16 user Andrew Poelstra <apoelstra@wpsoftware•net> wrote:
> On Fri, Feb 17, 2023 at 11:35:34PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>
> 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.
>
I realize this is confusingly worded. I mean, they'd provide the `FALSE`
as a separate witness element rather than being part of the witnessScript.
--
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
next prev parent reply other threads:[~2023-02-18 9:48 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
2023-02-17 23:39 ` Andrew Poelstra
2023-02-18 9:48 ` vjudeu [this message]
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=177848612-ad2b15230d78bcd732bbe8621af89a1e@pmq3v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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