Open kaloudis opened 2 weeks ago
:+1: Perhaps it could be helpful to see what other force close/sweeping actions were done before for that channel. Did the force close initiate while running v0.18 (i.e. without an upgrade)? Could you find out who force closed in the initial force close? Any backend specifics would be good to know as well.
Looks like it is related to https://github.com/lightningnetwork/lnd/pull/8345 from the log message not accepted by mempool
.
👍 Perhaps it could be helpful to see what other force close/sweeping actions were done before for that channel. Did the force close initiate while running v0.18 (i.e. without an upgrade)? Could you find out who force closed in the initial force close? Any backend specifics would be good to know as well.
Looks like it is related to #8345 from the log message
not accepted by mempool
.
I need to double check the timeline, but it is possible that the original FC was broadcasted while I was still on lnd v0.17.4. However this issue was not hit directly after the upgrade
The shutdown results from the error from TestMempoolAccept
not being handled gracefully, by maybe wrapping with mapRpcclientError(err)
here, to at least not shut down.
https://github.com/lightningnetwork/lnd/blob/c0f7c2849da9dea424574651505a7f2e4494f37f/lnwallet/btcwallet/btcwallet.go#L1254
Interesting why there was a second force close with too low fees.
How did you determine that it was using a different tx? I think the change in behavior here is that we'll now check to see if something can actually enter the mempool or not before broadcasting. In this case though, I think we want a bypass here to just attempt to publish anyway, as if we get that initial attempt, then we'll continue to rebroadcast in the background.
How did you determine that it was using a different tx? I think the change in behavior here is that we'll now check to see if something can actually enter the mempool or not before broadcasting. In this case though, I think we want a bypass here to just attempt to publish anyway, as if we get that initial attempt, then we'll continue to rebroadcast in the background.
the close TX was already broadcasted and visible on block explorers
Was this a case of doing a co-op close, then also doing a force close while that was unconfirmed? Otherwise, there's no way that lnd
can broadcast two different force close transactions (txid
) unless an accidental breach occurred...
Background
I experienced a peculiar issue with LND v0.18 where after I restarted the node, LND attempts to rebroadcast a force close TX for a channel that is already in the process of being force closed, using a different tx.
Channel point in question is redacted.
I was able to resume operations with use of
abandonchannel
.chantools
assisted in recovery of funds in question.Potentially related to v0.18 sweeper changes?
Your environment
lnd
v0.18.0-betabitcoind
v24.0.1