DigiByte Core v9.26.6 release notes

Final v9.26.6 release

v9.26.6 includes RC1, RC2 and the final wallet improvements listed below.
The final changes improve minting from wallets with many small coins, explain
send errors, and make the wallet easier to read. They do not change RC2's
consensus rules, oracle requirements or Thaw Day heights. Consensus means
the rules nodes use to agree on valid blocks.

All full-node and mining operators must upgrade before mainnet block
24,490,000, including operators who do not use DigiDollar. Older software
can disagree about valid blocks after that height. Testnet26 activated Thaw
Day at block 432,100. Mainnet activation is controlled by its block
height, not a calendar date.

What to do

1. Back up your wallets and configuration. Keep the backups private.
2. Download the final release for your system and verify the published checksums.
3. Stop the old wallet or daemon normally, replace the program, and restart it.
4. Check that the version is v9.26.6 and that the node finishes synchronizing.

A normal upgrade from a working RC2 node does not require a reindex. Keep the
required DigiDollar block history. If the old node stopped on a rejected block,
use the reviewed recovery instructions for that failure.

Installing this release enables its wallet and display improvements immediately.
The scheduled mainnet rule changes begin at block 24,490,000. Minting still
requires an eligible price, sufficient collateral and the other existing checks.

Changes added after RC2

Each entry is one change group. Supporting tests count with their fix.
The version number, wallet version image and release-note edits are not extra fixes.

Minting and sending

1. Change: Large mints wait for coin-merge transactions to confirm before building the mint, and show the merge transaction IDs. Repeated requests reuse that pending status, including after restart.
   Why: Spending several large, unconfirmed merges at once can exceed the existing transaction-chain limit. The wallet must explain the wait without recording a failed mint or starting unnecessary extra merges.

2. Change: The Qt mint form respects manually locked DGB coins and uses the wallet's normal spendable-coin checks.
   Why: Coins the user has locked must stay out of automatic collateral selection.

3. Change: DigiDollar sends report the actual coin-selection error and check the selected inputs before asking for confirmation.
   Why: Change below $1 needs a different amount or input selection. Waiting for confirmations will not fix that error. The $1 output minimum is unchanged.

4. Change: Oversized DGB sends explain that too many coins are needed and suggest a smaller send or combining small coins first.
   Why: The existing transaction-size limit remains necessary, but users need a useful next step.

5. Change: A DigiDollar send that lacks fee funds shows the estimated fee in DGB.
   Why: Users should not have to convert an internal unit or assume every send costs the same amount.

Wallet screens and CSV exports

1. Change: The Send DigiDollar address field says "Enter a DigiDollar address."
   Why: Example text should not look like an address already entered by the user.

2. Change: DigiDollar paste and address-book icons have readable contrast, and Send and Clear buttons visibly respond to hovering and clicking.
   Why: The controls should be recognizable and show when they are being used in both themes.

3. Change: DigiDollar transaction rows, filters and dropdowns use the DigiDollar green theme consistently.
   Why: Mixed background and text colours made the page harder to read.

4. Change: Main Transactions CSV dates include hours, minutes and seconds without an unnecessary ".000" ending.
   Why: Exports should contain clear, consistent dates. Dates shown inside the wallet still follow the computer's regional settings.

5. Change: The main Transactions page exports DigiDollar amounts as plain decimal numbers without a currency suffix.
   Why: Spreadsheets need numeric cells for calculations. This completes the CSV amount repair started in RC2.

6. Change: Transaction exports suggest a dated filename and make the disabled Save button readable.
   Why: Users should have a useful starting filename and understand when saving is unavailable.

7. Change: New folder names remain readable while editing them in the dark-theme export dialog.
   Why: The old styling could put white text on a white background.

8. Change: The About window gives its text enough room, keeps links readable, and points to the current DigiByte website and source repository.
   Why: Users need to find their version and the project's current information without a cramped text column.

RPC, logging and test tools

1. Change: listdigidollaraddresses returns saved labels, transaction counts and last-used times from the wallet.
   Why: These fields previously returned empty or zero values. An unknown address creation date remains empty rather than being guessed.

2. Change: validateaddress help and wallet integration instructions direct DigiDollar users to validateddaddress.
   Why: DigiByte and DigiDollar use different address formats. The existing DigiDollar command checks DD, TD and RD addresses without changing ordinary DigiByte address validation.

3. Change: Expected nonmatching DigiDollar key checks appear only when DigiDollar debug logging is enabled.
   Why: Routine wallet scanning should not fill the normal log with misleading messages.

