OP_CAT was Re: Continuing the discussion about noinput / anyprevout

The email discussion between Ethan and ZmnSCPxj revolves around the use of OP_CAT in Bitcoin, which allows concatenation of stack values. Ethan believes that enabling OP_CAT could lead to smaller transaction sizes for his proposed protocols on Bitcoin and it would be 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 suggests implementing tagged SHA256 as a new opcode instead, but Ethan prefers increasing the size of inputs to OP_CAT. In another email, ZmnSCPxj proposes a radical idea 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.