Date: Tue, 16 Aug 2016 14:58:58 -0700
From: Joseph Poon <joseph@lightning.network>
To: Peter Todd <pete@petertodd.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160816215858.GB2532@lightning.network>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160816194332.GA5888@fedora-21-dvm>
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
Precedence: list

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