Skip to content

V9.26.4_MAINNET_VALIDATION.md

Latest commit

 

History

History
172 lines (139 loc) · 8.39 KB

V9.26.4_MAINNET_VALIDATION.md

File metadata and controls

172 lines (139 loc) · 8.39 KB
Raw

v9.26.4 Mainnet Prune Validation — Live Test Record

Date: 2026-07-02 (UTC) · Binary: DigiByte version v9.26.4 (release build) from branch release/v9.26.4 · Host: Jared's workstation, live mainnet P2P.

Purpose

Prove on real mainnet data — not just regtest — that a v9.26.4 node with prune=N and no txindex:

  1. boots, registers the DigiDollar prune lock at the activation floor (23,627,520), and prunes the ~12-year pre-DigiDollar history;
  2. keeps validating and following the live chain while pruned;
  3. can never prune a DigiDollar-era block, even when explicitly asked to;
  4. reports correct DigiDollar deployment state pre-activation.

Context: mainnet tip was ~23,774,300 during the test — already past the minimum activation height (23,627,520) while DigiDollar BIP9 is still signaling (status: started). So the retained DigiDollar-era window is live and real: the lock protects blocks that exist today.

Setup (repeatable)

# 1. Cleanly stop the primary node (Qt has no mainnet RPC in this config):
kill -TERM <qt-pid>        # wait for "Shutdown: done" in ~/.digibyte/debug.log

# 2. Copy chain data to a disposable test datadir (~39 GB, a few minutes).
#    The untouched ~/.digibyte is the pristine backup — re-copy to reset the
#    test bed for reindex/rescan experiments at any time.
mkdir -p ~/.digibyte-prunetest
cp -a ~/.digibyte/blocks     ~/.digibyte-prunetest/blocks
cp -a ~/.digibyte/chainstate ~/.digibyte-prunetest/chainstate
# deliberately NOT copied: indexes/ (txindex + DD stats index — the pruned
# node must not need them) and wallets/ (test runs walletless).

# 3. Test-node config (~/.digibyte-prunetest/digibyte.conf) — distinct ports
#    so it can coexist with the primary node:
#      prune=2000
#      server=1
#      rpcport=14022
#      port=12124
#      rpcbind=127.0.0.1
#      rpcallowip=127.0.0.1
#      dbcache=1024
#      # no txindex line on purpose: prune must auto-disable the default txindex

# 4. Launch the release Qt against it:
DISPLAY=:1 src/qt/digibyte-qt -datadir=$HOME/.digibyte-prunetest -splash=0

# 5. Query it:
src/digibyte-cli -datadir=$HOME/.digibyte-prunetest -rpcport=14022 <cmd>

Observed results

Startup (debug.log)

DigiByte version v9.26.4 (release build)
InitParameterInteraction: parameter interaction: -prune set -> setting -txindex=0
InitParameterInteraction: parameter interaction: -prune set -> setting -digidollarstatsindex=0
Prune configured to target 2000 MiB on disk for block and undo files.
DigiDollar: pruning enabled; retaining all blocks at/above height 23627520 (DigiDollar activation floor)
Oracle: DigiDollar not yet active (BIP9) at height 23774290, skipping price loading

All four wiring points fired on mainnet: txindex softset off, DD stats index softset off, prune lock registered at the activation floor, and the BIP9-gated oracle startup skip. Startup includes one long single-core step (~8 minutes) after "Pruning blockstore…": the DigiDollar health seeding scan over the ~24M-entry mainnet UTXO set (present since v9.26.3; not prune-specific).

Pruned steady state

Check Result
getblockchaininfo.pruned true
Disk (size_on_disk) after initial prune 2.07 GB (from 38 GB blocks + 4.2 GB indexes)
First pruneheight 21,195,663 — below the floor, because the 2000 MiB size target was satisfied before the lock had to bind
Chain following tip advanced live with the network while pruned (23,774,274 → 23,774,383+)
getnetworkinfo.localservicesnames ['WITNESS', 'NETWORK_LIMITED'] — no NODE_NETWORK, correct for a pruned node
getindexinfo {} — no txindex, nothing else
getdigidollardeploymentinfo status: started, bit 23, min_activation_height: 23627520, live signaling tally (4,130 of 28,224 threshold at test time), MuSig2 session telemetry present

The DigiDollar prune lock, proven on mainnet

$ digibyte-cli pruneblockchain 23774000     # deliberately above the floor
23511221                                    # clamped — refused to cross the lock
  • Requested prune height 23,774,000 (near tip, far above the floor).
  • Actual prune stopped at 23,511,221 — the last whole block-file boundary below the lock (floor − PRUNE_LOCK_BUFFER − 1 = 23,627,509; the block file containing the floor spans ~116k blocks and is retained whole).
  • Floor block 23,627,520: still readable (getblock succeeds).
  • Block 23,000,000 (below the floor): pruned, getblock errors cleanly.
  • Disk after the aggressive prune: 0.21 GB.

This is the release guarantee in one command: a pruned v9.26.4 node cannot be talked into deleting a DigiDollar-era block — automatic pruning and the pruneblockchain RPC both clamp below the activation floor.

getdigidollarstats on a pruned mainnet node

Pre-activation it returns instantly with DigiDollar is not yet active on this blockchain — the standard activation gate at the top of every DigiDollar RPC. The no-index UTXO-scan fallback (and its "don't poll it tightly" caveat from the release notes) only comes into play after activation.

First-prune cost, and restart with m_have_pruned=true

  • The first prune of a 23.7M-block chain took ~8 minutes of one core between "Pruning blockstore…" and "Done loading": pruning ~21 million blocks marks each one's block-index entry as data-less and flushes that to LevelDB once. (The primary node's unpruned startups show no such gap, and neither does the pruned node afterward.)
  • Restart after pruning: total boot ~112 s (block-index load, same as an unpruned node), "Pruning blockstore… → Done loading" in the same second. The data-availability guard (CheckBlockDataAvailability from tip down to the floor, m_have_pruned=true) ran against the pruned datadir, found the DigiDollar-era window intact, and booted normally with the prune lock re-registered. (The refuse-to-start path for a damaged window is pinned by feature_digidollar_pruning.py F9 on regtest — it cannot be triggered with a v9.26.4 binary because the lock prevents creating the damage.)

Reset / reindex / rescan procedure

  • Reset the test bed (fresh un-pruned copy): stop test Qt, then rm -rf ~/.digibyte-prunetest/{blocks,chainstate} and re-copy from ~/.digibyte (the pristine backup). ~3 minutes.
  • Reindex test: with the copy in place, start with -reindex to rebuild the chainstate from local block files. On a pruned copy, -reindex re-downloads missing history from the network and re-prunes (this is the recovery path the startup guard prescribes; exercised end-to-end in feature_digidollar_pruning.py F9 on regtest).
  • Rescan test: wallet rescans work within the retained window and fail cleanly with "Can't rescan beyond pruned data" below it (pinned in feature_digidollar_pruning.py F6).
  • The primary node's datadir ~/.digibyte was never modified by this test.

Re-validation on the tagged binary (consensus fix included)

Re-run on the recompiled v9.26.4 tag (c3c785443f, which adds the redeem collateral floor gate) against a fresh 42 GB copy of ~/.digibyte (~/.dgb-mainprune, prune=2000, no txindex):

  • Boot: both softsets fired; DigiDollar: pruning enabled; retaining all blocks at/above height 23627520; DigiDollar status started (mainnet not yet active); pruned=true; services ['WITNESS','NETWORK_LIMITED']; getindexinfo empty. Initial prune to the 2000 MiB target: size_on_disk 1.77 GB.
  • Clamp: pruneblockchain(23778861) returned 23,511,221 (below the floor), floor block 23,627,520 remained readable, block 23,000,000 was gone (error -1), and size_on_disk fell to 209,887,284 bytes (0.21 GB).
  • Restart: the data-availability guard passed, pruned=true, the floor block was still available, and the node resumed syncing the live chain.

Identical to the original run — the consensus change does not affect mainnet (DigiDollar is not active yet, so no redeem path runs) and does not change the prune/lock/guard mechanics.

Verdict

Every mainnet observation — on both the pre-fix and the tagged binary — matched the regtest functional suite (feature_digidollar_pruning.py, 15 phases), the live testnet26 battery, and the code review. The pool config in the release notes (prune=2000, no txindex) runs today on mainnet, keeps the full DigiDollar-era window, and will carry a pool through DigiDollar activation without a further upgrade.