-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Flag for manually specifying remote delay when opening channels #792
Copy link
Copy link
Closed
Labels
beginnerIssues suitable for new developersIssues suitable for new developerschannelscliRelated to the command line interfaceRelated to the command line interfacefeature requestRequests for new featuresRequests for new featuresfundingRelated to the opening of new channels with funding transactions on the blockchainRelated to the opening of new channels with funding transactions on the blockchaingood first issueIssues suitable for first time contributors to LNDIssues suitable for first time contributors to LNDrpcRelated to the RPC interfaceRelated to the RPC interface
Description
Metadata
Metadata
Assignees
Labels
beginnerIssues suitable for new developersIssues suitable for new developerschannelscliRelated to the command line interfaceRelated to the command line interfacefeature requestRequests for new featuresRequests for new featuresfundingRelated to the opening of new channels with funding transactions on the blockchainRelated to the opening of new channels with funding transactions on the blockchaingood first issueIssues suitable for first time contributors to LNDIssues suitable for first time contributors to LNDrpcRelated to the RPC interfaceRelated to the RPC interface
Type
Fields
Give feedbackNo fields configured for issues without a type.
As discussed in #788, the only way to manually set the remote CSV delay for channels is by using the
--defaultremotedelayflag at startup, which will be applied to all channels opened from that point on. In certain cases it is needed to manually specify this delay, in order to create channels compatible with less conservative implementations thanlnd. In particular, c-lightning tolerates a delay of maximum 3 days, whilelndscales all the way up to 2 weeks for large channels.While we want the defaults to be as safe as possible, it makes sense to allow the user to specify a shorter delay on a per channel basis, in the case she wants to open a channel with a node not supporting long delays. We should therefore add a flag to
openchannelthat let's the user specify this, the default still being scaling linearly with channel size.After such a flag is added, I think the
--defaultremotedelaystartup option can be made applicable only to incoming channels, as you can emulate it for outgoing channels with the new flag toopenchannel(if this simplifies the code in anyway).