4. Change: The isolated Thaw Day test builds the current release candidate by default and also accepts an exact commit or tag.
   Why: Each rehearsal must exercise the intended candidate rather than an older, fixed commit.

5. Change: The Thaw Day test leaves its last permitted block available while oracle signatures finish.
   Why: A block mined without a price bundle cannot gain one later. The test must wait before mining that block and still check the actual signed bundle afterward.

Integration notes and limits

When a mint needs coin merging, mintdigidollar can return
status: "consolidation_pending" and consolidation_txids. This means that
no DigiDollar has been minted yet. Wait for those transactions to confirm,
then retry. Check any accompanying error if a later merge failed. The normal
successful mint response is unchanged. Coin merges are ordinary DGB
transactions and pay the normal network fees.

listdigidollaraddresses counts distinct DigiDollar transactions known to the
wallet. last_used is the latest wallet transaction time, in UTC. These fields
describe this wallet's records, not a complete public address history.

This release does not add a general "combine coins" button or DigiDollar
watch-only import support. An oracle pause remains a restriction, not permission
to bypass missing signatures or price checks. A reported Windows-only blank
progress popup was not reproduced in the Linux checks; no speculative change
was made for it.

Final verification

The Linux test runs checked the production source at a96e6b10b6. The later
rehearsal correction changes only the test script and its regression tests;
the production source is identical.

The functional skips require older binaries, tracing support, special network
interfaces, or unsupported Signet features. Fuzz checks replayed the saved
test inputs; the two targets without saved inputs each generated new inputs
for ten seconds. This was a bounded test run, not an exhaustive search.

Linux visual checks covered all seven DigiDollar tabs, the changed controls
and export dialogs, and the About window in light and dark themes. Native
Windows and macOS checks are still needed on their release packages.

The private rehearsal used commit 86c8176902 with the isolated lab patch.
All nine nodes finished on the same block at height 5,686. The lab changes
its own network settings and activation height; it does not replace a full
mainnet history reindex or native release-package checks.

The RC1 and RC2 results below describe those earlier candidates. Release
packages must be built from the reviewed final tag and checked before
publication. These source tests do not verify packages that have not yet
been built.

Release package checks

These five packages were built with the same native Guix process used for RC2,
from tag v9.26.6, commit 92330d9.

• Builds completed for Linux x64, Linux ARM64, Windows x64, Apple Silicon Mac and Intel Mac.
• All 15 build-output checksums passed. The five packages contain the expected processor architectures. ZIP integrity checks passed.
• The packaged Linux programs report v9.26.6. All 3,759 unit cases passed, with two existing partial-fixture warnings. The optional script-data case also passed when run with its saved data.
• Nine functional checks passed using the packaged Linux programs. They cover Thaw Day, fresh sync, restarts, reorganizations, accounting and oracle-bundle validation.
• Review still required: native Mac CI failed one test that assumes at least 5% memory savings. Its estimate was about 4.6% lower. That platform-dependent test expectation needs review, and Mac functional tests did not run after the failure.
• Windows, Mac and Linux ARM64 packages still need testing on their own systems.

Windows and Mac packages are unsigned, as in RC2. Mac applications are ZIP files.
The SHA-256 values below identify the five downloads; they are not digital signatures.

05cc75f57e934882673b941f1c9c0b99eaddc2fd7fa797224b7187c95db61e96  digibyte-9.26.6-aarch64-linux-gnu.tar.gz
db407a272cddd447152ea376eeac6d790410365aa34da7958b1b0e6924da0582  digibyte-9.26.6-arm64-apple-darwin.zip
714dfdb2a2dfcf1893b66c541386b173b1959153675699bab30eac96e0135db5  digibyte-9.26.6-win64-setup.exe
9f85163485040395f89d6cae34c2cefe5df127eca6e8f61a523d23dd5ed05f82  digibyte-9.26.6-x86_64-apple-darwin.zip
cdbd6ed7efdb006b91b76389db79d2a3db2593f05e56dd789f394a1b4366c211  digibyte-9.26.6-x86_64-linux-gnu.tar.gz

RC2 — second release candidate

RC2 adds the changes below to RC1. The code change list covers source through
943243613ce7f75492eae8b4a074859eeb5ba6d1. RC2 is a test release before the
final v9.26.6 release. Release packages must be built from the final RC2 tag
and verified before distribution.

