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.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
