Proposed BIP for OP_CAT

The email discusses the correctness of a specific code sequence and its implications for backward compatibility. The author mentions that they believed the original sequence "0x01234567 0x89abcdef OP_CAT 0x0123456789abcdef OP_EQUAL" was correct, but it could also be reversed. They suggest testing the old implementation of OP_CAT before it was disabled to ensure backward compatibility. However, they note that either choice will have similar consequences because the former sequence can be transformed into the latter by using "OP_SWAP OP_CAT" instead of just "OP_CAT". The author expresses surprise that this proposal received a positive reaction, as they thought the path to OP_CAT was permanently closed. Nevertheless, they acknowledge that such proposals have not been battle-tested and may have potential for success.

The email further discusses the idea of concatenating up to a 520-bit Schnorr signature using OP_CAT. It suggests that by chaining OP_CAT operations, arbitrary sizes can be achieved, limited only by the speed of the blockchain. The author speculates that even if a more conservative approach is taken and the proposal switches to a 520-bit format instead of bytes, people will still explore similar possibilities. They mention the use of Bitcoin Script to build logical gates like NAND, indicating that new features can be activated without a soft-fork. The author concludes by stating that nothing is set in stone anymore, as people now know how to activate new features without careful designing and testing, potentially leading to no-forks being done by newcomers.