Feedback-ID: i525146e8:Fastmail
Date: Wed, 22 Feb 2023 11:39:04 -0500
From: Peter Todd <pete@petertodd.org>
To: Andrew Poelstra <apoelstra@wpsoftware.net>
Message-ID: <Y/ZFKM2PGG+ijoBO@petertodd.org>
References: <TG0yVn41L6VFOHFRYqd3iGz7mxHWtjFdaBrz8mlP6Uk8bmog_isDbtq_2QyvdUs9_Q-jStmx7V7l5rAesXDfHlK9Ehft7SkK5EWQ_3mg-eQ=@protonmail.com>
 <177016307-23dca06637e70217317077657442d0d8@pmq7v.m5r2.onet>
 <Y/APRs3IPYapIpGg@camus>
 <B837E586-894E-40E8-9814-385EF59402B6@petertodd.org>
 <Y/Apxhqij1v56dT8@camus>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="eA6+M1CF4SFN2plB"
Content-Disposition: inline
In-Reply-To: <Y/Apxhqij1v56dT8@camus>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p
 network
Precedence: list


--eA6+M1CF4SFN2plB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
> > >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 dropp=
ed
> > >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.
> >=20
> > "greatly increase their space cost"?
> >=20
> > Tell me, what is the actual % increase to adding OP_DROPs like you prop=
ose?
> >
>=20
> 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%.
>=20
> 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 h=
our
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 consideri=
ng
all PUSHDATA's with certain characteristics to be data, so that encoders ca=
n 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 witne=
ss
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 do=
n't
mess with it. :D

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--eA6+M1CF4SFN2plB
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmP2RSYACgkQLly11TVR
Lzc5dw//VDyg9Dy7IzuB80yv9LXSoHR5Zv5sTlCYuUMUdhoanoYflKdMIiF8peGu
cJ7C7Xwx8+QIkNTUP+mgvlcTEETbZiC7F+k1n6eTavrYGpBMotVlkQHann+NxOU0
RPC2s17mc91Wo12tpbrp+vur4lQ3apnylDxeIeo0xkbsMzsX5XXGh0BPoD8aPT4y
jHo4TCBBIpXBOPI86VcbZKCgNrB2pZHRra3RHVjKFT9tyLM58A2qrtybMS2CzAj0
SmJAIzP1V1lmJSc6N/zlNuGwM6rBvG7o9UGZRENPq21Y0mPZ5YwlyerVnoE3AX21
Pwg7vMLOAd90VPmf/WjmGZx9x5050/AP3VmWTYsLnJDlmg/pPYtBF+SQ/EqJTsve
lfKSz23S5BFZnrG/6Vn5Vl7HKUfxuNT8/4tQbvZWlzWdX4o80zS3evrJ0Veb8Tv8
g4cPLUA5GGpwu5cm04LCDGyKMy5upX6rK9PiL3dRkuf3BZKfEpe9elLJxX5G2tSb
j3KvQFYOLRF0ycv4ecEdhMh6neKhCY4WqcuQGWcFGYg/yySrqA7UtXQfRjuEv8mJ
iGHGUNRO4Kz27Om7xDCy4gbi/Y3jBrK6twHcXK7Xid1EWIKFCkh6RWS8DBIi0iqD
K61Th/A6qn5r2DbOpeph/n91XZqv4u37KXHtgNt7o18Ue1GtfEk=
=Su2o
-----END PGP SIGNATURE-----

--eA6+M1CF4SFN2plB--