Daniel McNally [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-14 📝 Original message: This makes a lot of sense ...
📅 Original date posted:2018-04-14
📝 Original message:
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 <jim.posen at gmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180414/96622c6e/attachment.html>;
📝 Original message:
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 <jim.posen at gmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180414/96622c6e/attachment.html>;