Skip to content

V9.26.4_TESTNET_PRUNE_TESTS.md

Latest commit

 

History

History
147 lines (122 loc) · 8.04 KB

V9.26.4_TESTNET_PRUNE_TESTS.md

File metadata and controls

147 lines (122 loc) · 8.04 KB
Raw

v9.26.4 Testnet26 Pruning Test Record

— DigiSwarm, DGB AI dev team · live testnet26, 2026-07-02

Companion to V9.26.4_MAINNET_VALIDATION.md. Where the mainnet record proves the prune lock and disk behavior on the live mainnet chain (DigiDollar still signaling), this record exercises the full operational battery on testnet26, where DigiDollar is already ACTIVE (activation height 599/600) — so a pruned node here does real DigiDollar validation against real on-chain positions and the real 35-oracle roster. This is the closest rehearsal of post-activation mainnet.

Why testnet is the important one

  • DigiDollar is ACTIVE on testnet26 → the retained window [600, tip] holds real DD mints/transfers/redeems, and the pruned node must resolve their amounts/lock-terms from retained blocks (no txindex).
  • It is a live, multi-node network → reindex and catch-up pull real data from real peers, not a regtest simulation.

Binary & environment

  • Binary: DigiByte version v9.26.4 (release build) from release/v9.26.4.

  • Backup source (pristine, unpruned, with wallets): ~/digibyte-testnet26-backup-20260702 (523M) — the restore point for every destructive test below. The primary node datadir ~/.digibyte is never touched.

  • Two disposable test datadirs, distinct ports, addnode'd to each other + the oracle1.digibyte.io testnet seed:

    Node datadir conf RPC P2P
    Full (parity reference) ~/.dgb-tnF txindex=1 15026 15126
    Pruned (subject) ~/.dgb-tnP prune=550 (no txindex) 15027 15127

Test battery — ALL PASS (live testnet26, tip ~67,281)

# Test Result
T1 Boot pruned: softsets, prune lock @600, DD active PASS
T2 pruneblockchain behavior at the DigiDollar floor PASS (see note)
T3 Full-vs-pruned DigiDollar stats parity (live) PASS
T4 Normal restart: startup guard passes, parity holds PASS
T5 Rescan on the pruned node preserves DD balance PASS
T6 -reindex on the pruned node, parity restored PASS
T7 Damaged block file: fail-closed, then -reindex recovery PASS
T8 Run the DigiSwarm slot-15 oracle on the pruned node PASS

Results

T1 — Boot

~/.dgb-tnP (prune=550, no txindex) logged, on the live chain:

InitParameterInteraction: parameter interaction: -prune set -> setting -txindex=0
InitParameterInteraction: parameter interaction: -prune set -> setting -digidollarstatsindex=0
DigiDollar: pruning enabled; retaining all blocks at/above height 600 (DigiDollar activation floor)

getdigidollardeploymentinfo → status: active, activation_height: 599. getnetworkinfo.localservicesnames → ['WITNESS','NETWORK_LIMITED']. getindexinfo → {}.

T2 — pruneblockchain (honest note)

pruneblockchain <tip> deleted nothing: pruneheight stayed 0 and block 100 (below the floor) remained readable. Reason: testnet26's entire block history is a single ~24 MB blk00000.dat, well under the 550 MiB minimum prune target, and a block file is only deleted once every block in it is prunable — this one holds the whole chain including the tip, so it can never be removed. So testnet cannot demonstrate actual block deletion; the prune lock is registered at 600 and would clamp if deletion ever occurred. Real deletion + the clamp are proven on mainnet: 38 GB → 0.21 GB, pruneblockchain 23774000 clamped to 23,511,221 (V9.26.4_MAINNET_VALIDATION.md).

T3 — Full-vs-pruned parity (live)

Full node (~/.dgb-tnF, txindex + stats index) vs pruned node (UTXO-scan fallback), same tip:

field full pruned
total_dd_supply 472077 472077
total_collateral_dgb 6631875.58178788 6631875.58178788
active_positions 18 18
health_percentage 335 335
oracle_available true true

Identical best-block hash; both validated new blocks as they arrived.

T4 — Normal restart

Stop → start; guard passed (pruning enabled … height 600, no "incomplete" error); post-restart supply=472077 positions=18, matching the full node. PASS

T5 — Rescan on the pruned node

Loaded the DigiSwarm oracle wallet ($1.00 DD / 100 cents, 6 positions, 1.58M testnet DGB); rescanblockchain 600 completed to height 67300; DD balance unchanged (100 → 100). Because testnet retains all blocks, rescan to any height works; the "can't rescan beyond pruned data" error path needs actual pruning and is pinned in regtest (feature_digidollar_pruning.py F6). PASS

T6 — Reindex on the pruned node

Stop → start -reindex. Reindexing block file blk00000.dat… Reindexing finished, resynced, supply=472077 positions=18 — parity restored. (On testnet the whole chain is in one contiguous file, so reindex rebuilds locally; the network-redownload path is exercised by T7.) PASS

T7 — Damaged block file → fail-closed → recovery

Truncated blk00000.dat (33.5 MB → 4 KB) and started: the node refused to run —

: Corrupted block database detected.
Please restart with -reindex or -reindex-chainstate to recover.
Aborted block database rebuild. Exiting.

Then -reindex (redownloading from the network) recovered to supply=472077 positions=18. Note: destroying testnet's single block file wipes the tip too, so this trips the standard corrupt-block-db guard rather than the DigiDollar-specific fail-closed path; both are fail-closed with -reindex recovery. The DD-specific path (a truncated file that passes the index-flag guard, isolated to below/above the floor) is pinned in regtest (feature_digidollar_pruning.py F14). PASS

T8 — DigiSwarm oracle on the pruned node (the real-world one)

On the pruned node, imported the real DigiSwarm slot-15 testnet key; the derived pubkey 03447153bcec341f2dad94541104f4e8c0a8b19e342dada1b2204ae56cf2b960a6 matches the live testnet26 roster (slot 15, in consensus). startoracle 15 → success: true, status: running; listoracle → running: true, oracle_id: 15; getoraclepubkey 15.is_running: true. Stopped cleanly. A pruned node runs a real oracle against the live roster — it needs only a wallet key, live price input and P2P, never the txindex or pre-activation blocks. PASS

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

After the final ship audit added a consensus change — gating redeem collateral classification on the DigiDollar activation floor so pruned and full nodes agree on every redeem — the whole battery was re-run on the recompiled v9.26.4 tag (c3c785443f) to prove the change is a no-op on real DD-active data:

  • Live parity (new binary): full vs pruned matched exactly at tip 70,337 — total_dd_supply=493577, active_positions=19, total_collateral_dgb=7581119.93022874, health_percentage=364, identical best-block hash. (Numbers grew from the first run because testnet minted more DigiDollar; both nodes agree on the new state.)
  • -reindex re-validation (the direct proof): the pruned node reindexed — replaying and re-validating every block, including all historical redeems, through ConnectBlock with the new collateral floor gate — reached the live tip, matched the full node exactly (493577/19), and logged zero DigiDollar consensus reject reasons (bad-collateral-release-*, bad-dd-redeem-*). The floor gate only affects sub-floor coins, of which real testnet redeems have none, so no legitimate redeem changed.
  • Restart guard (new binary): passed; stats identical post-restart.

Bottom line

Every testnet26 scenario passed on both the pre-fix and the tagged binary. A pruned v9.26.4 node on the live, DigiDollar-active testnet validates identically to a full node (to the cent), re-validates its entire redeem history under the new consensus gate with no spurious rejects, survives restarts and reindex, refuses to run on damaged data and recovers via -reindex, serves wallets with real DD, and runs the real DigiSwarm oracle. The only thing testnet can't show is physical block deletion (chain too small) — that is proven on mainnet.