Update channel_reestablish for splicing
#3886
Open
+446
−98
Conversation
This file contains hidden or 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
|
🎉 This PR is now ready for review! |
While splicing is not yet fully supported, checking if the feature has been negotiated is needed for changes to the channel_reestablish logic.
The splicing spec extends the channel_reestablish message with two more TLVs indicating which funding txid the sender has sent/received either explicitly via splice_locked or implicitly via channel_ready. This allows peers to detect if a splice_locked was lost during disconnection and must be retransmitted. This commit updates channel_reestablish with the TLVs. Subsequent commits will implement the spec requirements.
7 tasks
|
🔔 1st Reminder Hey @wpaulino! This PR has been waiting for your review. |
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
from
c079677 to
06c0dfc
Compare
The previous commit extended the channel_reestablish message with your_last_funding_locked_txid and my_current_funding_locked_txid for use as described there. This commit sets those fields to the funding txid most recently sent/received accordingly.
When splicing is negotiated, channel_ready must be retransmitted when your_last_funding_locked is not set. Further, the current logic for retransmitting channel_ready is only applicable when splicing is not negotiated.
The splicing spec updates the logic pertaining to next_funding_txid when
handling a channel_reestablish message. Specifically:
A receiving node:
- if `next_funding_txid` is set:
- if `next_funding_txid` matches the latest interactive funding transaction
or the current channel funding transaction:
- if `next_commitment_number` is equal to the commitment number of the
`commitment_signed` message it sent for this funding transaction:
- MUST retransmit its `commitment_signed` for that funding transaction.
- if it has already received `commitment_signed` and it should sign first,
as specified in the [`tx_signatures` requirements](#the-tx_signatures-message):
- MUST send its `tx_signatures` for that funding transaction.
- if it has already received `tx_signatures` for that funding transaction:
- MUST send its `tx_signatures` for that funding transaction.
- if it also sets `next_funding_txid` in its own `channel_reestablish`, but the
values don't match:
- MUST send an `error` and fail the channel.
- otherwise:
- MUST send `tx_abort` to let the sending node know that they can forget
this funding transaction.
This commit updates FundedChannel::channel_reestablish accordingly.
Co-authored-by: Wilmer Paulino <[email protected]>
Co-authored-by: Jeffrey Czyz <[email protected]>
The splicing spec updates the logic pertaining to next_commitment_number
when sending a channel_reestablish message. Specifically:
The sending node:
- if it has sent `commitment_signed` for an interactive transaction construction but
it has not received `tx_signatures`:
- MUST set `next_funding_txid` to the txid of that interactive transaction.
- if it has not received `commitment_signed` for that interactive transaction:
- MUST set `next_commitment_number` to the commitment number of the `commitment_signed` it sent.
The channel_reestablish protocol supports retransmitting splice_locked messages as needed. Add support for doing such when handling channel_reestablish messages.
The splicing spec updates channel_establishment logic to retransmit
channel_ready or splice_locked for announced channels. Specifically:
- if `my_current_funding_locked` is included:
- if `announce_channel` is set for this channel:
- if it has not received `announcement_signatures` for that transaction:
- MUST retransmit `channel_ready` or `splice_locked` after exchanging `channel_reestablish`.
When a splice transaction is promoted (i.e., when splice_locked has been exchanged), announcement_signatures must be sent. However, if we try to send a channel_announcement before they are received, then the signatures will be incorrect. To avoid this, clear the counterparty's announcement_signatures upon promoting a FundingScope.
The channel_reestablish protocol supports retransmitting channel_ready messages as needed. Add support for doing such when handling channel_reestablish messages.
When handling a counterparties channel_reestablish, the spec dictates that a splice_locked may be implied by my_current_funding_locked. Compare that against any pending splices and handle an implicit splice_locked message when applicable.
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
from
06c0dfc to
f000b76
Compare
|
@wpaulino Ready for review now. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3886 +/- ##
==========================================
- Coverage 89.66% 89.42% -0.24%
==========================================
Files 164 165 +1
Lines 134661 126319 -8342
Branches 134661 126319 -8342
==========================================
- Hits 120743 112967 -7776
+ Misses 11237 10971 -266
+ Partials 2681 2381 -300 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
🔔 2nd Reminder Hey @wpaulino! This PR has been waiting for your review. |
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.
The splicing spec extends the
channel_reestablishmessage with two more TLVs indicating which funding txid the sender has sent/received either explicitly viasplice_lockedor implicitly viachannel_ready. This allows peers to detect if asplice_lockedwas lost during disconnection and must be retransmitted.To this end, the spec updates the
channel_reestablishlogic to support splicing.