[Lightning-dev] BOLT3: Commitment Transaction Outputs is weak to malleability

[Rusty Russell]

Nicolas Dorier <nicolas.dorier at gmail.com> writes:
> I noticed the Commitment Transaction Output script is weak to malleability,
> this can be used to delay confirmation of the revocation.
> Luckily, fixing the situation does not require lots of development.

Oh, wow!  FWIW I'm a bit mindblown by your level of adversarial
thinking.

I've filed bug https://github.com/lightningnetwork/lightning-rfc/issues/295

We use this pattern in 3 places: elsewhere we use 0-or-valid-sig which
doesn't have this issue.

> ```
> OP_IF
>     # Penalty transaction
>     <revocationkey>
> OP_ELSE
>     `to_self_delay`
>     OP_CSV
>     OP_DROP
>     <local_delayedkey>
> OP_ENDIF
> OP_CHECKSIG
> ```
>
> An attacker can delay the Penalty Transaction by malleating it. Which can
> lead to very bad outcome as Lightning dependant on time locks.
>
> The penalty transaction would have.
>
> ```
> <revocation_sig> 1
> ```
>
> Problem is that Eve could malleate OP_1 into a positive, huge number. This
> would have for effect to fill the mempool of nodes/miners with the
> malleated version which will have an higher fee rate, delaying the
> confirmation of the penalty transaction.

You mean lower fee rate, right?

They could replace 1 byte with 80 bytes, AFAICT.  That would increase
weight by 79 Sipa[1], which worst-case is almost 15% feerate drop.

> Now, there is a policy rule called SCRIPT_VERIFY_MINIMALIF by jl2012 which
> was merged into v0.15.1. (
> https://github.com/bitcoin/bitcoin/commit/c72c5b1e3bd42e84465677e94aa83316ff3d9a14
> )
>
> I guess that by the time LN is ready, 0.15.1 will be spread enough among
> miners, but still I think a 2 bytes overhead is well worth the fix.

We should probably strongly suggest RBF in the spec; you can easily
underguess fees by 15% anyway and should deal with it appropriately.

Since spec is frozen and issue is probably moot, I'm tempted to leave it
as is.

Thanks!
Rusty.