-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug]: "lncli closechannel" may sometimes ignore the --sat_per_vbyte
argument
#8309
Comments
One thing I though to add to this. The |
Maybe the feerate was changed during the fee negotiation period when the channel was closing. Could you share some logs after calling |
Yeah the way things work right now is that both sides sort of "negotiate" what the fee rate should be. This can mean that ultimately, you may not get your exact fee rate. There's a new version of the co-op close protocol in the works that instead will just have either side pay what they can. It also allows resumption, so you can bump the fee via RBF. |
@yyforyongyu Here are lines in the logs which reference either
|
also:
|
Thanks for the logs, very helpful. First of all, you cannot use 100 sats/vb as the fee rate because your local balance cannot cover it, as shown in this line,
Given the size 278.5 vb and a fee rate of 100 sats/vb, you'd need at least 27850 sats as your local balance. Secondly, this channel is in a conflicting state,
The status Could you provide more details on how you used the command |
Thanks for the info. Yes, I think I tried a cooperative close, got some kind of error, and then tried a force close. |
I think we could improve the current coop-close negotiation, maybe it also affects the new design which will be introduced.
Wdyt ? |
Just wanted to add some more color to this from the perspective of a clueless user -- in case that is helpful. I am continuing to find that closing channels with LND is a scary/unpredictable process due to fee problems. Anecdotally, this is what I am finding: -- If I use -- If I use Note - I do understand that these fees are likely being pushed around in the negotiation process with the other node, so maybe it's not LNDs fault? Or at least not the fault of MY instance of LND? Next: To remediate these "too-low-fee" closes, I have referenced these directions: https://docs.lightning.engineering/lightning-network-tools/lnd/unconfirmed-bitcoin-transactions#docs-internal-guid-5647dd03-7fff-dc71-47cf-5f7e2155a44d I have tried commands like:
For both of these commands, If you would like me to grep the LND logs to try to see what LND did with these commands, please advise what I should search for. thanks! |
Looks like my problem when using ZeusLN. Look at the bottom for my log. |
Just chiming in with a similar issue: Tried force closing a channel that has been offline for a long time and got the following error:
Trying to bump the close fee with lncli doesnt seem to work either:
Any ideas? |
2 options:
|
Thanks for the insight. I'll give it a go and see if it works out! |
Background
Earlier today I tried the
lncli closechannel
command with a--sat_per_vbyte 100
argument.The closechannel transaction was broadcast with a much lower fee.
The transaction is now stuck. Here is the relevant result from
lncli pendingchannels
You can see the transaction here:
https://mempool.space/tx/f7b6fe0c4958e5ad303dab547143d3a7354d9945950cbe217773f9f487448296
You can see that it was broadcast at 13.7 sats/vB
Your environment
LND:
v0.17.2-beta
BITCOIND:
25.1
Expected behaviour
LND should use the
--sat_per_vbyte
argument to set the transaction feeActual behaviour
A much lower fee was broadcast.
The text was updated successfully, but these errors were encountered: