Update channel_reestablish for splicing
#3886
Conversation
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
|
🔔 1st Reminder Hey @wpaulino! This PR has been waiting for your review. |
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
2 times, most recently
from
06c0dfc to
f000b76
Compare
|
@wpaulino Ready for review now. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #3886 +/- ##
========================================
Coverage 88.74% 88.74%
========================================
Files 176 176
Lines 128845 129485 +640
Branches 128845 129485 +640
========================================
+ Hits 114340 114912 +572
- Misses 11912 11962 +50
- Partials 2593 2611 +18
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ 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. |
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
from
f000b76 to
e2ea3bf
Compare
|
Rebased. |
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
from
e2ea3bf to
69be701
Compare
There was a problem hiding this comment.
We may need to double check our incoming
channel_readyhandling to make sure we can handle receiving one long afterchannel_readywas already exchanged due to the new logic surroundingyour_last_funding_locked_txid.
ACK. Also need to address https://github.com/lightningdevkit/rust-lightning/pull/3736/files#r2133028859.
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
2 times, most recently
from
f7b9785 to
b0291f4
Compare
Latest push adds some commits to address this. |
Looks like we have some logic below. I think the catch-all case still holds? We should only receive a rust-lightning/lightning/src/ln/channel.rs Lines 6491 to 6519 in 42085b9 |
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.
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.
During channel reestablishment, both commitment_signed and tx_signatures messages may be retransmitted. However, commitment_signed must come first, so re-arrange the ordering. This moves tx_abort as well to keep the interactive tx messages together.
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
from
dc7379d to
cce9421
Compare
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
from
cce9421 to
845360b
Compare
lightning/src/ln/channel.rs
Outdated
| }) | ||
| } else if msg.next_local_commitment_number == next_counterparty_commitment_number - 1 { | ||
| debug_assert!(commitment_update.is_none()); | ||
| debug_assert!(tx_signatures.is_none()); |
There was a problem hiding this comment.
I believe this is reachable if a counterparty sends a bogus message? If we're just trying to test for it we should #[cfg(test)] it, in general we try to avoid reachable debug_asserts as well.
There was a problem hiding this comment.
Yeah, see #3886 (comment)
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
from
845360b to
27f70b0
Compare
lightning/src/ln/channel.rs
Outdated
| @@ -8705,6 +8710,15 @@ where | |||
| } | |||
| } | |||
|
|
|||
| // FIXME: Is this correct? | |||
There was a problem hiding this comment.
Looks right to me. Once we fix #4036 basically we can assume we're connected to the peer and in normal operation, which means an interactive signing session or awaiting-ready implies if we're sending a CS its an initial one, and otherwise we want to make sure we get our ready out first. Probably good to leave a comment describing that reasoning.
There was a problem hiding this comment.
Replaced the FIXME accordingly.
lightning/src/ln/channel.rs
Outdated
| data: | ||
| "No active signing session. The associated funding transaction may have already been broadcast.".as_bytes().to_vec() })) | ||
| } | ||
| let channel_ready_order = if commitment_update.is_some() || tx_signatures.is_some() { |
There was a problem hiding this comment.
If we're not sending any signatures does it matter? Can we not just always set SignaturesFirst?
There was a problem hiding this comment.
Done. Also, pulled out a new commit introducing ChannelReadyOrder since it's applicable for v2 channel establishment. Addressed this comment there.
| shutdown_msg, announcement_sigs, | ||
| tx_signatures: None, | ||
| tx_signatures, |
There was a problem hiding this comment.
We shouldn't send tx_signatures if is_monitor_update_in_progress, right? Probably need to check it in the interactive signing session stuff above, but also here cause we're specifically in a block because of it sometimes.
There was a problem hiding this comment.
Introduced a separate commit for the interactive signing session case since that preexist this PR. No additional logic is needed here since tx_signatures is initialized there.
|
🔔 1st Reminder Hey @wpaulino! This PR has been waiting for your review. |
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
from
27f70b0 to
51406e6
Compare
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
|
🔔 2nd Reminder Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review. |
When handling channel_reestablish, the order in which channel_ready is sent depends on whether or not the initial commitment_signed / tx_signatures are being retransmitted. When they are, then channel_ready should come after them. Otherwise, channel_ready should come before any commitment_signed.
The ChannelMonitor must be successfully persisted before transmitting any messages.
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.
Note that the spec is in flux. Instead, next_funding_txid is replaced
with next_funding, which contains both a txid and retransmit_flags. The
latter is used instead of next_commitment_number to determine whether
commitment_signed should be retransmitted.
This commit updates FundedChannel::channel_reestablish accordingly.
Co-authored-by: Wilmer Paulino <wilmer@wilmerpaulino.com>
Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>
During channel_reestablish handling, next_local_commitment_number can never be zero. Remove the unnecessary check conditioning on next_funding not being set. Additionally, remove the spec requirement in the comment that follows since it does not exist.
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.
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.
During channel reestablishment, announcement_signatures may need to be retransmitted. The splicing spec allows doing so without retransmitting splice_locked first, which could normally trigger retransmitting announcement_signatures. Instead, my_current_funding_locked lets the sender request retransmitting it.
The previous commit allowed requesting retransmission of announcement_signatures during channel reestablishment. This commit handles such requests.
jkczyz
force-pushed
the
2025-06-channel-reestablish
branch
from
51406e6 to
a3a3a55
Compare
| // signatures should be sent before channel_ready. | ||
| let channel_ready_order = if self.interactive_tx_signing_session.is_some() { | ||
| ChannelReadyOrder::SignaturesFirst | ||
| } else if matches!(self.context.channel_state, ChannelState::AwaitingChannelReady(_)) { |
There was a problem hiding this comment.
Do we actually need to check this? We keep the signing session around until we receive channel_ready.
lightning/src/ln/channel.rs
Outdated
| @@ -9289,6 +9289,9 @@ where | |||
| if session.holder_tx_signatures().is_none() { | |||
| log_debug!(logger, "Waiting for funding transaction signatures to be provided"); | |||
| None | |||
| } else if self.context.channel_state.is_monitor_update_in_progress() { | |||
There was a problem hiding this comment.
This shouldn't be necessary since the signing event isn't given to the user until after the monitor update completes.
| ChannelError::Close( | ||
| ( | ||
| message.clone(), | ||
| ClosureReason::HolderForceClosed { message, broadcasted_latest_txn: Some(false) }, |
There was a problem hiding this comment.
Should be ClosureReason::ProcessingError
| ChannelError::Close( | ||
| ( | ||
| message.clone(), | ||
| ClosureReason::HolderForceClosed { message, broadcasted_latest_txn: Some(false) }, |
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.