Full-node and mining operators must upgrade before mainnet block
24,490,000. Thaw Day changes the rules used to agree on valid blocks, even
for operators who do not use DigiDollar. Older software can disagree after
activation. Installing the update prepares the node; the block height starts
the scheduled rule changes.

Testnet26 has passed block 432,100 and Thaw Day activated there. RC2 is being
tested on the already-active testnet. Mainnet block 24,490,000 remains the
future production activation height. Calendar estimates in the preserved RC1
notes are historical. The RC2 repair that removes wallet state from DigiDollar
validation also applies when checking blocks below Thaw Day.

What the totals count

Each numbered entry counts one distinct change group. Related repairs are
grouped, and a repair's supporting tests are included with that repair. A
separate test tool or coverage expansion has its own entry. Version labels,
wallet version artwork and edits to these notes are not extra improvements.
These totals are not counts of security vulnerabilities or outside reports.
The categories describe the main purpose of each group, not its severity.

Corrective fixes since RC1

1. Change: DigiDollar block and mempool validation read amounts and vault identity from chain records independently of the wallet's local script table.
   Why: Nodes checking the same transaction must reach the same result regardless of their wallet history.

2. Change: Header synchronization calculates mining work using the header's actual chain history, including competing branches.
   Why: Valid headers must receive the work score required by the existing mining rules.

3. Change: Incoming block checks verify proof of work before consulting more expensive chain history.
   Why: Invalid block submissions should be rejected without unnecessary history lookups.

4. Change: The DigiByte send form identifies a missing or invalid address, an invalid amount, or an amount too small to send.
   Why: Clicking Send should explain the field that needs attention.

5. Change: DigiDollar transaction dates and amounts, position dates and receive-request dates sort by their underlying values.
   Why: Formatted text can put dates and money in the wrong order.

6. Change: DigiDollar transaction CSV exports write amounts as plain decimal numbers.
   Why: Spreadsheets and accounting tools need numeric amounts without a currency suffix.

7. Change: DigiDollar pages distinguish expired, abandoned and conflicted mint attempts from confirmed vaults and completed redemptions.
   Why: An unsuccessful mint must not appear as collateral that was redeemed or can still be redeemed.

8. Change: The pending DigiDollar balance excludes local mint attempts whose confirmation window has expired.
   Why: A mint that cannot confirm on the current chain should not inflate the pending balance.

9. Change: Redemption commands and estimates use the correct block boundary for the transaction's time lock.
   Why: A vault must not be reported as redeemable one block before its redemption can enter the mempool.

10. Change: Redemption status finds the actual collateral output when an older mint places its outputs in a different order.
    Why: An unconfirmed redemption must remain pending until it confirms, including when ordinary change precedes the collateral.

11. Change: Bounds the recent Dandelion transaction hashes remembered for each peer while keeping exact checks for retained entries.
    Why: Long-running peer connections need predictable memory use without weakening transaction relay checks.

12. Change: Clears Dandelion peer routes before shutdown deletes peer connections.
    Why: Shutdown must not leave transaction relay referring to a peer that has already been removed.

Usability and logging improvements since RC1

1. Change: DigiDollar dates use the computer's regional format, with columns sized to fit.
   Why: Dates should follow the user's settings across the wallet.

2. Change: The DigiDollar overview and mint pages explain missing prices, unavailable checks and restrictions that pause minting.
   Why: Users need to know why minting is unavailable and when they can check collateral and fees.

3. Change: DigiDollar controls, labels, dropdowns and status text follow the wallet's light and dark themes consistently.
   Why: Both themes need readable text and recognizable controls.

4. Change: Repeated redemption requests distinguish a pending redemption, a redeemed vault and another inactive position.
   Why: Users need the position's actual state before deciding whether to retry.

5. Change: estimatecollateral includes mint restrictions and their reason alongside its collateral figures.
   Why: A collateral estimate alone does not mean a mint can currently proceed.

6. Change: DigiDollar commands distinguish an unavailable next-block oracle quote from unavailable health state.
   Why: The error should identify which information is missing.

7. Change: senddigidollar help explains that the sending wallet needs spendable DGB for the transaction fee.
   Why: A DigiDollar balance cannot pay a DGB network fee.

8. Change: Repeated wallet reconciliation messages during synchronization require -debug=digidollar.
   Why: Routine progress should not fill the normal log once per block.

9. Change: Routine compact-block header messages follow the network debug setting.
   Why: Normal logs should stay quiet when network debugging is disabled.

Tests, tools and documentation since RC1

1. Change: Adds a repeatable, isolated Thaw Day rehearsal with build records and checks before, across and after activation.
   Why: The same wallet, oracle and chain scenarios need to be repeatable on each candidate.

2. Change: Expands tests for DigiDollar transfer recovery after a mint is disconnected and later confirms again, including after restart.
   Why: Tests must cover normal wallet rebroadcast and balance recovery as well as rejection while the mint is unconfirmed.

3. Change: Corrects the private security-reporting instructions.
   Why: Sensitive reports need to reach the project's designated private channels.

Verification and known limits

The combined source passed 3,755 unit test cases and the rendered Qt test
suite. Of 421 scheduled extended functional-test entries, 404 passed and
17 were skipped. None failed. The skips cover unsupported Signet, unavailable
old release binaries, disabled USDT tracepoints and special test IP addresses.
All 256 fuzz targets passed under AddressSanitizer and UndefinedBehaviorSanitizer,
which check for memory errors and undefined behavior. That run replayed saved
inputs and generated inputs for the target without a saved corpus.
Focused shutdown tests also reproduced the stale-route failure before the fix
and passed under AddressSanitizer after the fix.

The isolated Thaw Day rehearsal built from commit
8ae095ae01b3bbdac13723db346c3970343ec544 also passed. It repeated DigiDollar
minting, sending, redemption and accounting before and after the exact activation
height. It also passed restart, backup restore, boundary rollback, competing-branch
reorg, full private reindex and empty-directory fresh-sync checks.

These results verify the source build used for testing. They do not certify the
final RC2 release binaries. The release build record must identify the final tag,
binary hashes, build options, completed checks, skips and unresolved findings.
An isolated rehearsal does not establish public-network agreement.

Large DigiByte sends from wallets with many small coins can still require
consolidation. RC2 does not add a guided or automatic consolidation flow for
that reported case. The abandoned-transaction icon has not been replaced.
These notes do not claim that every reported synchronization problem or
external wallet, pool or service issue has been resolved.

The scheduled Thaw Day rules, mining difficulty, block rewards and the $1
minimum DigiDollar output are unchanged from RC1. New minting status messages
report current conditions; a successful mint does not make a later warning
incorrect if those conditions change.

Before installing a published build, back up wallets and configuration, verify
the published signed checksums, and stop the old program normally. Keep the
required DigiDollar block history. Use the release's reviewed recovery
instructions if an older candidate stopped on a rejected block.

Report ordinary problems with the version, network, block height, expected
result and relevant logs with private information removed. Use
the private security-reporting instructions for sensitive
reports.

RC1 — preserved release notes

The following is the unchanged RC1 note from tag v9.26.6rc1, commit
390f71d5cb74bf519dc0510cc5d8e9c70fefa3cc. Its version, counts, dates,
measurements and test results refer to RC1. The RC2 section above gives the
RC2 additions, combined count and verification limits.

DigiByte Core v9.26.6 release notes

Current version: v9.26.6rc1. This is the first release candidate: a test
build before the final release.

Summary

v9.26.6 includes 83 fixes and improvements. It improves wallet recovery,
DigiDollar (DD) sending and redemption, wallet displays, node stability, price
services, memory use and startup. The count also includes tests and documentation.

Node and mining operators must upgrade before mainnet block 24,490,000,
expected around November 1, 2026. This applies even if you only use DGB.

Thaw Day changes consensus: the rules nodes use to agree on valid blocks.
Older software may follow a different chain after the change.

We are testing Thaw Day on testnet first. The final mainnet release follows
the remaining tests and release review.

What you need to do

1. Read the upgrade notes below. Check scripts that send DD amounts and
   make sure the node has enough disk space.
2. Back up your wallets and keep existing backups. Keep your configuration
   and oracle keys too.
3. Verify the build, then replace the old program. Check the release's
   signed checksums. Stop the old node normally and wait for it to exit first.
   RC1 is for the test exercise; use the approved final build for the mainnet rollout.
4. Let startup finish. The node may need to check or rebuild accounting.
   Do not mistake a long scan for a stopped program.
5. Check the running node. Confirm its version, network, sync progress and
   Thaw Day height. Check any wallet or oracle service you operate.

Full nodes, miners, pools, exchanges, oracle services and wallet backends need
the update. If a provider runs your wallet or exchange service, check its
upgrade notice.

Thaw Day: testnet first, then mainnet

The block number starts the change. The date is an estimate. Faster or
slower block production can move that date. The old rules remain below the
height, including when old blocks are checked again.

Release files and instructions must be available at least 3 days before
testnet activation and 14 days before mainnet activation. Track block
progress during that time.

There is no miner vote or local public-network setting to change Thaw Day.
Postponing it requires a replacement build and coordinated upgrades before
the original height. Editing an announcement cannot postpone installed software.

The testnet exercise will check the switch itself, minting, transfers,
redemptions, oracle prices and agreement between independent nodes. Tests also
cover restarts and chain changes, where recent blocks are replaced by another
branch. Public testnet activation and observation have not yet finished.

To check your node's schedule:

digibyte-cli getdigidollardeploymentinfo
digibyte-cli -testnet getdigidollardeploymentinfo

The result shows the height and whether the rules apply to the current tip
or next block. The tip is the latest block on that node's chain.

Upgrade details that matter

Amounts sent by scripts

Four commands accept amount_unit: senddigidollar,
sendmanydigidollar, redeemdigidollar and getredemptioninfo.
The amount filters in listdigidollarpositions and
listdigidollaraddresses use it too.

Existing scripts using whole cents keep working. Scripts using decimals
must specify dollars. The new unit argument goes last in a positional call.
For example, this requests a $250.00 send:

digibyte-cli -named senddigidollar address="<DigiDollar address>" amount="250.00" amount_unit="dollars"

mintdigidollar still takes whole cents.

The $1 minimum DD output is unchanged. The $100,000 request limit
applies to a single send, each sendmany recipient and a requested redemption.
It does not limit the extra DD the rules may require burning in an emergency
redemption. A redemption still closes the whole vault.

Minting and redemption after Thaw Day

A vault is DGB locked to back newly minted DigiDollars. Oracles provide
the signed DGB prices used by DigiDollar.

At Thaw Day, a new price check replaces the old mint freeze. It uses prices
already recorded in the chain. Transfers and redemptions stop using the old
volatility freeze, but their other requirements still apply.

New mints still need an accepted oracle price, enough collateral and a price
that passes the new check. Large price swings can still pause minting.

Health will count the original DD amounts attached to vaults that remain open.
DD still in circulation is a separate total. Extra DD burned during redemption
can make circulation smaller than the amount attached to open vaults.

This can lower health, keep emergency restrictions in place longer or require
more DD to redeem than the old calculation. Check the current estimate before
confirming. Thaw Day itself creates no tokens and changes no wallet balances.

Wallets and service integrations

• Minting needs the modern descriptor wallet format, private keys and supported
  receiving and change addresses. The wallet explains missing support early.
• Existing wallets can still send and redeem if they hold the needed keys.
  Recovery of a missing key record cannot replace a missing private key.
• CSV exports add Amount ($DD). Position status can include expired_mint,
  abandoned_mint and conflicted_mint.
• Statistics separate open_vault_principal from circulating supply.
  selected_health_denominator identifies the total used for health.
  An unavailable total is not zero.
• Oracle signing keys and required agreement stay the same.
• Use -debug=digidollar if your log tools need routine DD details.
  Errors and startup progress remain visible without it.

Disk space, startup and recovery

Pruning deletes older block files to save space. A pruned node must still keep
DigiDollar's required history. On mainnet, the retention floor remains
23,627,520. Required blocks and the data used to reverse them must stay.

That history can exceed a small prune target. The target is not a hard disk
limit, and this release does not add a warning for every overrun. Leave room
for growth and check actual disk use.

An ordinary upgrade with the required data does not need a full reindex.
A reindex rebuilds the node's chain databases from block history. A late
upgrade may need extra checks; missing files need restoration or download.
Repeated restarts cannot supply missing data.

If recovery fails, keep the error, logs, wallets and block files. Pause any
automatic restart loop while the cause is checked. After Thaw Day, downgrading
to old software is not a repair. If nodes disagree, compare block hashes at
the same height and coordinate recovery before resuming settlement.

Feather's RAM improvements work on installation. On Unix, the new database
file allowance may expose a low system open-file limit. Check that limit if
startup reports it or reduces connections.

All 83 fixes and improvements

Each entry states the change and the reason. Related repairs are grouped.
These are implemented changes, not a claim that every outside bug report is fixed.

Thaw Day and DigiDollar accounting

New block rules wait for Thaw Day. Status reporting and preparation are available before it.

1. Change: All new DigiDollar block rules start at one Thaw Day height on each network.
   Why: Nodes need to change rules at the same point.

2. Change: Status shows the scheduled height and whether the current or next block uses the new rules.
   Why: Operators can see when their node reaches Thaw Day.

3. Change: At Thaw Day, new mints use earlier block prices to check for large price swings.
   Why: Nodes checking the same chain need the same minting reference.

4. Change: At Thaw Day, transfers and redemptions stop using the old volatility freeze.
   Why: The minting price safeguard should not apply that freeze to these operations.

5. Change: At Thaw Day, checks use the prices, coins and history belonging to the block being checked.
   Why: A restart or a different branch must not change the inputs to that block's checks.

6. Change: At Thaw Day, health counts the original DD amounts attached to vaults still open.
   Why: The system needs a consistent measure of what those vaults back.

7. Change: Vault totals are saved with chain data and updated as blocks are added or reversed.
   Why: Accounting must stay with the right chain through restarts and interrupted saves.

8. Change: At Thaw Day, validation and recovery give each vault the same transaction-based identity.
   Why: Both paths must find the same vault.

9. Change: Recovery checks saved vault totals and unchecked Thaw Day history, and rebuilds totals from available records when needed.
   Why: Late upgrades and interrupted recovery must finish their checks before using the results.

10. Change: Status separates DD still in circulation from the amounts attached to open vaults.
    Why: Burning extra tokens can make these two totals differ.

11. Change: From Thaw Day, saved circulating-supply totals are checked against chain records and repaired when needed.
    Why: An incorrect saved total should not keep carrying forward.

12. Change: Coin scans use a consistent order and read older accepted vault records consistently.
    Why: Recent changes saved at different times must still give the same accounting totals.

Node crashes, hangs and transaction sharing

Dandelion is DigiByte's system for passing transactions between nodes.

1. Change: Fixes a Dandelion crash when recent blocks are replaced by another chain branch.
   Why: Pending transaction records must remain usable during a chain change.

2. Change: Fixes hangs during transaction-sharing checks, peer disconnections and incoming announcements.
   Why: Tasks running at the same time must not get stuck waiting for each other.

3. Change: Protects shared transaction records when the usual Dandelion relay peer is unavailable.
   Why: The fallback send path must handle those records safely too.

4. Change: After loading a saved chain state, the relay checks pending transactions against that chain.
   Why: The relay must follow the chain the node is using.

5. Change: Fixes conflicting wallet and chain locks during wallet loading, imports, rescans and DigiDollar checks.
   Why: Wallet work and chain work must not block each other indefinitely.

Wallet recovery, sending and redemption

1. Change: Saves a mint's owner key and recovery records before sending the transaction.
   Why: The recovery information must be saved before the mint can reach the network.

2. Change: Rebuilds a missing vault-key record from a matching key already in the wallet.
   Why: A missing record should not stop redemption when the correct key still exists.

3. Change: Refuses to replace a vault's saved owner key with a different key.
   Why: Existing vault ownership records must stay intact.

4. Change: Reports an error if the key for a new DigiDollar address cannot be saved.
   Why: The wallet should save the required key before offering the address.

5. Change: Releases eligible coins reserved by failed, abandoned or expired mints, including after restart.
   Why: Unsuccessful mints should not leave spendable DGB reserved forever.

6. Change: Keeps mint keys and recovery history during cleanup and checks whether the mint can still confirm.
   Why: A later confirmation or chain change can make that history necessary again.

7. Change: Labels expired, abandoned and conflicted mints separately from completed redemptions.
   Why: Users need to distinguish a failed mint from a closed vault.

8. Change: Saves affected transaction states together when abandoning a transaction, and reports failed saves.
   Why: An incomplete save must not look successful or release coins incorrectly.

9. Change: Coordinates simultaneous mint and redemption requests so they do not select the same coins.
   Why: One request should not conflict with another before either has finished.

10. Change: Calculates redemption fees from the transaction being built and selects more fee coins when needed.
    Why: Many small DGB coins can make a transaction larger than a fixed estimate.

11. Change: Explains when small DGB coins cost more in fees than they can contribute.
    Why: Users need to know when to combine small coins instead of retrying.

12. Change: Stops a mint or send if required DGB change has no usable destination.
    Why: Leftover funds must not go to an address invented by the builder.

13. Change: Checks the redemption address and keeps leftover fee money in the sending wallet.
    Why: Collateral may go to a chosen external address; fee change should stay in the wallet.

