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

splice: Add field to DB to track if we’ve sent sigs

Public commit record

What the developer wrote

Authored by Dusty Daemon

78/100 · Adequate
splice: Add field to DB to track if we’ve sent sigs

We used to use a check on the active psbt to see if our splice signature was in it — but now we need to generate the signature early.

So we have to add a field tracking if we’ve sent it and add it to the database, wire protocols, and inflight objects.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds a new bookkeeping flag, 'i_sent_sigs', to track whether a splice signature has already been sent. It changes how the node decides that question: previously it inspected the active PSBT, but now it records the fact explicitly in memory, wire messages, and the wallet database. The change is described as a refactor to support generating splice signatures earlier. There is no direct evidence in the commit of a security vulnerability, but any mismatch in this flag could in principle cause a node to send signatures twice, omit them, or resume a splice incorrectly after a restart.

Recommended action

Treat as a normal correctness/state-integrity change. Review follow-up commits that actually set i_sent_sigs to true and consume it during reconnection or retransmission, because the security-relevant behavior depends on how that flag is used. No immediate patch or incident response is indicated by this commit alone.

Security signals we found

01

State-machine flag added to prevent duplicate or missing signature events during splice negotiation

02

Database migration added to persist signature-sent state across restarts

03

Wire protocol and struct changes extend trusted internal IPC only, not a public network protocol

04

No input validation, bounds, or cryptographic changes visible in the diff

05

No explicit bug fix, CVE reference, or security disclosure in commit message

Risk score

Why this scored 24/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 5/15
Confidence 4/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.