-
Notifications
You must be signed in to change notification settings - Fork 406
force close is not always broadcasting latest TX #3155
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
Comments
FWIW, we saw similar flaky behavior in LDK Node's integration tests. I might be wrong, but I suspect this could be a race with |
This is not a guarantee -
Hmm, this event order does somewhat surprise me, however. Are you sure you're seeing this on the same node's
That shouldn't impact this. That change only impacts persists based on block-connection, but here we're (I think?) just talking about persists due to channel state changes, and specifically when the |
Got it, thanks for the explanation. So I guess in our tests we should keep a small sleep to be sure the force close operation will always broadcast the latest commitment TX.
I confirm the fork is based on LDK 0.0.123, but nice catch, I wasn't checking which node was printing the change to |
I'm using RLN, which uses a forked version of rust-lightning, where I've added support for RGB. I'm running an integration test (https://github.com/RGB-Tools/rgb-lightning-node/blob/master/src/test/close_force_standard.rs) where I open a channel between 2 nodes, make 2 payments via keysend and force close the channel.
After the channel closure I sometimes see a behavior (non-deterministic, but quite frequent) where the
BumpTransactionEventHandler
tries to bump the fees for an HTLC TX (we are using anchor outputs). This is strange because before closing the channel, during the keysend, we wait for the payment to become successful (which happens during thePaymentSent
andPaymentClaimed
events), therefore we expect the channel to have no pending HTLCs and the node to broadcast the last commiment TX.I'm writing here first of all to understand if you think this is expected behavior or not. That is, waiting for the mentioned events should guarantee that the
OnchainTxHandler
will broadcast the last valid commitment TX?I've also collected some logs, hoping this could help better understand the issue:
provide_latest_holder_tx
that sets theholder_commitment
field to the latest commitment TX (the one we expect to be broadcasted, with no HTLCs)channel_manager.force_close_broadcasting_latest_txn
happens after theholder_commitment
is set to the expected commitment TXself.holder_commitment
inget_maybe_signed_holder_tx
I see the TX is not the expected one but it's the previous commitment TX (the one with 1 HTLC) insteadI don't think that our changes to support RGB could cause this issue. If you think this part is well-tested on your side I'll investigate more and maybe try to reproduce it on a vanilla node.
The text was updated successfully, but these errors were encountered: