Proposed BIP for OP_CAT

The email discusses the limitation of 520 bytes in relation to the lack of rolling sha2 opcodes. The sender believes that with the presence of these opcodes, 65 bytes would be sufficient. However, without them, it is unclear what value would be considered "enough". For the purpose of emulating CHECKSIGFROMSTACK, the sender suggests the need for the ability to construct a full transaction on the stack, which would require a 4M limit. Despite this, the sender acknowledges that minimizing changes and maintaining the existing stack element limit of 520 bytes may be a more viable strategy to achieve consensus.

It is mentioned that Bitcoin Core currently limits the stack size to 1000 elements, each with a maximum size of 520 bytes, resulting in a theoretical limit of 520k. The sender notes that Bitcoin Core does not explicitly count the "total stack size" as suggested, but rather enforces the two separate limits. Adding a "total stack size limit" would introduce complexity in accounting and require modifications to almost every other opcode, which may not be worth the added consensus logic.

The email is from Andrew Poelstra, Director of Research at Blockstream, and his contact information is provided at the end.