CLN continues trying to RBF an OUR_DELAYED_RETURN_TO_WALLET even after "All outputs resolved"
#7788
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue and Steps to Reproduce
I had a channel that CLN had force-closed due to an HTLC timeout due to the peer's being unreachable for a prolonged time. CLN faithfully tracked the
DELAYED_OUTPUT_TO_USoutput of the on-chain commitment transaction as it approached its timelock expiration, down to 1 block remaining:Once the timelock had expired, CLN began RBF attempts on its
OUR_DELAYED_RETURN_TO_WALLETtransaction:Evidently there's no logic to avoid attempting to RBF a transaction using the same transaction (a fraction of a second later):
(Odd that that message was logged at the
DEBUGlevel, whereas the previous message of identical format was logged at theINFOlevel.)What followed was a strangely urgent series of attempts to RBF the transaction with ever decreasing fees (which should be impossible):
Finally, one of the proposed replacement transactions was mined into a block:
You'll note that it was not the most recently proposed replacement (
69…c4) that was mined but rather one (26…7a) from a few iterations back.CLN tried again to RBF its claim transaction even after it had noted that the UTXO had already been spent on chain:
Subsequently it realized that its
DELAYED_OUTPUT_TO_USoutput had been resolved by itsOUR_DELAYED_RETURN_TO_WALLETproposal:However, it then continued trying to RBF its proposal, still with gradually decreasing fees:
This continued until 100 blocks had passed and CLN "forgot" the channel:
Only then did the RBF attempts cease.
getinfooutputThis was with CLN 24.08.2.
The text was updated successfully, but these errors were encountered: