From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E4158722 for ; Tue, 16 Aug 2016 21:59:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com [209.85.192.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53213110 for ; Tue, 16 Aug 2016 21:59:01 +0000 (UTC) Received: by mail-pf0-f173.google.com with SMTP id y134so31348478pfg.0 for ; Tue, 16 Aug 2016 14:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightning.network; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wI5nQF3kkW+xLmUakOF0U5MtC+dNLGXwZOrHWKctwwQ=; b=FJ1gmpeYxQuNHUrj9Bo1SAGpzJeUyoASmVJhGFQvOEzsiE4rKCpWZExusxG1nGiE8w 7AJF1fQbLmt4gWEsaFFsWPZACTKrOU0iUAD+w1XwnoxKjsB6eqGalnjs3xkpAYGw5a5h gmUB5WT82Bl5VFDW1EjQl1rMZJebPowP9/R6Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wI5nQF3kkW+xLmUakOF0U5MtC+dNLGXwZOrHWKctwwQ=; b=KTQw6VK+z/1B4GCaFfQe2nUHXQlIrq4UhFfTmmP8HCtitZbrLRwRxknPhfk+o2Nosq iYxjf3hOcxckLPaR4tFfSVlYYk35ArHVwQYqcKOdZra0tr0BFjrLP5mvvuAtW0u+0PNk 30Jaq7t0giIgfFgPXpKpMlB5lbttcVnMj3PyrUQHI6ljwNn8dNLR7jUDAvVtpmvGiJQ0 Gkq5YjJVnOOMnbFPFO9HA7deHjfKQ82eOuEdcL7mB33CxWH7zFfpB2jKs3UOjIjzcEPp Bbz6fR8oI1wDm8B8hWptOl9xPJuhlTkA3XKceCJJrw4tu27Oo/M1IZbhsI2yA+SFtAG8 v4dA== X-Gm-Message-State: AEkoouvy9FIRjVwSFzPE1e1FgnlVI2RnaB98Bc+5O7hI+8YyA0Mp9nhXgErcEYUAweMkMQ== X-Received: by 10.98.155.17 with SMTP id r17mr68108018pfd.24.1471384740966; Tue, 16 Aug 2016 14:59:00 -0700 (PDT) Received: from localhost ([2605:6400:20:11aa:189e:28a5:52ed:8948]) by smtp.gmail.com with ESMTPSA id p187sm41649056pfb.5.2016.08.16.14.59.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Aug 2016 14:59:00 -0700 (PDT) Date: Tue, 16 Aug 2016 14:58:58 -0700 From: Joseph Poon To: Peter Todd , Bitcoin Protocol Discussion 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> X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 16 Aug 2016 22:02:16 +0000 Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:59:02 -0000 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