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