Bitcoin Core 28.4: Why Wallet Fixes Matter in Production

Bitcoin Core 28.4 wallet migration fixes are the kind of release work service operators should care about more than headline chasers do. Version 28.4 shipped on March 18 as a stable maintenance release with official downloads and release notes, and its main value is operational: it closes wallet migration failure paths and removes a DNS seed the project no longer trusted.

Bitcoin Core 28.4 changes a narrow set of things, and that is the point

The 28.4 release notes are short and specific. Under Wallet, Bitcoin Core lists fixes for unnamed legacy wallet migration failure, wallettool createfromdump failure that could delete the wallets directory, a relative-wallet migration cleanup test, and a backport bug fix. Under P2P, it removes dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us. The rest of the release is build and CI maintenance: a Guix osslsigncode test fix, removal of third-party JavaScript from a Windows DLL GitHub Actions job, updated GitHub Actions versions, and a move to the macOS 14 CI image. This is not a feature release. It is a release aimed at keeping a mature node stack from failing in ways operators discover too late.

That framing also matches how Bitcoin Optech described it. Optech’s March 27 roundup calls 28.4 “a maintenance release for a previous major release series” of the predominant full node implementation and says it “primarily contains wallet migration fixes and removal of an unreliable DNS seed.” That is the right editorial lens. The most useful Bitcoin infrastructure updates are often the ones that narrow failure domains without changing how users think the software works.

Bitcoin Optech’s release roundup

Wallet migration bugs are not edge-case trivia for services

The wallet fixes matter because the failure mode was destructive, not cosmetic. In the issue that led to PR #34156, a user reported migrating a legacy unnamed wallet through Bitcoin-Qt, seeing migration “complete,” and then finding not just wallet.dat gone but the entire wallet directory removed. The associated pull request explains the root cause clearly: when migration of an unnamed legacy wallet failed, cleanup logic erased the newly created descriptor-wallet directories, but because the unnamed wallet lives directly in the top-level /wallets/ folder, that cleanup path could remove the main wallet directory itself. The fix changes the behavior so only the unnamed wallet file is restored and the top-level /wallets/ directory stays intact.

The companion wallettool fix closed a similar class of risk on the CLI side. In PR #34215, Ava Chow wrote that createfromdump could also accidentally delete the entire wallets directory if the wallet name was an empty string and the dump file had a checksum error. The fix avoids fs::remove_all and narrows cleanup so named-wallet directories are removed only when appropriate. That is exactly the kind of “boring” change operators want in a maintenance train: cleanup code that stops behaving like a recursive delete in the wrong edge case.

PR #34215 on createfromdump cleanup

This is also not abstract history. On January 5, Bitcoin Core published an advisory saying a wallet migration bug in 30.0 and 30.1 could, under rare circumstances, delete all files in the wallet directory and potentially cause loss of funds, and it removed binaries for those affected releases from bitcoincore.org until 30.2 was available. That advisory concerned 30.x, not 28.4 directly, but it shows why migration-path bugs deserve operator attention out of proportion to how small they look in release notes.

January 2026 wallet migration advisory

Bitcoin infrastructure coverage→ /categories/crypto-newswire

Removing an unreliable DNS seed is network hygiene, not housekeeping

The P2P change in 28.4 is only one line in the release notes, but it reflects a trust decision about node discovery. Bitcoin Core removed dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us, and the issue discussing that seed says there were concerns about the operator’s control of the server after a reported compromise, uncertainty about who had access, and allegations that the seed was filtering nodes by user agent rather than fairly returning functioning public Bitcoin nodes. The issue quotes the project’s DNS seed policy, which expects good host security practices and fairly selected functioning nodes from the public network.

That matters because DNS seeding is a bootstrap dependency. A bad seed does not rewrite consensus, but it can degrade first contact with the network, skew peer discovery, or inject reliability and policy problems right at the start of node operation. For service builders who run autoscaling nodes, ephemeral environments, or scripted deployments, bootstrap quality is part of uptime. Removing a seed that the project no longer considered reliable is a small but meaningful reduction in operational ambiguity. It says the maintainers were willing to prune infrastructure dependencies that no longer met project policy instead of carrying them forward for convenience.

node bootstrap reliability→ /news/node-bootstrap-reliability

Stable release discipline still shows up in how 28.4 is shipped

Bitcoin Core’s release process is not framed around “audit passed” language on a release page. It is framed around documented release notes, official binaries and source, upgrade instructions, and reproducible-build attestations. The March 18 release announcement says version 28.4 is available for download and points users to the release notes. The 28.4 notes include the upgrade path, including support for direct upgrades from older versions that may require data-directory migration. On the verification side, the bitcoin-core/guix.sigs repository contains attestations for 28.4 and explains that all.SHA256SUMS covers the binaries uploaded to the website for a given version.

That does not make 28.4 a dramatic release. It makes it production software shipped the way operators expect Bitcoin Core to ship stable maintenance updates. The release credits list nine direct contributors, which is a reminder that even small maintenance lines are not one-person affairs.

Bitcoin Core 28.4 release notes

Guix release attestations

What node operators and wallet builders should do with 28.4

For operators pinned to the 28.x series, 28.4 is the sort of release that should move through normal staging rather than sit in backlog. Teams that still carry older unnamed legacy wallet states, support migrations in user-facing workflows, or use wallettool createfromdump should treat this as risk reduction for failure handling, not as optional cleanup. The most relevant operational question is not “does 28.4 add new capability?” but “does our upgrade or recovery path still contain a destructive cleanup edge case that upstream just fixed?”

Wallet and service teams should also separate this from a blanket “latest is always safest” rule. The January advisory on 30.0 and 30.1 showed that wallet migration bugs can surface even in current major lines and can be serious enough for the project to remove binaries from its own website. That is exactly why maintenance releases matter. They are the mechanism by which upstream narrows operational risk once concrete failure reports arrive.

wallet upgrade risk management/news/wallet-upgrade-risk-management

Bitcoin Core 28.4 does not change the narrative around Bitcoin scaling or policy debates. It does something quieter and more valuable for operators: it makes wallet migration and network bootstrap behavior less fragile. The next signal to watch is whether these wallet migration fixes stay contained to maintenance lines, or whether more tooling around legacy-wallet exit paths needs hardening across future stable releases.

• Bitcoin Core — Bitcoin Core 28.4 released — https://bitcoincore.org/en/2026/03/18/release-28.4/
• Bitcoin Core — Release Notes for 28.4 — https://bitcoincore.org/en/releases/28.4/