Jim Posen [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-16 📝 Original message: > > It seems to me that ...
📅 Original date posted:2018-04-16
📝 Original message:
>
> 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.
So the question is whether 1.1 or 2.1 is a worse DOS. To me it's pretty
clear that it is 2.1 because the attacker does not get penalized and can
for more quickly use any remaining channel balance to open a new channel
with someone else and start over.
I also would not classify 1.1 nor 2.1 as a passive attack -- the attacker
is proactively rebalancing the victim's channel balances in order to waste
the maximal amount of time-money. Passive attacks [1] are where an attacker
does not directly interact with the victim and just eavesdrops or tries to
observe and extract information.
> > 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.
[1] https://en.wikipedia.org/wiki/Passive_attack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180415/b2c9ac05/attachment-0001.html>;
📝 Original message:
>
> 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.
So the question is whether 1.1 or 2.1 is a worse DOS. To me it's pretty
clear that it is 2.1 because the attacker does not get penalized and can
for more quickly use any remaining channel balance to open a new channel
with someone else and start over.
I also would not classify 1.1 nor 2.1 as a passive attack -- the attacker
is proactively rebalancing the victim's channel balances in order to waste
the maximal amount of time-money. Passive attacks [1] are where an attacker
does not directly interact with the victim and just eavesdrops or tries to
observe and extract information.
> > 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.
[1] https://en.wikipedia.org/wiki/Passive_attack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180415/b2c9ac05/attachment-0001.html>;