Fix invalid_commit_sig issue when expecting tx_signatures
#536
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Extract the faulty lightning message or watch event.
If our peer asks us to retransmit our `tx_signatures`, we should do it even if the transaction is already confirmed.
When expecting a retransmission of `tx_signatures`, we should ignore the `commit_sig` they send just before if we've already received it. The right way to check that we've already received it is to compare its signature to our latest commitment transaction.
t-bast
commented
Sep 22, 2023
pm47
previously approved these changes
Sep 22, 2023
src/commonMain/kotlin/fr/acinq/lightning/channel/states/Normal.kt
Outdated
Show resolved
Hide resolved
pm47
approved these changes
Sep 22, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If we disconnect before receiving our peer's
tx_signatures, we expect them to re-send it on reconnection (by filling thenext_funding_txidfield inchannel_reestablish). In that case, our peer may also retransmit their correspondingcommit_sigfirst (if they cannot be sure that we've received it). If we've already received thatcommit_sig, we should ignore it. But we must make sure we don't end up ignoring othercommit_sigmessages!Eclair wasn't spec-compliant and wouldn't retransmit their
tx_signaturesif the transaction was already confirmed. We need to fix this on the eclair side (PR incoming). The issue is thatlightning-kmpended up ignoring unrelatedcommit_sigmessages, which could eventually lead to aninvalid_commit_sigerror and a force-close.