Proposed BIP for OP_CAT

The email discusses the topic of using the OP_CAT operation in Bitcoin Script. The sender mentions that there is confusion regarding whether the correct syntax is "0x01234567 0x89abcdef OP_CAT 0x0123456789abcdef OP_EQUAL" or if it should be reversed. They suggest that to ensure backward compatibility, testing the old implementation of OP_CAT before it was disabled could be considered.

The sender also points out that either choice would lead to similar consequences since it is possible to transform the former syntax into the latter by using "OP_SWAP OP_CAT" instead of just "OP_CAT". They believe that starting with this transformation could make it easier to reach a consensus for a new soft-fork.

The sender expresses surprise that this proposal has received a positive reaction, as they believed the path to OP_CAT was permanently closed. However, they acknowledge that the proposal has not been battle-tested and might have a chance of success. They mention that if OP_CAT were to allow concatenating up to a 520-bit Schnorr signature (not to be confused with 520-byte), people would create chains of OP_CATs to handle arbitrary sizes. The only limitation in this case would be the speed of the blockchain.

The sender speculates that if people are already attempting to build logical gates like NAND with Bitcoin Script, then all possibilities will likely be explored. Even if a more conservative approach is taken, such as switching to a 520-bit proposal instead of a 520-byte one, people will still perform similar actions. They note that the cost of pushing data onto the blockchain is now a significant factor, as everything can be executed on Script.

The sender concludes by mentioning that nothing is set in stone anymore, as people have discovered how to activate new features without requiring a soft-fork. They anticipate that some no-forks will be implemented by newcomers without thorough designing and testing, potentially leading to changes in the Bitcoin ecosystem.