Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9320E83D for ; Thu, 18 Aug 2016 00:11:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B72E61F1 for ; Thu, 18 Aug 2016 00:11:57 +0000 (UTC) Received: by mail-qk0-f180.google.com with SMTP id v123so3090289qkh.2 for ; Wed, 17 Aug 2016 17:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gBIpv3Hu0WmTsezeXmvsrnZ9cuLrvGwosAkRJR1uhMY=; b=nDvbHy9NVkxLw3zJxy9cLrurAGkYFWQccbtDqMmqSQp/MpOgE9jn2bW37+TsW2aka7 5TcxKhkgY5KL6w3Jj//wqpTQ6DJlvD5gOQJcboydk9HMDnSTsx2OCDG0ISMGuNmWT5i+ TLaIaeAP7oiLDxka3IqOhFS4f1vpTKbW90kzabvnLm0QUZWZlAlkbLkXM/7mWXQviXRq dGBbwkuQYpNL8kVAbsb0fmINV/jf75+jpxi977mSprSTKn1jbO5eri9UhB7J37v2N2DY VbX55EolynSQriVxvMO6W99MYf4mM7vetV//qF4xRtJrf+4jy9VkuDW+p2zoiuGPFS/D QT/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gBIpv3Hu0WmTsezeXmvsrnZ9cuLrvGwosAkRJR1uhMY=; b=eC+9OB30XWVG7dLS0zp8/U0YyWntgG3Y7X7qSvgSHymyeZBvdI9YiDe2ICotfRipN7 kdTdw3Xdd/i4efUCrJutvo8/QWJ8K9x2pJIIYsUm+CssSlL0gf1HBNn1pK4ycUIskstL lLQKmWInXiVqU7gnYhhbI6xdQCouM6ls0RrL37T3L74hjS/0pIXIlXjf97DumdfscImf lpevqRz0lJv36H5WaE0cNJXa5nBW5APe3N3d+2Pa2RNa26Syx1ihy3OZBLNSu+YF2Fv0 NRoJazvhCas6fP6tE4jxs9cnVgkvnDr91ahwRvpsiM2PFLBPcUFcc9vUYt+KFjbgV1so x9Bw== X-Gm-Message-State: AEkoousTtO6sjbdrn/n5XY1tUn2BZolLGl/ad12946uusP/gbkW51u6O5wsHm7Zwap26odjrLqAnt1KXFaa1LA== X-Received: by 10.55.130.130 with SMTP id e124mr27147938qkd.51.1471479116970; Wed, 17 Aug 2016 17:11:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.46.221 with HTTP; Wed, 17 Aug 2016 17:11:16 -0700 (PDT) In-Reply-To: <703193091.96057.1471428948569@privateemail.com> References: <1736097121.90204.1471369988809@privateemail.com> <976728541.94211.1471402973613@privateemail.com> <201608170440.35767.luke@dashjr.org> <703193091.96057.1471428948569@privateemail.com> From: Sergio Demian Lerner Date: Wed, 17 Aug 2016 21:11:16 -0300 Message-ID: To: Johnson Lau , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c06e1800fbe42053a4d6e61 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 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: Thu, 18 Aug 2016 00:11:58 -0000 --94eb2c06e1800fbe42053a4d6e61 Content-Type: text/plain; charset=UTF-8 I think that we're not attacking the real source of the problem: that the witness data size is not signed. It may be the case that a new source of malleability is detected in witness programs later, or related to new opcodes we'll soft-fork in the future. The problem is real, as some systems (such as hardware wallets or other low-memory IoT embedded systems) may have hard limits in the size of the witness program they can accept. So we need a solution for all current and future segwit extension problems. We could soft-fork to add an opcode OP_PROGSIZE using segwit script versioning that pushes in the stack the size of the segwit program being evaluated, and then the script can take any action it wishes based on that. Example: <0x50> OP_PROGSIZE OP_GREATERTHAN OP_VERIFY ..... OP_CHECKSIG Then an attacker cannot create a clone of the transaction having a witness ECDSA signature longer than 0x50 bytes. (many details omitted in this example) On Wed, Aug 17, 2016 at 7:15 AM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On August 17, 2016 at 12:40 AM Luke Dashjr wrote: > > > > > > On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev > wrote: > > > To completely replicate the original behaviour, one may use: > > > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if > script} > > > ELSE DROP {else script} ENDIF" > > > > This is much uglier than expected. IMO if that's the best workaround for > the > > current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if > they > > need to avoid malleability issues. > > It is ugly only if you want to faithfully replicate the behaviour. I'd > argue that in no real use case you need to do this. For example, "OP_SIZE > OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_SIZE must > return a valid MINIMALDATA number. > > And your workaround does not fix malleability, since any non-0x01 values > are valid FALSE > > However, in some case, enforcing MINIMALIF does require 1 more witness > byte: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/ > 013036.html > > I think the best strategy is to make it a relay policy first, and decide > whether we want a softfork later. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c06e1800fbe42053a4d6e61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that we're not attacking the real so= urce of the problem: that the witness data size is not signed. It may be th= e case that a new source of malleability is detected in witness programs la= ter, or related to new opcodes we'll soft-fork in the future.

The problem is real, as some systems (such as hardware wallets or = other low-memory IoT embedded systems) may have hard limits in the size of = the witness program they can accept. So we need a solution for all current = and future segwit extension problems.

We could soft-fork to add an o= pcode OP_PROGSIZE using segwit script versioning that pushes in the stack t= he size of the segwit program being evaluated, and then the script can take= any action it wishes based on that.

Example:
<0x50> OP_PR= OGSIZE OP_GREATERTHAN OP_VERIFY ..... OP_CHECKSIG

Then a= n attacker cannot create a clone of the transaction having a witness ECDSA = signature longer than 0x50 bytes. (many details omitted in this example)


On Wed, Aug 17, 2016 at 7:15 AM, Johnson Lau via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote= :
=20


> On August 17, 2016 at 12:40 AM Luk= e Dashjr <luke@dash= jr.org> wrote:
>
>
> On Wednesday, August 17, 20= 16 3:02:53 AM Johnson Lau via bitcoin-dev wrote:
> > To completely= replicate the original behaviour, one may use:
> > "DEPTH TO= ALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script}
> = > ELSE DROP {else script} ENDIF"
>
> This is much ugli= er than expected. IMO if that's the best workaround for the
> cu= rrent behaviour, people should just use "OP_1 OP_EQUAL OP_IF" whe= n/if they
> need to avoid malleability issues.

It is ug= ly only if you want to faithfully replicate the behaviour. I'd argue th= at in no real use case you need to do this. For example, "OP_SIZE OP_I= F" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_= SIZE must return a valid MINIMALDATA number.

And your workaround does= not fix malleability, since any non-0x01 values are valid FALSE

Howe= ver, in some case, enforcing MINIMALIF does require 1 more witness byte:=C2= =A0https://lists.linuxfoundation.or= g/pipermail/bitcoin-dev/2016-August/013036.html

I think= the best strategy is to make it a relay policy first, and decide whether w= e want a softfork later.


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


--94eb2c06e1800fbe42053a4d6e61--