You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have received several reports, and have analysed a number of nodes, that had channels with pending sweeps. The sweeps however have a rather low feerate (sometimes bumping into the lower bound of 253sat / kvB), and they therefore remain unconfirmed for prolonged periods.
This issue collects instances, and is used to discuss how we should tune the feerates.
The text was updated successfully, but these errors were encountered:
I have a PR open on CLN (ElementsProject/lightning#7528) that'll set up a finite deadline, rather than the Scrooge McDuck approach of always waiting for another 300 blocks, no matter how long we already waited.
The logic in that one is the following:
Generally aim to confirm in less than 2 weeks
If we are further away than 300 blocks from the deadline, use 300 blocks as a very low priority feerate
If we are closer than 2h or even past the deadline of 2 week, use an urgent but not critical feerate estimate of 2h in the future (so we don't panic and go overboard with fees).
We are testing and will be deploying this on GL in the coming days.
We have received several reports, and have analysed a number of nodes, that had channels with pending sweeps. The sweeps however have a rather low feerate (sometimes bumping into the lower bound of 253sat / kvB), and they therefore remain unconfirmed for prolonged periods.
This issue collects instances, and is used to discuss how we should tune the feerates.
The text was updated successfully, but these errors were encountered: