DigiByte Core v9.26.3 — fresh-node header sync fix + txindex default

[DigiSwarm]

DigiByte Core v9.26.3 — fresh-node header sync fix + txindex default

Patch release on top of v9.26.2. No consensus rule changes; v9.26.2's Groestl algolock and the DigiDollar BIP9 deployment are carried forward unchanged.

1. Fix fresh-node header sync (nMinimumChainWork → 0x00)

A fresh v9.26.2 node pre-synchronizes block headers to ~99.98%, then resets to a lower height and loops forever with headers=0, never leaving IBD. Reproduced on a fresh mainnet node.

Root cause. Header pre-synchronization is a feature DigiByte inherited from the Bitcoin v25/v26 merge — it did not exist in v7.17.x (which had no pre-sync; fresh nodes downloaded and validated all headers against checkpoints, so nMinimumChainWork was only an IBD marker). It first appears in DigiByte with v8.26 / v9.26 (the Bitcoin Core v26.2 lineage), where nMinimumChainWork becomes the pre-sync work gate.

During pre-sync the node has no block index yet, so it computes each header's work from a contextless CBlockIndex (nHeight=0, pprev=null). In Bitcoin that's fine — GetBlockProof() depends only on nBits, so contextless work == real chainwork. In DigiByte GetBlockProof() is context-sensitive (multi-algo geometric mean across active algos, scaled <<7), so the contextless dummy falls into the legacy single-nBits branch and only accumulates to ~28% of the real chainwork (measured 26–29% over recent blocks).

This mismatch was harmless for years because mainnet nMinimumChainWork was 0x00. The 2026-06-26 release metadata refresh (commit 47b9ea3481) set it to a value derived from the real tip chainwork (~98.68% of tip) — which the ~28% pre-sync can never reach. Hence the reset loop.

Fix. Revert mainnet nMinimumChainWork to 0x00 (its historical value, always pre-sync-reachable). Chain-metadata only — no consensus, chain-selection, or anti-DoS change relative to mainnet's prior behavior. Testnet/signet/regtest unaffected. Full analysis in doc/HEADERS_SYNC_FIX_PLAN.md.

Any value ≤ ~28% of real tip chainwork would also work; a proper non-zero anti-DoS floor is possible later but must stay below the contextless pre-sync ceiling (or pre-sync must be made contextual — a larger change deferred here).

2. txindex on by default

DEFAULT_TXINDEX = true. DigiDollar requires a full transaction index and the node already refuses to start with DigiDollar active and -txindex off; defaulting it on lets DigiDollar nodes start out of the box. -txindex=0 still works for non-DigiDollar setups.

Note: the -digidollar flag is not required and not defaulted — DigiDollar consensus/RPC/P2P all follow the BIP9 deployment via IsDigiDollarEnabled(); the flag only affects regtest.

3. Version → v9.26.3

Testing

• Full C++ unit suite: 3403 cases, no errors.
• Full functional suite: run (test_runner.py --jobs=8).
• Fresh-node reproduction + fix validated against live mainnet nodes

[JaredTate]

If you are having issues syncing DigiByte v9.26.2 make your digibyte.conf in the default $DGB data directory look like this:

[main]
server=1
listen=1
txindex=1
digidollar=1
minimumchainwork=00

addnode=oracle1.digibyte.io:12024
addnode=digihash.digibyte.io:12024
addnode=digiexplorer.info:12024

There was an incorrect minimumchainwork setting added in v9.26.2 release that will be fixed shortly with v9.26.3.

We manually confirmed adding 'minimumchainwork=00' to digibyte.conf fixes the sync issue; it was not peers, it was not v7 nodes on the wrong chain.

The issue was minimumchainwork was added in BTC v25 and does not apply to DGB multialgo.

We calculated a recent block 23.5 million chain work for v9.26.2, and it only adds up to 28% in pre-sync and resets because the check is not properly adapted to DGB multi-algo.

So we return to the same default setting that we had in v7 and v8.

[gto90]

ACK

Tested using fresh mainnet node

[JaredTate]

ACK tested; all looks good for v9.26.3

[ycagel]

cACK