14. Change: Adds explicit cents or dollars to four amount commands and two filters, with checks for invalid amounts.
    Why: A decimal point must not silently change the amount being requested.

15. Change: Rejects sends, requested redemptions and redemption estimates above $100,000; sendmany keeps its per-recipient cap.
    Why: The limit should be checked early and match between estimates and submitted requests.

16. Change: Prevents large amounts from overflowing wallet totals, displayed collateral ratios and collateral diagnostic calculations.
    Why: Overflow can turn a large number into a misleading small or negative number.

17. Change: Explains missing minting support before confirmation or passphrase prompts.
    Why: Users should know their wallet cannot mint before approving the operation.

18. Change: Eight more DigiDollar wallet commands wait for the wallet to process the latest block.
    Why: A newly confirmed balance or transaction should not be missed.

19. Change: Mint and redemption estimates follow the next block's rules and explain unavailable or restricted conditions.
    Why: The estimate should use the same rules as the transaction builder.

20. Change: Loads compatible saved fee estimates correctly after restart.
    Why: The node should keep the useful fee history it already learned.

Desktop wallet displays and buttons

1. Change: The Redeem button on a locked wallet opens the passphrase prompt.
   Why: An owner needs to unlock the wallet to redeem; wallets without private keys still cannot sign.

2. Change: Shows redemption results and mint refusals in dialogs.
   Why: Important messages must be visible even without desktop notifications.

3. Change: Redemption success messages show the transaction ID and explain that collateral returns after confirmation.
   Why: Sending a transaction is different from confirming it.

4. Change: Shows wallet-created mints with separate rows for DD created, DGB locked and the network fee.
   Why: A mint should not look like money sent out and back, or count its fee as collateral.

5. Change: Shows the DGB fee for a DigiDollar transfer on its own row.
   Why: A DGB fee should not disappear into a dollar amount.

6. Change: Gives DGB and DigiDollar separate columns in transaction tables and CSV exports.
   Why: Each currency needs its own value for sorting and exporting.

7. Change: Uses the correct currency for copied amounts, overview entries and notifications.
   Why: A DigiDollar payment should not appear as zero DGB.

8. Change: Keeps DigiDollar rows visible when the DGB minimum-amount filter is used.
   Why: A filter for DGB amounts should not hide dollar transactions.

9. Change: Restores saved column widths after loading the table and keeps the DD column visible.
   Why: Opening the wallet should preserve the layout and show both currencies.

10. Change: Transaction details show DD amounts, vault information, lock periods and the actual mint collateral, even with reordered outputs.
    Why: Users need the actual transaction details instead of misleading zero amounts.

11. Change: Gives returned DD its own row, labelled “DigiDollar change returned,” with an explanation.
    Why: Extra selected DD comes back as change; the vault still closes in full.

12. Change: Keeps showing the confirmation count after a DigiDollar transaction is confirmed.
    Why: The count remains useful after the first few confirmations.

13. Change: Keeps amounts typed above the send limit and explains why they cannot be sent.
    Why: Dropping the final digit could leave a smaller amount than intended.

14. Change: Allows full DigiDollar addresses to be typed and corrected in the send form.
    Why: The old partial-address cutoff could prevent entry of a valid address.

Oracle price services

1. Change: Fixes an alternate way of combining oracle public keys and keeps cached results tied to the right network settings.
   Why: Price verification must use the intended keys and settings.

2. Change: Starts oracle services before other tasks use them and waits for those tasks before destroying the services.
   Why: Background work must not use a service that is not ready or has already stopped.

3. Change: Retries stored public signing messages when the first send had no connected peer.
   Why: Signing should recover when a connection becomes available.

4. Change: Protects oracle settings and the current signing period from conflicting reads and changes.
   Why: Tasks running together must not read settings while another task changes them.

5. Change: Shows oracle operator names from the selected network's list.
   Why: Operators should be easy to recognize without changing their keys or signing rules.

RAM and disk use

The block index is the node's directory of known blocks. A header is a block's short summary.

1. Change: Removes eight mining lookup pointers from each block's memory record.
   Why: Finding earlier blocks through existing links saves permanent RAM.

2. Change: Reads less-used saved block details from disk and keeps a limited set of recent reads in RAM.
   Why: Every block no longer needs those details in memory all the time.

3. Change: Stores mining work scores in less space, with an exact full-size value when needed.
   Why: Saving RAM must not round the score used to choose a chain.

4. Change: Gives block records space in shared memory chunks and removes unnecessary lookup bookkeeping.
   Why: Millions of separate allocations waste space.

