Date: Sat, 21 Oct 2023 15:03:07 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Ethan Heilman <eth3rs@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZTPoK3aD8kFyhy3T@camus>
References: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="vdF/D/rAOCe016CG"
Content-Disposition: inline
In-Reply-To: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
Precedence: list


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

On Sat, Oct 21, 2023 at 01:08:03AM -0400, Ethan Heilman via bitcoin-dev wro=
te:
> Hi everyone,
>=20
> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
>=20
> OP_CAT was available in early versions of Bitcoin. It was disabled as
> it allowed the construction of a script whose evaluation could create
> stack elements exponential in the size of the script. This is no
> longer an issue in the current age as tapscript enforces a maximum
> stack element size of 520 Bytes.
>

Thanks, Ethan! This is really great, thank you for pushing forward and
writing up the BIP text.

In addition to the usecases listed in the text, I think CAT would open
up a wide range of Bitcoin script research and let us test nontrivial
things, in perhaps inefficient ways, in real life, befoer proposing
dedicated opcodes. When spitballing about ways to do cool stuff with
Bitcoin Script, I'd say about 90% of the time it ends with "we could do
this if only we had CAT". And the remaining 10% usually don't need much
more.

As evidenced by the short text and short implementation code, CAT is
very simple but provides a ton of value. There is a temptation to try
to bundle other opcodes in with this (for example, rolling SHA256
opcodes to allow hashing more than 520 bytes of data) but I think:

* There is no logical end to the list of opcodes we'd like to add, so
  this will invite an interminable amount of bikeshedding.

* No single opcode comes close to the power of CAT (except super
  general-purpose opcodes like OP_ZKP_VERIFY :))

* Most everything is more controversial than we expect. You can find
  Matt's "consensus cleanup" BIP from a couple years ago which did 4
  small things and I think that all 4 got a bunch of pushback.

So I think we should stick with "just CAT" :).

--=20
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


--vdF/D/rAOCe016CG
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmUz6CkACgkQxYjWPOQb
l8G8Egf/bnV3AQKC8brU/QDpSQcaaDTut/swCxCQ0orWaEX6eEkzKfuFSIsI4MHB
ADYJEIUFHXIkCx6/bf1MghBxTic63RvssQ/mgFo0P8Qbkzz7vADcR47huVPm8HTW
dS82ka4JxnhNflTUzcIlSk39d8GX+oCdOpdmPW1RnkygxKJkaO4jdNUxH8RLO0SP
KumHRA1LCNPY1ZhBwVkzIsKH8ketRsQqH6mfZVQ0Vx/WzFSQJwVozEqJiBOd97Kz
KbpUa5MMM/3xalwikxLlNKdPad+HGgTz7QcR5y8TB2I4TSwUkqgBRvuB+cGHNgWg
GxxU7D+IGNlxz3AvzLECvGemvT88Yw==
=iWnj
-----END PGP SIGNATURE-----

--vdF/D/rAOCe016CG--