AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 35 Bitcoin

Stop persisting QuiescentAction and remove legacy code

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

73/100 · Adequate
Stop persisting QuiescentAction and remove legacy code

Now that the Splice variant (containing non-serializable
FundingContribution) is the only variant produced, and the previous
commit consumes the acceptor's quiescent_action in splice_init(),
there is no longer a need to persist it. This allows removing
LegacySplice, SpliceInstructions, ChangeStrategy, and related code
paths including calculate_change_output, calculate_change_output_value,
and the legacy send_splice_init method.

With ChangeStrategy removed, the only remaining path in
calculate_change_output was FromCoinSelection which always returned
Ok(None), making it dead code. The into_interactive_tx_constructor
method is simplified accordingly, and the signer_provider parameter
is removed from it and from splice_init/splice_ack since it was only
needed for the removed change output calculation.

On deserialization, quiescent_action (TLV 65) is still read for
backwards compatibility but discarded, and the awaiting_quiescence
channel state flag is cleared since it cannot be acted upon without
a quiescent_action.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit removes old, no-longer-used code paths for splicing (a way to resize a Lightning channel). It stops saving a 'quiescent action' to disk because the only remaining variant cannot be serialized, and it drops legacy change-output calculation logic. On loading old data, the stored action is read and then discarded, and the 'awaiting quiescence' flag is cleared so the node does not get stuck waiting for something it can no longer act upon. The change is mostly cleanup and hardening against stale persisted state.

Recommended action

Review the backwards-compatibility path to confirm that discarding TLV 65 and clearing awaiting_quiescence cannot leave a channel in an inconsistent or exploitable state after an upgrade from 0.2. Ensure tests cover upgrade scenarios where a LegacySplice or persisted Splice quiescent_action existed. No immediate patch is indicated beyond normal review and regression testing.

Security signals we found

01

Removal of persisted state that could not be serialized (FundingContribution inside QuiescentAction::Splice)

02

Clearing awaiting_quiescence flag on deserialization to prevent a channel from being stuck in an unactionable quiescent state

03

Backwards-compatible deserialization that discards obsolete TLV 65 data

04

Dead-code elimination in funding transaction construction paths

05

Reduction of API surface around signer_provider in splice flow

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 7/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.