From therealsangaman at gmail.com Sat Apr 14 04:17:18 2018 From: therealsangaman at gmail.com (Daniel McNally) Date: Sat, 14 Apr 2018 04:17:18 +0000 Subject: [Lightning-dev] Commitment delay asymmetry In-Reply-To: References: <87vacwvuqn.fsf@rustcorp.com.au> Message-ID: 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. Daniel On Fri, Apr 13, 2018, 6:10 PM Jim Posen wrote: > > By extension, perhaps both sides should use the maximum delay either one >> asks for? >> > > I'm not sure that is necessary. As long as both parties have to wait the > same amount of time regardless of whether they publish the commitment or > the other side does, that would resolve the issue. > > >> I don't think it's urgent, but please put it into the brainstorming part >> of the wiki so we don't lose track?[1] >> > > I don't have access to add to the wiki. I'd write a section like: > > # Symmetric CSV Delay > > Change the script of the remote output of all commitment transactions to > require the full CSV delay. This acts as further incentive for both parties > to mutually close instead of waiting for the other side to unilaterally > close, and serves as punishment to misbehaving or unresponsive nodes that > force the other endpoint to go to chain. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: