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

Merge bitcoin/bitcoin#32895: wallet: Prepare for future upgrades by recording versions of last client to open and decrypt

Public commit record

What the developer wrote

Authored by merge-script

81/100 · Strong
Merge bitcoin/bitcoin#32895: wallet: Prepare for future upgrades by recording versions of last client to open and decrypt

7b32155458cc87e50da1fa9f245cc84bc203f25a wallet: Set last opened and decrypted features during migration (Ava Chow)
f998a740fc9f56c813973155cef44c757f1955dd wallet: Record the supported features of the last client to decrypt a wallet (Ava Chow)
8453ad801b63ec92af1652cdcf801165c59f2ab2 wallet: Introduce LastClientFeatures flags and LAST_OPENED_FEATURES record (Ava Chow)
0f104733cc8e4b1736efa6a3bc92a8e3dba1a1b3 walletdb: Decouple last client record from CLIENT_VERSION (Ava Chow)

Pull request description:

When a wallet is automatically upgraded, we always do so in a way that allows the user to load their wallet in an older version. When the user loads their wallet into an upgraded version again, the wallet may not perform the automatic upgrade and end up with upgraded and non-upgraded material in the wallet.

If we write some information about the last client to open the wallet, we would be able to detect these upgrade-downgrade-upgrade situations and perform another upgrade if so. However, in order for this to work, we need to have implemented writing such information into versions prior to the ones which introduce new automatic upgrades.

We are already writing the CLIENT_VERSION into all wallets in a "version" record, although this record is not updated in the same way across all previous versions. Since v24.0, we are always updating the record when the client version differs, but prior to that, the record would only be updated when the client version is newer. Even so, we can use this record to store the last client version.

The first commit decouples the written client version from the node version. This aids in development of new features. The version is entirely decoupled from previous versions by requiring all versions to have bit 19 set, and the initial version being `0 | (1 << 19)`. The versions just need to be at least 299900, and forcing bit 19 to be set was an easy way to achieve this.

However, using version numbers is not as flexible as feature flags, so the second commit introduces the concept of Wallet Client Features. These flags are distinct from the existing Wallet Feature Flags since they are conceptually different. These are written in a separate record, and the wallet client version is incremented to `(1 << 19) + 1`.

Lastly, since some upgrades may need private keys and can only occur after the wallet is decrypted, the third commit also adds a last decrypted features flags record to record the features of the last client to decrypt the wallet.

The result is that we will now be able to detect a downgrade down to v24.0 and be able to implement in parallel multiple features that require automatic upgrades.

ACKs for top commit:
polespinasa:
ACK 7b32155458cc87e50da1fa9f245cc84bc203f25a
w0xlt:
reACK 7b32155458cc87e50da1fa9f245cc84bc203f25a

Tree-SHA512: 7d619e24e06a48162950bd153e12ae9fe05454ca8422e7f3d185b1b8ac2506ead6c1bc094da0b1182aceffe3cf198b948335b676f383ce88f4f9e0ae78beca61
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change is a wallet infrastructure improvement, not a fix for an active security bug. It records which Bitcoin Core version and feature set last opened or decrypted a wallet so that future releases can detect 'upgrade-downgrade-upgrade' cycles and re-run automatic wallet upgrades safely. There is no direct exploit here, but any bug in this bookkeeping could in theory cause a wallet to skip needed upgrades or behave unexpectedly after being loaded in older software.

Recommended action

Review the new version/feature bookkeeping for correctness and edge cases (e.g., partial writes, migration failures, encrypted wallets that are never unlocked). Monitor follow-up PRs that will rely on these records to trigger automatic upgrades, since the actual security relevance depends on those future changes.

Security signals we found

01

New wallet database records for tracking last client version/features

02

Decoupling of wallet version metadata from node CLIENT_VERSION

03

Erase of stale decryption-features record on downgrade detection

04

Feature flags introduced to drive future automatic wallet upgrades

05

No patch of an existing vulnerability; preparatory change for future upgrades

Risk score

Why this scored 19/100

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