Bitweb Core 31.2

This release is a maintenance and feature update on top of the 31.x branch.

Caution

ALWAYS BACK UP YOUR WALLET DATA BEFORE ANY UPDATE. SHUTDOWN 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 31.1

If you are already running Bitweb Core 31.1, upgrading to 31.2 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 31.2.
4. Start the node — it will continue syncing from where it left off.

No rescan or migration is required when upgrading from 31.1.

What's new in 31.2

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 31.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.
• Hardened private-broadcast handling: newly queued transactions get a 5-minute grace period
  before being flagged stale (previously they could be flagged within seconds), and sending to the
  same node id twice for the same transaction is now prevented.
• 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 — make sure you're upgrading from 31.1 (or a migrated 30.x
  wallet). If you're coming from an older, unmigrated chain, instructions in the 30.3.1 release.
• 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.