From: Peter Todd <pete@petertodd•org>
To: Andrew Poelstra <apoelstra@wpsoftware•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
Date: Wed, 22 Feb 2023 11:39:04 -0500 [thread overview]
Message-ID: <Y/ZFKM2PGG+ijoBO@petertodd.org> (raw)
In-Reply-To: <Y/Apxhqij1v56dT8@camus>
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
On Sat, Feb 18, 2023 at 01:28:38AM +0000, Andrew Poelstra wrote:
> On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote:
> > On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev
> > >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.
> >
> > "greatly increase their space cost"?
> >
> > Tell me, what is the actual % increase to adding OP_DROPs like you propose?
> >
>
> 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%.
>
> Perhaps "greatly increase" is a stretch :) but if the fee market is
> functioning and we're talking about large amounts of data, it's not
> trivial either.
I would definitely call ~1% trivial. Fees vary more by that on an hour to hour
basis.
Anyway, it goes to show that protocols relying on data embedded in Bitcoin
transactions would do well to have flexible encoding rules, eg by considering
all PUSHDATA's with certain characteristics to be data, so that encoders can be
adapted on the fly if there are any censorship issues. It's also useful if the
rules allow data to be encoded in UTXO outputs, so that censorship of witness
data always risks people switching to filling up the UTXO set. A kind of
Mutually Assured Destruction threat in a way.
FWIW, OpenTimestamps was deliberately designed to have this property. So don't
mess with it. :D
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-02-22 16:39 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
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 [this message]
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/ZFKM2PGG+ijoBO@petertodd.org \
--to=pete@petertodd$(echo .)org \
--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