Author: ZmnSCPxj 2019-10-03 23:42:25
Published on: 2019-10-03T23:42:25+00:00
In a Bitcoin development mailing list, ZmnSCPxj proposed that OP_CAT, an opcode that concatenates two stack values, is extremely valuable and should be re-enabled with the limitation that each concatenated value must be 64 bytes or less. ZmnSCPxj explained that most of the protocols they wanted to build on Bitcoin ran into the limitation that stack values could not be concatenated and that TumbleBit would have far smaller transaction sizes if OP_CAT was supported in Bitcoin.However, there have been issues with the use of Merkle trees in Bitcoin blocks. Specifically, it is difficult to determine if a hash on a Merkle node is the hash of a Merkle subnode or a leaf transaction. Implementing tagged SHA256 as a new opcode might solve this issue. ZmnSCPxj also proposed a radical idea about removing SIGHASH flags from signatures and putting them on public keys instead. Public keys would be encoded as either 33-bytes (implicit SIGHASH_ALL) or 34-bytes (SIGHASH byte, followed by pubkey type, followed by pubkey coordinate). The `OP_CHECKSIG` would then look at the public key to determine the sighash algorithm rather than the signature. ZmnSCPxj suggested adding a new opcode `OP_SETPUBKEYSIGHASH` which would retain the old feature where the sighash is selected at time-of-spending rather than time-of-payment.
Updated on: 2023-06-13T21:41:55.952836+00:00