Feedback-ID: i525146e8:Fastmail
Date: Mon, 8 May 2023 23:55:57 +0000
From: Peter Todd <pete@petertodd.org>
To: Moth <moth_oshi@proton.me>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZFmMDYKxd7Uw6A4R@petertodd.org>
References: <SzOndBJmU5RPVdT2IhiWUmw925vgy-KCwrbWC4_e8tHVj5VWUn-Tr50TjxTczUUDcaVjUJEiuLVmFjfmtZwwvLyuUSkrGVg9uNje2oARArc=@proton.me>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="rJQYXhN1Z2LmqwxE"
Content-Disposition: inline
In-Reply-To: <SzOndBJmU5RPVdT2IhiWUmw925vgy-KCwrbWC4_e8tHVj5VWUn-Tr50TjxTczUUDcaVjUJEiuLVmFjfmtZwwvLyuUSkrGVg9uNje2oARArc=@proton.me>
Subject: Re: [bitcoin-dev] Witness script validation to reject arbitrary data
Precedence: list


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

On Mon, May 08, 2023 at 08:16:41PM +0000, Moth via bitcoin-dev wrote:
> From what I understand, things like inscriptions can only be inserted bet=
ween two specific flags - OP_FALSE and OP_IF.

That's just an artifical limitation of the current inscription protocol. Th=
ere
are endless ways to embed arbitrary data in Bitcoin transactions. Blocking =
them
all is a hopeless task.

> Having a validation check to reject witness scripts that have arbitrary d=
ata between these two flags could be used to reject inscriptions while stil=
l allowing all the benefits of taproot. This will prevent people from overl=
oading the network with txns geared solely for ordinals and brc-20 tokens.
>=20
> Is there a reason such a validation check is a bad idea? We already have =
OP_RETURN to store arbitrary data that is limited to 80kb. Was it an oversi=
ght that arbitrary data can be inserted between OP_FALSE and OP_IF when the=
 size limit for witness scripts was lifted as part of taproot?

It's pointless to even try.

The current flood of inscription txs are very small, about 150vB, and embed
very little data in the chain. They could have just as easily used OP_RETURN
outputs or any number of other data encoding techniques. Blocking that kind=
 of
use-case is hopeless.

The _purpose_ of the current flood of BRC-20 inscriptions - tl;dr the creat=
ion
of a new set of assets via an auction - is something that doesn't even requ=
ire
any data to be embedded in the chain at all. They could have implemented th=
em
with perfectly normal transactions indistinguishable from any other
transaction. Blocking that is truly hopeless.

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

--rJQYXhN1Z2LmqwxE
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmRZjAIACgkQLly11TVR
Lzd8nQ//fVfilxhtTEPyxK8BnE4IP/j4/Dq1JhB+XQaB8SdPKhKFe0pBc4JQB7ZN
4jVmgvgQay86Q9W4QWDLbO5T2caONR2L5zGRuXtfprjxmD/UE2fdR5mqcdqoAzFe
HXUU2mp8y/r8zVm6ieJHn6IbAh9KYOecsXqo+gJC3NuQ/Ns88/U27MzHr2pEaUe0
R0ScNgqzmhJcmxya+JfgCDZG2v0VgEuSGfTw+h0kEk1rj/U+RkL6LtJRk947ye0K
pqMVXAosl7zLw2qel8R+VE08fmzaJLK3NGbSAkYCqz8y7MM+JPFcxUGodpisocl4
xYTprm2JUoS/U2Y+xU98hrYZJ5KOt+5TZ43oXUw+q1UrupjInbfiKsnsrf8GU5yk
ow7ABmnybU8XWrVHB4kYWQw2RuvOQ6Xl2dEdtteAhVNocDKIp6BKdOzHbbCgg1AN
M4o/1Qb59YBkzjlgZuC0MRucs1WRTaqPWLd+s+i+zo4QSH82HHeo1+iDW1qB/hk0
SMXXHXGdFhhVEvMIjG+0ShK94bvjG+/Evn3e9ywOG00bb3Xn1SBYIqjtYjcH534j
8tX4NhXOuLSv5F6GAW4yHbR/Bvcchvt3TRkyEiKkp3iuWaEeJgYUm168h51R/pRl
C9MYvpfQPUf9Jw8fmuEILToNftkT8Ls41/ySyGPQFC9YuJPrYPQ=
=BuML
-----END PGP SIGNATURE-----

--rJQYXhN1Z2LmqwxE--