Author: Ethan Heilman 2019-10-04 00:48:17
Published on: 2019-10-04T00:48:17+00:00
The conversation is about the proposal of a new opcode called OP_CAT in Bitcoin. The proposal suggests increasing the size of two inputs to OP_CAT to 260 Bytes each where 520 Bytes is the maximum allowable size of object on the stack, which seems sensible and also doesn't special case the logic of OP_CAT. This would increase performance since SHA256(tag||subnode2||subnode3) requires 2 compression function calls whereas SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3 compression function calls (due to padding).The discussion then moves to the idea of implementing tagged SHA256 as a new opcode, but it is agreed that OP_CAT provides far more utility and is a simpler change. However, there are issues with the use of Merkle trees in Bitcoin blocks, specifically determining if a hash on a Merkle node is the hash of a Merkle subnode or a leaf transaction. This is why transactions are required to be at least 80 bytes. To fix this issue, the suggestion is to prepend the type of the hashed object, i.e. add at least one byte to determine this type.The proposal then moves on to the removal of `SIGHASH` flags attached to signatures, which are a misdesign and should be removed. Instead, `SIGHASH` should be put on public keys by encoding them as either 33-bytes (implicit `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey coordinate). `OP_CHECKSIG` and friends then look at the public key to determine sighash algorithm rather than the signature. If implemented, this 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:00.894638+00:00