5. Change: Reads needed parts of database files while still checking for incomplete or damaged data.
   Why: The node can avoid whole-file memory mappings without dropping those checks.

6. Change: Reserves open-file capacity for databases before assigning it to network connections.
   Why: Database and network work need to share the system's file limit.

7. Change: Uses a smaller sorted copy of changed coins during accounting scans.
   Why: The scan needs a stable copy, but not the previous extra lookup table.

8. Change: Keeps unsaved headers in RAM and saves block and reversal data before recording their disk locations.
   Why: A failed save must not lose pending data or point to an unfinished file write.

9. Change: Handles missing or unreadable local block headers as storage errors.
   Why: A local disk failure must not be blamed on another node's block.

Startup, recovery and mining

1. Change: Loads the block directory without first reading it only to count its entries.
   Why: Startup can begin loading straight away and report the count as it goes.

2. Change: Reads the last saved block before building lists of possible chain ends.
   Why: Startup avoids making a large list it would immediately discard.

3. Change: Avoids repeated warning calculations for old periods that cannot trigger the warning.
   Why: Startup does less work while keeping checks at the boundary and afterward.

4. Change: Reuses processed oracle price records and avoids repeating completed startup work.
   Why: The same records should not need repeated parsing and setup.

5. Change: Shows reconstruction progress, allows cancellation and keeps incomplete results marked as not ready.
   Why: Users need to see progress without mistaking a partial scan for a finished one.

6. Change: Stops startup with specific recovery information when required history cannot be read.
   Why: Repeated restarts cannot replace missing block or reversal data.

7. Change: Keeps the required DigiDollar history through chain changes, including when no blocks can yet be pruned.
   Why: Deleting old files must not remove records still needed to check transactions.

8. Change: Prepares starting Thaw Day totals when the preceding block is added, rather than for every mining request.
   Why: Miners should not repeatedly scan all coins while asking for work.

Logs, tests and instructions

1. Change: Moves routine DigiDollar, oracle and wallet messages into debug logs and removes three repeated transaction messages.
   Why: Normal logs should stay readable while retaining errors and startup progress.

2. Change: Stops reporting a false key-write error when re-saving the same key during a payment to the same wallet.
   Why: A successful payment should not look like a failed save.

3. Change: Documents the DD fields returned by raw-transaction commands so their result checks also work.
   Why: Command help and automated checks need to match the actual output.

4. Change: Lets source-reading tests find the checkout from a different working directory.
   Why: The directory used to launch a test should not cause a false failure.

5. Change: Corrects test setup for pruning, low-numbered ports, fees, script rules and Thaw Day.
   Why: Tests must use the intended network rules and data.

6. Change: Captures and checks errors from tests that deliberately cause storage failures.
   Why: Successful error tests should not print unexplained fatal-error messages.

7. Change: Adds checks for activation, accounting, extra burns, restarts, chain changes, wallet recovery, oracle retries and memory use.
   Why: These tests help catch future changes that break the repairs.

8. Change: Fixes the supplied configuration example and refreshes command help and manuals.
   Why: The example must load correctly and describe the available settings.

9. Change: Updates node, wallet, exchange and oracle instructions for upgrades, recovery, amounts and accounting.
   Why: Operators need instructions for the behavior added in this release.

10. Change: Adds setup steps for nodes sharing a router and for block-filter services used by lightweight wallets.
    Why: Correct ports and service settings help those setups work; this does not claim a mobile-wallet code fix.

Tests completed and work still ahead

These are the recorded results for source commit
d2097819f260f4d82409643fe9f7263cdd7e3eaa:

Unit tests check pieces of the program. Functional tests run nodes and check
how they behave. Fuzz tests try many inputs to find unexpected behavior.
A skipped test is not a pass.

One RC1 desktop run settled at about 3.65–3.67 GiB of RAM and started in
108 seconds. These figures describe that workload. They do not predict
startup on every computer or the cost of the future Thaw Day accounting scan.

Before the final mainnet release, complete the full mainnet history replay,
public testnet activation and observation, remaining platform checks and final
release review.

Some reports about mobile wallets, pools and outside services still need those
projects' investigation. Mining difficulty, block rewards and the $1 DD output
minimum are unchanged by this release.

Reporting a problem

Include the version, network, block height and hash, what you expected, what
happened and relevant log lines. Remove private information from logs first.
Report security-sensitive details through the project's private security
channel, rather than a public bug report.