I agree this is an interesting area of transaction malleability to still consider in the future, and minimization of these areas of malleability with regards to its impact on the p2p network should be easy to resolve and (hopefully) well-understood by script writers in the future.
On Tue, Aug 16, 2016 at 12:43:32PM -0700, Peter Todd via bitcoin-dev wrote: > Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode > that fails unless the top item on the stack is a minimally encoded true or > false value, to allow script writers to opt into this behavior; it's not > always > ideal. I think the biggest value of the proposed BIP behavior is that the cost is lower for "doing it right" to create script enforcement of OP_TRUE or OP_FALSE. It is already possible to enforce with 2 bytes pushing OP_TRUE and then OP_EQUAL. Creating an "OP_CHECKBOOLVERIFY" definitely achieves the same result, but at a 1-byte (insetad of 2-byte) cost to "do it right", so there is the same incentive to save on the byte and push potential DoS costs onto the network -- whereas enforcing OP_TRUE byte in OP_IF would create costs for those who want to evaluate pushdata, so that has to be explicitly opt-in from an optimization/convenience standpoint. -- Joseph Poon _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev