Wallet is Berkeley DB only — descriptor + SQLite wallets would retire the db-4.8.30 build ritual #41

New issue

Open

opened 2026-09-15 01:51:25 +00:00 by btcbob · 1 comment

btcbob commented

2026-09-15 01:51:25 +00:00

Owner

Roadmap section 4 (forum topic 24, msg 67), filed so it is tracked rather than prose.

Where we are

The wallet is CWalletDB over Berkeley DB and nothing else. src/db.cpp +
src/walletdb.cpp; configure.ac:522 checks for libdb_cxx whenever the wallet
is enabled. There is no SQLite backend anywhere in the tree — the only sqlite
hits under src/ are LevelDB's own benchmark files.

The cost is documented in our own build instructions: doc/build-unix.md:155
tells the builder to fetch db-4.8.30.NC.tar.gz from Oracle and compile it
statically, because a distro BDB will produce a wallet other builds cannot open.
That single dependency is the most fragile part of building (BOB).

What Core did

HD + multiwallet (0.15)
Descriptor wallets (0.17 → 0.21)
PSBT (0.17)
SQLite as the descriptor-wallet backend, default from 0.23
migratewallet legacy → descriptor (0.24)

The storage change is the one that matters here: descriptor wallets on SQLite mean
BDB exists only to open historical wallet.dat files, and a build that does not
need to open them does not need BDB at all.

Why this is separable

This has no consensus surface. It does not depend on the SegWit question in
section 3, and legacy descriptors work fine on a chain with no witness structure.
It can proceed on its own track at any time.

The real decision

Not whether, but what happens to existing wallet.dat holders. Options:

Ship both backends for a transition window, with migratewallet.
Ship SQLite only and provide a one-way migration tool built against BDB.
Leave the wallet alone and accept the build dependency indefinitely.

Nothing in this issue proposes one. The point of filing is that the BDB ritual is
a recurring tax on every build and every new contributor, and it is currently
nobody's task.

Note

Any wallet-storage work should first make the encrypt-wallet round-trip test
runnable. It needs db_dump from the BDB build, and a BDB compiled only for
linking does not provide it. That test is the one gate that would catch a
wallet-format regression, and it is currently easy to skip.

Roadmap section 4 (forum topic 24, msg 67), filed so it is tracked rather than prose. ### Where we are The wallet is `CWalletDB` over Berkeley DB and nothing else. `src/db.cpp` + `src/walletdb.cpp`; `configure.ac:522` checks for `libdb_cxx` whenever the wallet is enabled. There is no SQLite backend anywhere in the tree — the only `sqlite` hits under `src/` are LevelDB's own benchmark files. The cost is documented in our own build instructions: `doc/build-unix.md:155` tells the builder to fetch `db-4.8.30.NC.tar.gz` from Oracle and compile it statically, because a distro BDB will produce a wallet other builds cannot open. That single dependency is the most fragile part of building (BOB). ### What Core did - HD + multiwallet (0.15) - **Descriptor wallets** (0.17 → 0.21) - PSBT (0.17) - **SQLite as the descriptor-wallet backend**, default from 0.23 - `migratewallet` legacy → descriptor (0.24) The storage change is the one that matters here: descriptor wallets on SQLite mean BDB exists only to open historical `wallet.dat` files, and a build that does not need to open them does not need BDB at all. ### Why this is separable This has no consensus surface. It does not depend on the SegWit question in section 3, and legacy descriptors work fine on a chain with no witness structure. It can proceed on its own track at any time. ### The real decision Not whether, but what happens to existing `wallet.dat` holders. Options: 1. Ship both backends for a transition window, with `migratewallet`. 2. Ship SQLite only and provide a one-way migration tool built against BDB. 3. Leave the wallet alone and accept the build dependency indefinitely. Nothing in this issue proposes one. The point of filing is that the BDB ritual is a recurring tax on every build and every new contributor, and it is currently nobody's task. ### Note Any wallet-storage work should first make the encrypt-wallet round-trip test runnable. It needs `db_dump` from the BDB build, and a BDB compiled only for linking does not provide it. That test is the one gate that would catch a wallet-format regression, and it is currently easy to skip.

btcbob referenced this issue

2026-09-18 23:48:26 +00:00

Retire the db-4.8.30 build dependency without porting descriptor wallets #44

btcbob commented

2026-09-18 23:48:26 +00:00

Author

Owner

Recon before starting this, because the two halves are very different sizes.

The descriptor half is a port of Core 0.15 through 0.24 into a tree with no HD, no descriptor and no
PSBT code at all. The build-dependency half does not require it: CWalletDB is the only subclass of
CDB, CDB already reads and writes byte blobs, and BDB leaks outside db.cpp/db.h in three
places only (Dbc* cursors at 3 sites in walletdb.cpp, Dbt at 2, and a version string in
init.cpp and qt/rpcconsole.cpp).

Filed as its own issue so the chore is not blocked behind the rewrite. This one keeps the descriptor
question.

One correction: the closing Note above is out of date. db_dump is available from a BDB built with
its utilities, and the encrypt-wallet round trip ran twice as a release gate for v0.13.8, so that
prerequisite is already met.

Recon before starting this, because the two halves are very different sizes. The descriptor half is a port of Core 0.15 through 0.24 into a tree with no HD, no descriptor and no PSBT code at all. The build-dependency half does not require it: `CWalletDB` is the only subclass of `CDB`, `CDB` already reads and writes byte blobs, and BDB leaks outside `db.cpp`/`db.h` in three places only (`Dbc*` cursors at 3 sites in `walletdb.cpp`, `Dbt` at 2, and a version string in `init.cpp` and `qt/rpcconsole.cpp`). Filed as its own issue so the chore is not blocked behind the rewrite. This one keeps the descriptor question. One correction: the closing Note above is out of date. `db_dump` is available from a BDB built with its utilities, and the encrypt-wallet round trip ran twice as a release gate for v0.13.8, so that prerequisite is already met.

btcbob referenced this issue from a commit

2026-09-23 13:53:17 +00:00

wallet: keep wallet.dat in SQLite, not Berkeley DB (#44)

btcbob referenced this issue from a commit

2026-09-23 13:53:17 +00:00

test: SQLite wallet store and the v0.13.8 wallet migration (#44)

btcbob referenced this issue

2026-09-30 00:16:48 +00:00

Wallet: no way to remove a private key (add removeprivkey, and signmessagewithprivkey) #46

btcbob referenced this issue

2026-09-30 02:25:38 +00:00

Wallet: no way to remove a private key (add removeprivkey, and signmessagewithprivkey) #46