pull down to refresh
If I was going to create a new channel between two nodes, which I have control over, would it make sense to increase the CLTV Delta to let the two nodes be more forgiving to each other?
I am understanding CLTV Delta correctly?
Looking at my other Node B channels, CLTV Delta is set to 40 which I assume is default as I have not adjusted them.
Yes. If you increased it to 80, you would have twice the time to resolve the connectivity, feerate or other issue before resorting to force closing the channel. So your odds of hitting that would drop by at least half I would think. It would benefit your other channels as well because all nodes can have these disagreements. A CLTV delta of 40 seems reasonable, but it doesn't hurt to give your channel a bit more leeway if you're having issues with force closes.
Still, this kind of papers over the problem, so it would be good to get as much data as possible if this happens again.
Edit: In this case it was the CLN timeout that hit. To update that one, adding cltv-delta=80 to your config should do the trick. I should note that you can also manually override the feerate acceptance rules for this particular channel using lightning-cli setchannel -k id=<channel id> ignorefeelimits=true. I wouldn't do this for any channel where you don't control the other side. If you can't punch the channel owner in the face, don't set it! It puts your channel's funds at risk.
Still, this kind of papers over the problem
I am not oppose to papering over problems. :)
To update that one, adding cltv-delta=80 to your config should do the trick. I should note that you can also manually override the feerate acceptance rules for this particular channel using lightning-cli setchannel -k id=<channel id>
ignorefeelimits=true.
Is CLTV-Delta measure in numbers of Block?
For Core Lightning does ride the lightning (or another tool) let this be set from the GUI or only Terminal?
Yes, CLTV delta is the number of blocks, so for example, you could add 12 to the default to give your node about 2 more hours to resolve any issues with an active htlc.
RTL should allow you to edit your node's config file, but it doesn't give access to all of the setchannel parameters (even though I think it uses it under the hood to set channel fees.)
Cooperative doesn't mean anything about you personally, it just means both nodes agree to close the channel, so they can both sign the transaction without the unilateral timeout script. Node B saying remote force close, means the CLN node unilaterally closed the channel because there was a disagreement or timeout with the other node.
In this case, it looks like there was an HTLC that CLN was trying to remove, but it didn't get a revocation from LND before it had to drop it to chain to resolve. That still doesn't quite tell us the root issue. It could be connectivity, or the feerates are too far apart to update the commitment transaction, or maybe another issue that we'd need the log for.
On my node, I set the log destination in my config with
log-file=cl.logand it runs from my ~/.lightning/bitcoin directory so the log file ends up there. You can also setlog-level=debugif you want them more verbose, or even specify a subsystem likelog-level=debug:channeldIt might be useful to check the LND log prior to the force close and see if it was ever offline or if it complained about any channel traffic. The root cause could have started up to 34 blocks prior to the force close hit the chain.