Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AEC278CC for ; Fri, 6 Nov 2015 09:27:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E84A7108 for ; Fri, 6 Nov 2015 09:27:24 +0000 (UTC) Received: by qgeb1 with SMTP id b1so34171107qge.1 for ; Fri, 06 Nov 2015 01:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=O3cXoCrnaV/PJIvlVRlufDintYat1itZGg8pO0hzW/s=; b=BJ+uHxrd5rMeKLYhFTnp8TF0ID9uKMSYZjknVLn7CiL2UX7TmkkA5yu8GCYNfbTTCT FrHDUwQYp+3l9OIrw6isssN3JPxFOgIraEqsxCSVTJo0XE1Cjmm8vAbMnFs3Eo1m0JQI up0ZNQkwdXblzl566ORPVCtVSyTdVzGs4OEQSK5Nm3yLYvOf63cCYcMZTO6qJjc4Xdxd +5ovln4gXsNE0m2LpSwwbS6LD8LoZNWrnr72A1fLHEH3pBD3HgXiI4EhFwcoSDfPs/VG uXIligk2sdkWbRXeZmzYKYeGwN70Vj2M05wVV0RTjTzW/3W5eHHfrpAY+Dx+bqGjFoG9 f5Ig== MIME-Version: 1.0 X-Received: by 10.140.81.21 with SMTP id e21mr12179641qgd.69.1446802044109; Fri, 06 Nov 2015 01:27:24 -0800 (PST) Received: by 10.140.93.82 with HTTP; Fri, 6 Nov 2015 01:27:24 -0800 (PST) In-Reply-To: <0e72b173ea8e8aaf6b1b678182fa1ea7@xbt.hk> References: <0e72b173ea8e8aaf6b1b678182fa1ea7@xbt.hk> Date: Fri, 6 Nov 2015 09:27:24 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c121b4e662120523dbd9c6 X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MALFORMED_FREEMAIL, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Dealing with OP_IF and OP_NOTIF malleability X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 09:27:25 -0000 --001a11c121b4e662120523dbd9c6 Content-Type: text/plain; charset=UTF-8 One and zero should be defined as arrays of length one. Otherwise, it is still possible to mutate the transaction by changing the length of the array. They should also be minimally encoded but that is covered by previous rules. On Fri, Nov 6, 2015 at 8:13 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I have a new BIP draft for fixing OP_IF and OP_NOTIF malleability. Please > comment: > https://github.com/jl2012/bips/blob/master/opifmalleability.mediawiki > > Copied below: > > BIP: x > Title: Dealing with OP_IF and OP_NOTIF malleability > Author: jl2012 > Status: Draft > Type: Standards Track > Created: 2015-11-06 > > Abstract > > As an supplement to BIP62, this document specifies proposed changes to the > Bitcoin transaction validity rules in order to make malleability of > transactions with OP_IF and OP_NOTIF impossible. > > Motivation > > OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. > The programme flow is decided by whether the top stake value is 0 or not. > However, this behavior opens a source of malleability as a third party may > alter a non-zero flow control value to any other non-zero value without > invalidating the transaction. > > As of November 2015, OP_IF and OP_NOTIF are not commonly used in the > blockchain. However, as more sophisticated functions such as > OP_CHECKLOCKTIMEVERITY are being introduced, OP_IF and OP_NOTIF will become > more popular and the related malleability should be fixed. This proposal > serves as a supplement to BIP62 and should be implemented with other > malleability fixes together. > > Specification > > If the transaction version is 3 or above, the flow control value for OP_IF > and OP_NOTIF must be either 0 or 1, or the transaction fails. > > This is to be implemented with BIP62. > > Compatibility > > This is a softfork. To ensure OP_IF and OP_NOTIF transactions created > before the introduction of this BIP will still be accpeted by the network, > the new rules only apply to transactions of version 3 or above. > > For people who want to preserve the original behaviour of OP_IF and > OP_NOTIF, an OP_0NOTEQUAL could be used before the flow control code to > transform any non-zero value to 1. > > Reference > > BIP62: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a11c121b4e662120523dbd9c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One and zero should be defined as arrays of length one.=C2= =A0 Otherwise, it is still possible to mutate the transaction by changing t= he length of the array.

They should also be minimally encoded but t= hat is covered by previous rules.

<= div class=3D"gmail_quote">On Fri, Nov 6, 2015 at 8:13 AM, jl2012 via bitcoi= n-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I have a new BIP draft for f= ixing OP_IF and OP_NOTIF malleability. Please comment: https://github.com/jl2012/bips/blob/master/opifmall= eability.mediawiki

Copied below:

BIP: x
=C2=A0 Title: Dealing with OP_IF and OP_NOTIF malleability
=C2=A0 Author: jl2012 <jl2012@xbt.hk>
=C2=A0 Status: Draft
=C2=A0 Type: Standards Track
=C2=A0 Created: 2015-11-06

Abstract

As an supplement to BIP62, this document specifies proposed changes to the = Bitcoin transaction validity rules in order to make malleability of transac= tions with OP_IF and OP_NOTIF impossible.

Motivation

OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The= programme flow is decided by whether the top stake value is 0 or not. Howe= ver, this behavior opens a source of malleability as a third party may alte= r a non-zero flow control value to any other non-zero value without invalid= ating the transaction.

As of November 2015, OP_IF and OP_NOTIF are not commonly used in the blockc= hain. However, as more sophisticated functions such as OP_CHECKLOCKTIMEVERI= TY are being introduced, OP_IF and OP_NOTIF will become more popular and th= e related malleability should be fixed. This proposal serves as a supplemen= t to BIP62 and should be implemented with other malleability fixes together= .

Specification

If the transaction version is 3 or above, the flow control value for OP_IF = and OP_NOTIF must be either 0 or 1, or the transaction fails.

This is to be implemented with BIP62.

Compatibility

This is a softfork. To ensure OP_IF and OP_NOTIF transactions created befor= e the introduction of this BIP will still be accpeted by the network, the n= ew rules only apply to transactions of version 3 or above.

For people who want to preserve the original behaviour of OP_IF and OP_NOTI= F, an OP_0NOTEQUAL could be=C2=A0 used before the flow control code to tran= sform any non-zero value to 1.

Reference

BIP62: https://github.com/bitcoin/bips= /blob/master/bip-0062.mediawiki

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a11c121b4e662120523dbd9c6--