[Lightning-dev] Commitment delay asymmetry

[ZmnSCPxj]

Good morning Jim,

>> It seems to me that adding an entire new attack vector in order to only *mitigate* (not eliminate!) another attack vector is not a good enough trade-off.  In particular the new attack seems *easier* to perform.  The current attack where I annoy the other side until it closes has the risk that the other side may have a high tolerance for annoyance, and decide not to close the channel unilaterally anyway.  But in a symmetric-delay world, I do not have to wait for the other side to get annoyed: I just trigger the lockup period immediately in the active attack.
>
> I don't see the two attacks in the symmetric case as any different from one another. In 1.1, you force a unilateral close by becoming unresponsive and forcing the other side to eventually broadcast the commitment. In this case you waste the other party's channel balance for the full time of the delay PLUS the additional time they wait around to determine if you are ever going to come online. In 1.2, you force a unilateral close by broadcasting yourself. This is actually a weaker attack because the other party only has to wait for the delay period and there is no uncertainty about when they will get access to funds. So basically, I see no reason for an attacker to ever choose 1.2 over 1.1.

You make a good point there, I understand.

>>> For example, in the case where the side unilaterally closing the channel has zero balance, the other side gets no delay and symmetry as measured by (coins locked) * (duration of lock) equals zero on both sides. When the side closing the channel has at least 50% of the balance, both sides must wait the full delay. Thoughts?
>>
>> So on channel setup where I am the funder to a 1BTC  channel I make to Daniel:
>>
>> * Daniel holds a commitment transaction with: ZmnSCPxj=1BTC+no delay, Daniel=0BTC+no delay
>> * I hold a commitment transaction with: ZmnSCPxj=1BTC+no delay, Daniel=0BTC+no delay
>
> I rather like Daniel's suggestion to scale the delay in proportion to the time-money lost by the broadcasting party. Essentially, the delay just serves as punishment, so we should ensure that the punishment delivered is no greater than the time-value lost by the initiator of the unilateral close.
>
> This example is not quite right: the commitment delays do not need to be the same in both commitment transaction with this scaling strategy. So the delay for the local output is ALWAYS the to_local_delay, as it is in the BOLT 3 spec today. When assigning the delay on the remote output, however, instead of using 0 as BOLT specifies now or to_remote_delay as I originally proposed, a better rule might be min(to_remote_delay, to_local_delay * to_local_value / to_remote_value). So the delay is never worse than what the opposite side would get by broadcasting themself, but is the punishment duration is reduced if the attacker broadcasts a commitment transaction in which the balance of funds is skewed towards the victim's end of the channel. However, I'm not sure how much this matters because as I argued above, an attacker should always prefer to become unresponsive rather than broadcast the commitment themself.

This seems complicated, so perhaps just make delays equal as in the original proposal.  Of course, each side has its own `to_self_delay` that currently is applied to the other side.  It seems best the rule:

If I impose a specific `to_self_delay`, that applies to your commitment transaction, but for both branches of that.

My commitment transaction will have delays from your `to_self_delay` setting.

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180416/c7cd50b7/attachment.html>