-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Outgoing Channel force closed without any HTLC on channel. #6467
Comments
This is normal behavior, there are scenarios in which lnd should close out the channel even though there are no HTLCs on our local commitment |
what are those scenarios and how can one find them easily in the logs? |
Still very coincidential that the channel force-close happened the moment a hypothetical HTLC timeout between B-C would trigger the force-close. So in the above scenario it looks like lnd was thinking it had an HTLC between B-C. It would be interesting how the HTLC circuit behaved for the incoming HTLC, so no more log information for this one ? |
no, unfortunately I do not have DEBUG setup on my lnd logs or subsystems. Today lnd only logs
|
is this HTLC small enough to be considered trimmed? |
So I think we can close this as a duplicate of #2992? |
While I had another force close today for precisely the same reason (#2992). May be a point to consider When a peer disconnects, it is marked as pending disable (to be announced as disable after Could the flow of HTLC be stopped going towards channels marked as pending disabled? This could save on ping latency and would only apply to actually "suspect" channels instead of pinging every peer on every htlc which could be performance hit. |
closing as a duplicate of #2992 |
Background
Consider A-B-C - I am B (03c5528c628681aa17ab9e117aa3ee6f06c750dfb17df758ecabcd68f1567ad8c1)
I have channel with
A = XMRK 033878501f9a4ce97dba9a6bba4e540eca46cb129a322eb98ea1749ed18ab67735
C = SWISS NATIONAL NODE 024eac466254511fc135d43ab676155c3b3a2db9c63a4a85ad8a76ad2520652ab0
Channel B-C was Force closed, without any visible HTLC waiting to the resolved on chain. The on-chain transaction
9c302a4a31adcbebb64a5bfffc5fb3d9408a0038ca0a3fad33684395f02e3926
also does not have any HTLC output spent. Just 2 anchors and 2 channel balance outputs.Details:
I record an hourly snapshot of pending HTLCs on my node so that I can trace any open HTLCs during a force close. It is a simple out put of
lncli listchannels | jq -r '.[][] | .remote_pubkey, .pending_htlcs[] ' | grep "{" -B1 -A8
to a log file.At snapshot time above, my logs showed the following HTLC from A->B
However, there was no record of corresponding OutGoing HTLC to C. The forwarding channel
767332672493912065
is B->C but in these snap shots there is no record of the HTLC pending between B->CFast forward the HTLC snapshot logs carry on until there was 21 blocks left to expiry (the snapshot is at 23 blocks)
Since my CLTV delta is 21, if A-B have 21 blocks to expiry B-C would HTC would have expired by block 733715
At block 733715, channel B-C was closed
Some more logs at block 733716
Your environment
Steps to reproduce
See above. The behaviour is weird.
Expected behaviour
If there is no HTLC pending on outgoing channel B->C it should not be force closed.
Actual behaviour
Channel B->C was force closed without any HTLC on it.
The text was updated successfully, but these errors were encountered: