Update channel_reestablish for splicing
#3886
Conversation
|
🎉 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.
|
🔔 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 <wilmer@wilmerpaulino.com>
Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>
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. |
|
🔔 3rd Reminder Hey @wpaulino! This PR has been waiting for your review. |
|
🔔 4th Reminder Hey @wpaulino! This PR has been waiting for your review. |
|
🔔 5th Reminder Hey @wpaulino! This PR has been waiting for your review. |
|
🔔 6th Reminder Hey @wpaulino! This PR has been waiting for your review. |
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.