Ethan Heilman expressed his belief that enabling OP_CAT would be valuable for building protocols on Bitcoin. Andrew Poelstra added that OP_CAT could be useful for creating Merkle trees and manipulating signatures, among other applications. Meanwhile, ZmnSCPxj and Peter Todd discussed the efficiency of OP_CAT compared to SHA256STREAM, with ZmnSCPxj noting that OP_CAT could have a worst-case scenario of O(n^2) behavior. However, ZmnSCPxj suggested that limiting the maximum output size of OP_CAT could help reduce this worst-case behavior.Another email exchange on the Lightning-dev mailing list raised the question of using OP_SHA256STREAM versus OP_CAT for constructing midstate in scripts. While there may not be a significant advantage to using OP_SHA256STREAM over OP_CAT, it was noted that OP_CAT could have less efficient behavior in certain cases. Jeremy proposed using a correctly constructed midstate to prevent attacks on scripts under user control, but Peter Todd questioned the advantage of this approach compared to using OP_CAT followed by OP_SHA256.The discussions also touched on the need for OP_CAT in building protocols and the limitations of scriptless scripts. There was a proposal to replace OP_CAT with an OP_SHA256STREAM opcode, which would allow concatenation of unlimited data as long as it is only used for hashing. However, concerns were raised about the security implications of exposing raw SHA256 midstates. Additionally, ZmnSCPxj proposed a new opcode called OP_SETPUBKEYSIGHASH, which would allow for selecting the SIGHASH flag at the time of signing while still committing to the intended SIGHASH. This proposal aimed to address the malleability issue in Bitcoin transactions.The bitcoin-dev mailing list also discussed the proposal for OP_SHA256STREAM and its potential security concerns. Experienced cryptographers have already proposed designs that fall victim to attacks exploiting the exposed raw SHA256 midstates, leading to suggestions that such attacks should not be encouraged.In another discussion on the Lightning-dev mailing list, various solutions were proposed to improve data concatenation while hashing. Jeremy Rubin suggested using OP_SHA256STREAM, but concerns were raised about its future obsolescence if SHA256 is ever broken. Ethan Heilman agreed with this concern and proposed increasing the size of inputs for OP_CAT to enhance performance and usefulness. The group also discussed the limitations of OP_CAT for building Merkle trees in Bitcoin blocks and the possibility of implementing tagged SHA256 as a new opcode.Furthermore, ZmnSCPxj proposed removing SIGHASH flags from signatures and putting them on public keys instead. This would ensure that public keys determine the sighash algorithm rather than the signature itself. To achieve this, ZmnSCPxj suggested the addition of the OP_SETPUBKEYSIGHASH opcode, which would allow public keys to be indirectly committed to every output scriptPubKey. This proposal included guidelines for hiding public keys until they are needed, such as using MAST-inside-Taproot.In summary, the discussions revolved around the potential benefits and limitations of OP_CAT in Bitcoin protocols, the efficiency comparison between OP_CAT and SHA256STREAM, the use of midstate in scripts, and proposals for improving data concatenation and addressing the malleability issue in Bitcoin transactions. These discussions highlighted the importance of considering both the practicality and security implications of different approaches in Bitcoin development.In a recent email thread, ZmnSCPxj suggests a potential solution to a problem discussed on the bitcoin-dev mailing list. The discussion revolves around the use of OP_CAT in Bitcoin, which allows concatenation of stack values. Ethan believes that enabling OP_CAT could result in smaller transaction sizes for his proposed protocols on Bitcoin, making it a valuable opcode. However, there is a challenge with Merkle trees as it becomes difficult to determine if a hash on a Merkle node is the hash of a Merkle subnode or a leaf transaction.ZmnSCPxj proposes implementing tagged SHA256 as a new opcode instead, while Ethan prefers increasing the size of inputs to OP_CAT. Another radical idea proposed by ZmnSCPxj is to remove SIGHASH flags attached to signatures and replace them with OP_SETPUBKEYSIGHASH. This feature retains the old feature where the sighash is selected at time-of-spending rather than time-of-payment. The proposal also includes adding a new opcode, OP_SETPUBKEYSIGHASH, that works by attaching a byte to public keys to select the sighash algorithm, allowing particular SIGHASH. The signature still commits to the SIGHASH it was created for, making it malleability-safe. The proposed solution removes the problems associated with SIGHASH_NONE and SIGHASH_SINGLE, as they are allowed only if the output specifically says they are allowed.In another conversation about Bitcoin design flaws, the