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

Persist witnesses in InteractiveTxSigningSession

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

58/100 · Thin
Persist witnesses in InteractiveTxSigningSession

InteractiveTxSigningSession currently persists holder witnesses
directly, but persists counterparty witnesses as part of its unsigned
ConstructedTransaction. This makes the ConstructedTransaction actually
partially signed even though it is held in a field named unsigned_tx.
Instead, persists the counterparty witnesses alongside the holder
witnesses directly in InteractiveTxSigningSession, leaving the
transaction it holds unsigned.
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a code-quality and correctness fix in rust-lightning's interactive transaction signing. It changes how counterparty (remote) signatures are stored during a Lightning channel funding flow. Previously, counterparty signatures were immediately added to a data structure named 'unsigned_tx', meaning that structure was no longer truly unsigned. Now, both sides' signatures are kept separately in the signing session and only combined into the final transaction at the last moment. The commit does not describe a security vulnerability, and there is no direct evidence it fixes an exploitable bug, but it removes a confusing state where sensitive signature data was stored inside a supposedly unsigned transaction object.

Recommended action

Treat as a correctness and defensive-hardening patch. Reviewers should verify that the new finalize() path correctly handles all shared-input signature ordering cases and that serialization backward compatibility is preserved or intentionally changed. No urgent security response is indicated by the available evidence, but the patch should be included in normal updates because it reduces the risk of state confusion around partially-signed transactions.

Security signals we found

01

Refactor of sensitive signature storage in interactive transaction signing session

02

Previously 'unsigned_tx' field contained counterparty witnesses, making it partially signed despite its name

03

Now both holder and counterparty signatures are stored separately and combined only on finalization

04

No explicit security bug or CVE mentioned in commit message or diff

05

Change touches serialization format (TLV fields) of signing session state

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.