Published on: 2015-11-10T10:52:46+00:00
In a discussion on the bitcoin-dev mailing list, the usage of OP_0 and OP_PUSH opcodes for pushing data is being debated. It is stated that OP_0 represents a zero-length byte array, whereas a single-byte string with 0x00 in it is not equal to an empty string. This leads to "false" being pushed as the result of comparison with OP_EQUAL. The participants suggest using only OP_0 and OP_1 for pushing data and not any other push opcode.One participant raises a concern about defining the "IF/NOTIF argument must be either zero-length array or a single byte 0x01" explicitly, as it contradicts the rule of minimally-encoded "zero". The aim is to prevent potential mutation of the transaction by changing the length of the array.The discussion takes place in relation to implementing a proposal alongside BIP62, which addresses malleability in OP_IF and OP_NOTIF. These flow control codes in the Bitcoin script system can be manipulated without invalidating the transaction. The proposal suggests that if the transaction version is three or above, the flow control value for OP_IF and OP_NOTIF must be either zero or one, or else the transaction fails. This change is a softfork and should be implemented with BIP62.To ensure compatibility with transactions created before the introduction of this BIP, the new rules only apply to transactions of version 3 or above. Those who wish to preserve the original behavior of OP_IF and OP_NOTIF can use an OP_0NOTEQUAL before the flow control code to transform any non-zero value to one. The proposal also emphasizes that one and zero should be defined as arrays of length one to prevent transaction mutation by changing the length of the array.Overall, the proposed BIP aims to fix the malleability issue in transactions with OP_IF and OP_NOTIF and should be implemented alongside other malleability fixes.
Updated on: 2023-08-01T16:49:16.229529+00:00