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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
