What the developer wrote
Authored by Leo Nash
Make `for_splice` infallible
What changed, and why it matters
This commit changes an internal function called `for_splice` so it no longer returns an error. Previously, the function could fail and callers used `?` to propagate that failure. Now it always succeeds. The change is small and appears to be a code-cleanup step in the unfinished splicing feature, but the commit message gives no explanation of why the function was made infallible or what error conditions were removed. Without more context, it is unclear whether this removes a safety check that protected against invalid splice parameters.
Treat as a routine refactor pending further review. A reviewer should verify that all prior error conditions in `for_splice` were truly impossible (e.g., already validated by callers) and that removing the `Result` does not hide future failure modes. Ask the author for the rationale and whether any validation was moved elsewhere. No immediate security action is warranted based solely on this diff.
Security signals we found
Function made infallible without visible replacement of prior error checks
Callers no longer propagate ChannelError from splice funding construction
Splicing feature is marked with TODO comments and appears incomplete
No test changes or documentation included in the diff
Evidence from the diff
In lightning/src/ln/channel.rs, the FundingScope::for_splice method signature is changed from Result<Self, ChannelError> to Self, and the two call sites drop the ? operator. The function body still computes post-splice channel value, balances, reserve, and transaction parameters, but now returns the struct directly. The diff does not show any removed error checks inside for_splice; the only change is the return type and the removal of Ok(...). The callers are in splice-related message handling paths (splice_channel and splice_ack).
Changed components
lightning/src/ln/channel.rsFundingScope::for_splicesplice_channel message handlersplice_ack message handlerInspect captured patch +5 / −5
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 0dbbf6a..031929e 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -2255,7 +2255,7 @@ impl FundingScope {
fn for_splice<SP: Deref>(
prev_funding: &Self, context: &ChannelContext<SP>, our_funding_contribution: SignedAmount,
their_funding_contribution: SignedAmount, counterparty_funding_pubkey: PublicKey,
- ) -> Result<Self, ChannelError>
+ ) -> Self
where
SP::Target: SignerProvider,
{
@@ -2305,7 +2305,7 @@ impl FundingScope {
let holder_selected_channel_reserve_satoshis =
get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS);
- Ok(Self {
+ Self {
channel_transaction_parameters: post_channel_transaction_parameters,
value_to_self_msat: post_value_to_self_msat,
funding_transaction: None,
@@ -2329,7 +2329,7 @@ impl FundingScope {
funding_tx_confirmed_in: None,
minimum_depth_override: None,
short_channel_id: None,
- })
+ }
}
/// Compute the post-splice channel value from each counterparty's contributions.
@@ -11312,7 +11312,7 @@ where
our_funding_contribution,
their_funding_contribution,
msg.funding_pubkey,
- )?;
+ );
// TODO(splicing): Once splice acceptor can contribute, check that inputs are sufficient,
// similarly to the check in `splice_channel`.
@@ -11533,7 +11533,7 @@ where
our_funding_contribution,
their_funding_contribution,
msg.funding_pubkey,
- )?;
+ );
// TODO(splicing): Pre-check for reserve requirement
// (Note: It should also be checked later at tx_complete)
Why this scored 29/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.