[Lightning-dev] Commitment delay asymmetry

ZmnSCPxj ZmnSCPxj at protonmail.com
Sun Apr 15 13:35:55 UTC 2018

Good morning Daniel,

> This makes a lot of sense to me as a way to correct the incentives for closing channels. I figure that honest nodes that have truly gone offline will not require (or be able to take advantage of) immediate access to their balance, such that this change shouldn't cause too much inconvenience.
> I was trying to think if this could open up a DOS vector - dishonest nodes performing unilateral closes even when mutual closes are possible just to lock up the other side's coins - but it seems like not much of a concern. I figure it's hard to pull off on a large scale.

Now that you bring this up, I think, it is indeed a concern, and one we should not take lightly.

As a purely selfish rational being, it matters not to me whether my commitment transaction will delay your output or not; all that matters is that it delays mine, and that is enough for me to prefer a bilateral close if possible.  I think we do not need to change commitment transactions to be symmetrical then --- it is enough that the one holding the commitment transaction has its own outputs delayed.

If I had a goal to disrupt rather than cooperate with the Lightning Network, and commitment transactions would also delay the side not holding the commitment transaction (i.e. "symmetrical delay" commitments), I would find it easier to disrupt cheaply if I could wait for a channel to be unbalanced in your favor (i.e. you own more money on it than I do), then lock up both our funds by doing a unilateral transaction.  Since it is unbalanced in your favor, you end up losing more utility than I do.  Indeed, in the situation where you are funding a new channel to me, I have 0 satoshi on the channel and can perform this attack costlessly.

Now perhaps one may argue, in the case of asymmetric delays, that if I were evil, I could still disrupt the network by misbehaving and forcing the other side to push its commitment transaction.  Indeed I could even just accept a channel and then always fail to forward any payment you try to make over it, performing a disruption costlessly too (as I have no money in this).  But this attack is somewhat more passive than the above attack under a symmetrical delay commitment transaction scheme.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180415/bc7a2473/attachment.html>

More information about the Lightning-dev mailing list