Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

From: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
To: Johnson Lau <jl2012@xbt•hk>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
Date: Wed, 17 Aug 2016 21:11:16 -0300	[thread overview]
Message-ID: <CAKzdR-qmL0Em058ama8CyAONrY2TbCSU7_SbfKoDEy0ZwnsFBA@mail.gmail.com> (raw)
In-Reply-To: <703193091.96057.1471428948569@privateemail.com>

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

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 <luke@dashjr•org> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3407 bytes --]