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

Set is_change only after each branch's own checks

Public commit record

What the developer wrote

Authored by kdmukai

85/100 · Strong
Set is_change only after each branch's own checks

In _parse_outputs the flag was set True as soon as the rebuilt
scriptPubKey matched, and two multisig branches then turned it back
off. That made "change" the default inside the matched arm, so a branch
that forgot the flag would record change with nothing verified behind
it. Now each branch sets the flag only once its own checks have passed,
and an output that satisfies none of them stays an external spend.

The two sites where the flag is set split by signature type, and each
carries the certainty it actually has: single sig is settled, because
our own key rebuilt the scriptPubKey; multisig is a presumption, because
our key in the committed script does not say which wallet that script
belongs to, and only the user's descriptor can. The reminder that
"change" means any output coming back to our seed moves to the line
where change_data is built, which is where the word takes that meaning.

No behavior change: the same outputs land in the same lists on every
fixture shape, and the suite is unchanged.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit fixes a logic bug in how SeedSigner decides whether a Bitcoin transaction output is 'change' coming back to the user's wallet. Previously, the code marked an output as change as soon as it looked like it paid to the user's seed, before fully checking the details. Two special cases (multisig wallets) then had to manually undo that mark. The danger was that any future code path that forgot to undo the mark could wrongly label an external payment as the user's own change, potentially tricking a user into approving a transaction that sends funds to an attacker. The patch moves the 'is_change = True' assignment so it only happens after each branch's specific safety checks have passed. The commit itself says there is no behavior change on current test fixtures, but it removes a risky default.

Recommended action

Treat this as a security-hardening fix with latent bug-fix value. Review whether any prior release shipped with the default-true behavior and assess if a user could construct a PSBT that reaches the matched arm but fails the multisig checks in a way that left is_change True before this patch. If such a path existed, consider a security advisory and patch release. Regardless, the change should be included in the next release because it removes a footgun for future code changes.

Security signals we found

01

Logic bug: default-true flag inside a conditional arm with branches responsible for undoing it

02

Potential UI deception: unverified output could be displayed as user change

03

Defensive refactor: flag set only after branch-specific verification

04

Explicit comment noting multisig change is a presumption pending descriptor verification

05

No new tests or fixtures added; commit claims no behavior change on existing fixtures

Risk score

Why this scored 59/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 8/15
Confidence 7/10
Evidence quality 4/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.