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.

Lightning-dev mailing list

Reply via email to