<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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.</span></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><div>> 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?<br></div><div><br></div></span><div>So on channel setup where I am the funder to a 1BTC channel I make to Daniel:<br></div><div><br></div><div>* Daniel holds a commitment transaction with: ZmnSCPxj=1BTC+no delay, Daniel=0BTC+no delay<br></div><div>* I hold a commitment transaction with: ZmnSCPxj=1BTC+no delay, Daniel=0BTC+no delay</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>[1] <a href="https://en.wikipedia.org/wiki/Passive_attack">https://en.wikipedia.org/wiki/Passive_attack</a></div></div></div></div>