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

wallet: Deserialize directly in CWalletTx's ctor

Public commit record

What the developer wrote

Authored by Ava Chow

80/100 · Strong
wallet: Deserialize directly in CWalletTx's ctor

When loading a transaction, instead of constructing a CWalletTx with no
transaction, pass the DataStream into the constructor so that the
CWalletTx is RAII. This allows us to ensure that the transaction is
never a nullptr so that dereferences, especially once multiple txs are
stored, will not cause a segfault.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit changes how Bitcoin Core wallet transactions are loaded from disk or copied between wallets. Previously, a wallet transaction object could be created with no actual transaction inside it, and later filled in. The patch makes the transaction data mandatory from the start using a constructor that deserializes directly from a data stream. The stated goal is to prevent crashes (segfaults) caused by accidentally using a null transaction pointer, especially as more transaction types are stored in the wallet. It also improves error handling for corrupt wallet records.

Recommended action

This is a defensive hardening change. Users and downstream maintainers should treat it as a routine bug-fix/hardening patch. No immediate emergency action is required. Wallet operators should ensure they run a version containing this patch, especially if loading wallets with mixed or new transaction types. If a wallet previously triggered crashes on load, this patch may help; if loading now reports corruption, follow the suggested rescan/removal procedure.

Security signals we found

01

Null-pointer dereference prevention: CWalletTx transaction member is now guaranteed non-null at construction via Assert(tx) and direct deserialization.

02

RAII-style construction: transaction object is fully initialized in constructor rather than two-phase init-then-fill.

03

Improved corruption handling: deserialization exceptions are caught and reported as DBErrors::CORRUPT.

04

Refactoring of LoadToWallet to remove callback-based filling, reducing window where object is partially constructed.

05

Serialization round-trip used for copying wallet transactions between wallets during export and migration.

Risk score

Why this scored 45/100

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