Lnd: Feature Request: Specify the lowest CSV delay we're willing to accept

[lsching17]

Is there a option specifying the csv for autopilot to open channel?

Higher csv should means more time for disaster recovery.

[wpaulino]

At the moment, there is no way to specify or constrain your own CSV delay. You can do so for the remote party with --bitcoin.defaultremotedelay. See lnd -h for more help.

[lsching17]

At the moment, there is no way to specify or constrain your own CSV delay. You can do so for the remote party with --bitcoin.defaultremotedelay. See lnd -h for more help.

version: v0.5.1-beta

I added "bitcoin.defaultremotedelay=864" in lnd.conf and restarted lnd. Some new channels are createds in the 2 days. As my instance is running from nat, i think the new connections are created by autopilot.

Some of the new channel's csv_delay is still below 864, am i missing something?

[wpaulino]

The flag is to set it for the remote party, not yourself. You set theirs and they set yours.

[lsching17]

Thx for your help

[halseth]

A lower toSelfDelay is always preferable from your POV. Is making it possible to specify the max what you want?

[Roasbeef]

Related to #3758

[mrfelton]

I'm interested in this too, as I have learned in https://github.com/lightningnetwork/lnd/issues/4613 force closures can happen for a variety of reasons, many of which are outside of my control.

As I understand it, when opening a channel to another party I can specify what their CSV delay will be but not my own.

But this is a key consideration from both sides of the channel:

Channel initiator

From the perspective of the channel initiator I'm concerned with the question:

"how long will I have to wait to get my funds back in the event of a force closure?"

The answer as I understand it is that my delay will be set by the defaultremotedelay config option of the remote node and there is no way to know what this is until after I have opened the channel.

It would be useful to know this upfront so that I can decide if I like the policy that the other node has set in advance of me committing funds to the channel. I might not want to open the channel if I may have to wait 2 weeks to get my funds back, but I might be more interested if I knew that the wait time was only 4 days.

Furthermore, it would be useful if there was a way for me to specify my own preference for this value when opening the channel.

I can think of two things that could be useful here:

1. Provide details of a node's remote csv delay policy as part of the GetNodeInfo RPC response.

2. Allow the channel initiator to set local_csv_delay as part of the OpenChannel RPC.

Channel acceptor

From the perspective of the channel acceptor I'm also concerned with the same question:

"how long will I have to wait to get my funds back in the event of a force closure?"

When a channel is opened to me it is the other party that specifies how long I will have to wait.

As a channel acceptor I have the ability to implement the ChannelAcceptor stream in which I could intercept incoming channel opening requests and reject them if csv_delay is unacceptable to me. This allows me to control my own risk and only accept channels that, in the event of a force closure, will lock up my funds for a period that I'm happy with.

[carlaKC]

Mostly going to touch on setting an upper limit on our own CSV delay here. I think that we have sufficient options for setting the remote party's delay (we default to DefaultRemoteDelay, a custom value for channels we open can be set with theremote_csv_delay field in OpenChannel , and #4683 will allow setting of custom value for incoming channels.)

The situation at the moment for restricting our own CSV delay is:

• Outgoing channel (we open): we fail the channel if the remote delay is > 10000 (which is a hard coded const), as per BOLT 2 to fail unreasonably long delays
• Incoming channel (they open): as above, we fail unreasonably long delays. If you have a channel acceptor enabled, you can dynamically reject channels based on the proposed CSV delay (csv_delay in the request sent to your acceptor).

Some actions we can take:

1. Add a MaxLocalCSVDelay config option which we check for outgoing and incoming channels, failing if the remote party's value exceeds this. This is a nice set-and-forget option, and covers incoming channels for those not running channel acceptors.

1. If there is a requirement to set a per-channel max local csv delay (@mrfelton ?), we can also add a max_local_csv to the OpenChannel rpc message, and we will fail the channel if it exceeds this custom value for the channel. This is a nice-to-have because you can decide the delay you will accept based on the amount of the channel.

I am going to start on (1) because that's quite a simple change, and I think takes us a long way. (2) will likely need some db changes (albeit minor), so going to hold off on that until it's confirmed that there is a requirement for this.

[mrfelton]

If there is a requirement to set a per-channel max local csv delay (@mrfelton ?), we can also add a max_local_csv to the OpenChannel rpc message, and we will fail the channel if it exceeds this custom value for the channel. This is a nice-to-have because you can decide the delay you will accept based on the amount of the channel.

We would find this useful @carlaKC - so that we when opening channels, we can scale this setting appropriately to our preferences inline with the typical channel sizes that we open.

[carlaKC]

we can scale this setting appropriately to our preferences inline with the typical channel sizes that we open.

Yeah thought so! Will get to this as well 👍