Bitcoin Core 29.3 Released with Performance and Wallet Improvements | Bitcoin Index

Bitcoin Core 29.3 landed on February 11, 2026, and while it’s a maintenance release for the 29.x branch, it packs some serious fixes. If you’re still running version 29.x (or older), this update deserves your attention. It patches a wallet migration bug that could wipe out your entire wallet directory, tightens up signature validation performance, and fixes a rare but nasty mining edge case.

Yes, version 30.2 is the current major release. But maintenance branches exist for a reason. If you haven’t jumped to 30.x yet, 29.3 backports critical fixes that v30 users already have. Think of it as insurance for the cautious.

The wallet migration bug you didn’t know you needed to worry about

Here’s the headline: if you were migrating Bitcoin Core’s default “unnamed” legacy wallet and the migration failed, earlier versions could accidentally delete your entire /wallets/ directory during cleanup. Not just the broken wallet file. The whole folder.

Let me explain why this happened. Bitcoin Core has been nudging users away from the old Berkeley DB (BDB) wallet format toward descriptor wallets. Most wallets live in their own subdirectories inside /wallets/. But the default wallet, if you never named it, lives directly in /wallets/wallet.dat. No subfolder.

The cleanup logic after a failed migration assumed all wallets had subdirectories. So when things went wrong with an unnamed wallet, the cleanup code tried to remove the “parent directory” of wallet.dat. That parent was /wallets/ itself. Oops.

PR #34156 by furszy fixed this by making the cleanup smarter. Now it only touches the wallet.dat file for unnamed wallets, leaving the directory structure intact.

Who’s at risk? If you’ve been running Bitcoin Core with the default wallet setup and haven’t migrated yet, this bug was lurking. The good news is it required a failed migration to trigger, so not everyone would hit it. The bad news is if you did hit it, you’d lose everything in that directory. Backups suddenly seem less paranoid.

Performance tweaks: defending against quadratic hashing

Bitcoin Core 29.3 adds sighash caching for legacy scripts, which sounds dry until you realize what it prevents: attackers using valid but expensive transactions to slow down your node.

Here’s the setup. When Bitcoin validates a signature, it has to hash parts of the transaction. For certain complex transactions (especially legacy multisig setups), this hashing can happen repeatedly for the same data. An attacker could craft transactions that force your node to do this expensive work over and over, creating a denial-of-service drag without breaking any consensus rules.

The fix, courtesy of Pieter Wuille in PR #32473, introduces a cache. When your node validates multiple signatures in the same input, it remembers the intermediate SHA256 state (called a “midstate”). If the script code matches for the next signature check, it reuses that cached midstate instead of rehashing from scratch.

Impact: For everyday use, you probably won’t notice speed improvements. But for nodes under stress or validating blocks with complex multisig transactions, this cuts redundant computation. More importantly, it raises the cost of DoS attacks that rely on quadratic hashing patterns.

It’s the kind of invisible infrastructure work that keeps Bitcoin running smoothly. You don’t see it until you imagine what happens without it.

Smarter witness stripping detection

Another validation improvement: Bitcoin Core 29.3 detects witness stripping without re-running script validation multiple times.

Background: since PR #18044, nodes have needed to figure out when a transaction’s witness data has been stripped (making its wtxid equal to its txid). This detection prevents malicious peers from messing with transaction relay. The old approach could run script validation up to three times in the worst case, which is wasteful.

The new logic, from Antoine Poinsot in PR #33105, uses reasoning instead of brute force:

Defined witness programs (SegWit v0, Taproot) with empty witnesses will always fail validation by consensus rules.
Undefined witness programs fail regardless of witness (by standardness rules).
Pay-to-Anchor (P2A) outputs never fail on an empty witness.

With this knowledge baked in, the node can detect stripping without redundant script checks. There’s a trade-off: it may flag more transactions as “witness-stripped” even when they’re also invalid for other reasons. But that’s fine. It doesn’t affect correctness, just internal categorization.

Other wallet fixes worth noting

Beyond the directory deletion bug, 29.3 cleans up other wallet migration edge cases:

Zero-value outputs: Better handling for transactions spending 0-value outputs, particularly Lightning anchor outputs (PR #33268).
Watch-only wallets: Prevents accidentally creating spendable wallets when migrating watch-only legacy wallets (PR #34123).
wallettool improvements: Fixed unnamed wallet handling in the createfromdump command (PR #34215, PR #34370).

These are niche scenarios, but if you’ve ever tried migrating an old wallet with unusual configurations, you’ll appreciate the polish.

The mining bug almost no one will hit

There’s also a fix for an unsigned integer overflow in the mining code that could cause an infinite loop when assembling blocks. The trigger conditions are extremely specific: a miner trying to create an empty block with reserved weight (e.g., starting with -blockmaxweight=2000 -blockreservedweight=2000).

When this edge case hit, the block assembler’s loop would never break, and it would churn through every transaction in the mempool instead of bailing out. PR #33475 by ismaelsadeeq fixed the arithmetic to avoid the overflow.

Practical impact: Near zero. Almost no miner would configure their node this way in production. But the fact that it was found (via fuzz testing) and patched anyway shows Bitcoin Core’s commitment to correctness, even in obscure corners.

P2P housekeeping

Two smaller changes in the peer-to-peer layer:

No more peer punishment for invalid transactions: Nodes will stop punishing peers that relay consensus-invalid transactions (PR #33050). Invalid transactions aren’t necessarily malicious. They could result from bugs or misunderstandings. Dropping the punishment reduces false positives.
DNS seed removal: Luke Dashjr’s dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us was removed from the hardcoded DNS seed list (PR #33723).

Neither change affects typical node operation, but they’re part of ongoing network maintenance.

Should you update?

If you’re running Bitcoin Core 29.x (or older), yes. The wallet migration bug alone is worth the update, even if you’re not actively migrating right now. You don’t want to discover that bug the hard way.

If you’re already on version 30.x, you’re fine. These fixes were originally merged for the 30.x series and backported to 29.3 for users who haven’t upgraded yet.

Download: bitcoincore.org/bin/bitcoin-core-29.3/

Bitcoin Core’s maintenance model is one of the things it gets right. Rather than forcing everyone to jump to the latest major version immediately, the project backports critical fixes to older branches. It’s a sign of mature, thoughtful engineering. Not flashy, but reliable.

And in a system where people store their money, reliable beats flashy every time.

Sources

Updated: March 3, 2026