DigiByte v9.26.0-rc32 Release Notes

WARNING: This is a TESTNET-ONLY release. DO NOT use on mainnet.

Development Branch: https://github.com/DigiByte-Core/digibyte/tree/feature/digidollar-v1

Join the Developer Chat: https://app.gitter.im/#/room/#digidollar:gitter.im

✅ SAME TESTNET — NO RESET

RC32 uses the same testnet23 chain as RC31. No reset, no new genesis, no network-magic change, no port change. Existing chain data, wallets, DD positions, and oracle keys carry forward.

Oracle operators running RC31 can drop in RC32 binaries and resume. There are no oracle key rotations in RC32.

What's New in RC32

RC32 is a DigiDollar wallet + mining reliability release on top of RC31. It removes unconfirmed DigiDollar transfer chaining, adds a sendmanydigidollar RPC so apps can pay multiple DD recipients in one transaction, updates RC32 wallet branding, and fixes a miner block-template hang exposed by the new confirmed-only DD policy.

RC32 fix summary since RC31

• Unconfirmed DigiDollar chaining removed — DD transfer outputs, including trusted wallet-created change, are no longer spendable until confirmed. Wallet balance, DD coin selection, Qt available balance, and consensus validation now enforce the same confirmed-only rule.
• Consensus rejects unconfirmed DD inputs consistently — transfer and redemption validation now refuse DD inputs at MEMPOOL_HEIGHT with dd-input-amounts-unknown. The old mempool DD amount fallback was removed so local metadata cannot create peer-inconsistent acceptance.
• sendmanydigidollar RPC added — wallets and apps can send to multiple DigiDollar addresses in one confirmed-input transaction instead of trying to chain unconfirmed DD change through consecutive senddigidollar calls.
• Qt DigiDollar send panel updated — available DD now means confirmed spendable DD only. Pending DD remains visible as pending but cannot be selected for another send until confirmed.
• Miner CreateNewBlock hang fixed — when a DD transaction fails block-inclusion validation while selected from mapModifiedTx, the miner now erases the failed modified entry instead of selecting it forever. This prevents runaway debug logs and stuck block-template generation.
• RC32 branding — version bumped to v9.26.0-rc32; Qt wallet image text updated to v9.26.0-rc32 DigiDollar.
• Release-note archive cleanup — older RC28–RC30 release notes moved under doc/release-notes/ so the repository root only carries the active/recent RC notes.

1. Confirmed-only DigiDollar transfers

RC31 still allowed wallet-trusted unconfirmed DD change to appear spendable in some paths. That made rapid consecutive sends depend on unconfirmed DD parents and created the exact behavior we do not want for v1: local mempool chains with DD amounts that peers cannot independently resolve from confirmed history.

RC32 changes the rule to the simple v1 policy:

A DigiDollar output must confirm before it can be spent again.

That applies to:

• DD balance shown as spendable by the wallet.
• DD UTXO selection for senddigidollar and sendmanydigidollar.
• Qt send-screen available balance.
• Transfer validation.
• Redemption validation.

Pending DD, including the change output from your own transfer, remains tracked as pending. It simply cannot be spent until a block confirms it.

User-facing behavior

If a wallet sends DD and immediately tries to spend the resulting DD change before confirmation, RC32 rejects the second spend with a normal wallet/validation error. Wait for the next confirmation and retry.

This is intentional. It prevents unconfirmed DD chains and keeps mempool behavior consistent across peers.

2. sendmanydigidollar

RC32 adds:

digibyte-cli -testnet -rpcwallet=<wallet> sendmanydigidollar "" '{"TD...addr1":5000,"TD...addr2":1250}'

Arguments:

1. dummy — must be "", matching the Bitcoin/DigiByte sendmany style.
2. amounts — JSON object mapping DigiDollar addresses to amounts.
3. comment — optional wallet comment.

Amounts follow the existing DD RPC convention:

• Integer values are cents: 5000 = $50.00 DD.
• Decimal values are dollars: 50.25 = 5025 cents.

Example result:

{
  "txid": "...",
  "amounts": {
    "TD...addr1": 5000,
    "TD...addr2": 1250
  },
  "total_amount": 6250,
  "status": "success"
}

Why this matters

For payment apps and PayDesk-style flows, the clean v1 pattern is now:

• gather confirmed DD inputs,
• create one transfer transaction,
• pay many recipients,
• receive optional DD change,
• wait for confirmation before spending that change again.

That replaces the unsafe pattern of sending recipient #1, then immediately chaining the unconfirmed change into recipient #2.

3. Miner block-template hang fix

The confirmed-only DD policy exposed a miner edge case in CreateNewBlock.

When the mempool contained an accepted DD parent plus unconfirmed DD descendants, the descendants correctly failed block inclusion with dd-input-amounts-unknown. But if the failed transaction was being considered from mapModifiedTx, the miner did not erase that modified entry after the DD failure. The outer package-selection loop then selected the same failing entry forever.

Observed failure mode:

• getblocktemplate / mining appears stuck.
• debug.log grows explosively with repeated DD rejection lines.
• Disk can fill if left running.

RC32 handles DD validation failure like the existing package-test failure paths: if a modified candidate fails and is not added to the block, erase it from mapModifiedTx and continue. This fixes the hang for unconfirmed DD chains and for any other DD validation failure encountered during block assembly.

4. Validation results

Upgrade Path

RC32 is a drop-in binary replacement on testnet23.

1. Stop the RC31 node or Qt wallet.
2. Install the RC32 binary.
3. Start with the same data directory and wallet.
4. Keep txindex=1 enabled for DD nodes.
5. Oracle operators: load/unlock the same oracle wallet and run startoracle <your_oracle_id> if auto-start does not resume.

No chain reset or wallet migration is required.

Manual oracle start if needed:

digibyte-cli -testnet loadwallet "oracle"
digibyte-cli -testnet -rpcwallet=oracle startoracle <your_oracle_id>

Encrypted wallet operators should unlock first:

digibyte-cli -testnet -rpcwallet=oracle walletpassphrase "your passphrase" 600
digibyte-cli -testnet -rpcwallet=oracle startoracle <your_oracle_id>

Oracle Operators (RC32)

No oracle slot changes from RC31.

Network Information

Configuration

testnet=1

[test]
digidollar=1
txindex=1
algo=scrypt
addnode=oracle1.digibyte.io

Note: txindex=1 is enforced at startup for DD-enabled nodes. Make sure it is in the correct section ([test] for testnet, [main] for mainnet). Global placement above all sections also works.

Scrypt CPU mining against local Qt/node

For local testnet scrypt mining, both the node and miner must agree on scrypt:

[test]
algo=scrypt

Start the miner with the scrypt flag explicitly:

cd /home/jared/Code/cpuminer
./minerd -c dgb-solo-mining.json -a scrypt -t 12

Healthy mining output includes:

• 12 miner threads started, using 'scrypt' algorithm.
• Long-polling activated for http://127.0.0.1:14026/
• no repeated HTTP 401/500 errors.

Downloads

Binaries attached to the GitHub release once Guix builds complete and are verified.

Troubleshooting

"My DD change disappeared after sending"

It did not disappear. In RC32, unconfirmed DD change is pending, not spendable. Wait for the transfer to confirm, then it becomes available for the next DD spend.

"senddigidollar says insufficient DD balance right after I sent DD"

That is expected if your only remaining DD is unconfirmed change. Wait for one confirmation or use sendmanydigidollar to pay multiple recipients in the original transaction.

"Previous DigiDollar transfer has not confirmed yet"

RC32 intentionally blocks DD chains through unconfirmed parents. Wait for confirmation and retry.

"getblocktemplate hangs or debug.log grows rapidly"

This was the miner bug fixed in RC32. Upgrade to RC32. If you are still testing older binaries, stop the node, clear stale mempool state, and restart with a clean mempool.

"My oracle did not start automatically"

Load and unlock the oracle wallet, then start manually:

digibyte-cli -testnet loadwallet "oracle"
digibyte-cli -testnet -rpcwallet=oracle walletpassphrase "your passphrase" 600
digibyte-cli -testnet -rpcwallet=oracle startoracle <your_oracle_id>

"Node refuses to start: oracle roster alignment mismatch"

That is the RH-50 guard from RC31 working as intended. It means consensus.vOraclePublicKeys and vOracleNodes disagree in your local chainparams. Run an official RC32 binary and do not hand-edit chainparams.

Commits Since RC31

0b4959f563 wallet: remove unconfirmed DigiDollar chaining
9143bed9b9 rpc: add sendmanydigidollar
14c08a9f1b release: bump DigiDollar RC32 wallet branding
6b5ff516c3 miner: fix CreateNewBlock hang when DD tx fails in mapModifiedTx
a7c0c97521 Doc Cleanup

Feedback & Community

• Developer Chat (Gitter): https://app.gitter.im/#/room/#digidollar:gitter.im
• GitHub Issues: https://github.com/DigiByte-Core/digibyte/issues