On Sat, Oct 21, 2023 at 01:08:03AM -0400, Ethan Heilman via bitcoin-dev wrote: > Hi everyone, > > 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 > > 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" :). -- 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