Bitweb Core 30.4

Bitweb Core 30.4 is now available. This release is a maintenance and feature update on top of the 30.x branch.

⚠️ IMPORTANT! ALWAYS BACK UP YOUR WALLET DATA BEFORE ANY UPDATE. Shut down your wallet completely, then copy your wallet.dat file to a safe place before updating. If possible, always encrypt your wallet with a strong password.

Upgrade from 30.3.1

If you are already running Bitweb Core 30.3.1 with a migrated wallet, upgrading to 30.4 is straightforward:

1. Shut down your node completely.
2. Back up your wallet.dat to a safe location outside the data directory.
3. Install Bitweb Core 30.4.
4. Start the node — it will continue syncing from where it left off.

No rescan or migration is required when upgrading from 30.3.1.

What's new in 30.4

New feature: header PoW verification cache

This release adds a new header proof-of-work verification cache (pow_cache), built on the same CuckooCache::cache structure already used elsewhere in the codebase (e.g. the signature cache). The cache stores the result of already-verified headers (64 MiB by default, configurable via -headerpowcachesize) and sits behind a single choke point, CheckProofOfWorkCached(), used by both header validation (CheckBlockHeader()) and block reads from disk (BlockManager::ReadBlock()). This means the cache speeds up essentially any PoW check on an already-seen header — including serving blocks to other peers and re-reading blocks from local storage — not just initial header sync. It starts empty and is warmed up by ordinary node operation; misses always fall back to a full Argon2id recompute, so consensus rules are unaffected.

New feature: parallel header PoW check queue

Separately, header PoW checks can now be dispatched across a dedicated parallel check queue owned by ChainstateManager, instead of being checked one at a time. This only engages once a batch of headers exceeds an internal threshold (32 headers) — in practice this means it's mainly active during the presync stage of initial headers sync, where large batches of headers arrive from a peer and need checking before the chain's cumulative work is confirmed; during normal steady-state operation, where headers usually arrive in small numbers, checks are still processed sequentially. Up to 6 threads can be used; on machines with fewer than 3 CPU cores, the queue automatically falls back to a single thread so it never starves the rest of the node.

Bug fixes (backported from upstream Bitcoin Core, not yet in official 30.x)

• Fixed a race in FetchBlock() where a peer disconnecting between GetPeerRef() and BlockRequested() could hit an assert on a missing CNodeState, remotely triggerable via the getblockfrompeer RPC.
• Fixed an undefined-behavior bug where a pruned node in a deep reorg could insert the same (parent, block) pair into m_blocks_unlinked twice, corrupting the ordering invariant of setBlockIndexCandidates.
• Enforced BIP152's requirement that sendcmpct's announce field be 0 or 1; peers violating this are now misbehaved and disconnected.
• Fixed mempool package cleanup on an internal, not-known-to-be-reachable "PolicyScriptChecks succeeded but ConsensusScriptChecks failed" path, so a failing transaction's dependents are also removed instead of being left behind.
• Fixed a cosmetic Taproot-deployment reporting issue in RPC output (Taproot itself was already active at the validation level; only the RPC status report was affected).

See release notes on GitHub for the full changelog.

Troubleshooting

• Node won't start after upgrade — ensure your wallet was already migrated. If you skipped migration, see the instructions in the 30.3.1 release. This release still contains the migration code.
• Balance shows zero after upgrade — run bitweb-cli rescanblockchain to rescan the chain.

Issues or questions? Use the issue tracker or join the community on the resources page.