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

Olaoluwa Osuntokun laolu32 at gmail.com
Wed Nov 29 09:22:22 UTC 2017


FWIW, going by the bitnodes tracker [1], most upgraded nodes are currently
running a bitcoind version >= 0.14. With segwit widely deployed, I'd safe
say it's a safe bet to assume that most miners are already running with
the standard malleability reducing policy that shipped in that version.

However, as you point out there's still the possibility that the Eve's
first element of Eve's witness stack would pushes the fee rate of Alice's
justice transaction to an "insufficient" range. If the justice transaction
is delayed excessively, then there's a chance that the commitment output
of the peer breaching the transaction matures before Alice's justice
transaction is confirmed. In this case, Eve may successfully breach the
contract.

In lnd, we have plans to implement a scorched earth policy when responding
to on-chain contract breach event. With this policy, once our justice
transaction punishing the violator of the contract has been broadcast, for
each block it doesn't confirm in, we'll gradually bump of the fee on the
transaction (with RBF). The additional fee would be drawn from from the
*violator's* settled balance in that state. With each iteration (block, no
confirmation, fee bump) we gradually bleed away the funds of the violator,
supplementing the fee already present on that commitment state. Assuming
that rational miners accept the higher fee transaction (and the violator
isn't colluding with miners), then our justice transaction will make it
into the block before the transaction breaching the contract. In an
attempt to counter act this, the violator may try to use CPFP to anchor
the transaction into the chain with a more attractive fee package.
However, in order to beat us in, they must spend a total amount of fees
that is greater than the current cumulative fee rate on our justice
transaction. If they do so, they'll either end up net negative, or fail to
profit (as they'll also bleed away all their funds).


The vindication strategy described requires the justice transaction to
signal RBF. This serves as another reason to signal RBF in justice
transactions. I recommend that all implementations adopt the scorched
earth vindication strategy when handling breached contracts. It addresses
Dorier's malleability concern, and also further stack the incentives
against attempting a contract breach.


[1]: https://bitnodes.earn.com/nodes/

-- Laolu

On Tue, Nov 28, 2017 at 11:40 PM Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:

> Actually this was merged as policy rules in 0.14, not 0.15.1.
> Not as bad as I thought, but still a bit uneasy about someone malleating
> my transaction.
>
> Another way to fix the situation which would not require the BOLT to
> change is to enable RBF of the Penalty transaction so Eve transaction would
> be replaced by the initial one.
>
> Nicolas,
>
> On Wed, Nov 29, 2017 at 4:11 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
> wrote:
>
>> 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.
>>
>> ```
>> 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.
>>
>> 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.
>>
>> ```
>> 1 OP_EQUAL OP_IF
>>     # Penalty transaction
>>     <revocationkey>
>> OP_ELSE
>>     `to_self_delay`
>>     OP_CSV
>>     OP_DROP
>>     <local_delayedkey>
>> OP_ENDIF
>> OP_CHECKSIG
>> ```
>>
>> Nicolas,
>>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171129/ab719344/attachment-0001.html>


More information about the Lightning-dev mailing list