How to un-crash-loop your Dash Core node
Since the point release containing the EvoDB crash fix was promised on Sep 22 and has yet to materialize:
The problem
Run Dash Core v23.1.8 (the version still wearing the "Latest" badge on GitHub, which is a bold choice) for about 24 hours of continuous uptime and, at any 576-block disk-snapshot boundary, it aborts:
Assertion failed! evo/evodb.cpp line 59: Expression: curDBTransaction.IsClean()
This is issue #7549 (dash#7549) — a credit-pool snapshot written outside the block-scoped EvoDB transaction, corrupting the database at a boundary you hit roughly once a day. Not from a bad shutdown, not from a power cut, not from anything you did. Just for running the software.
The crash loop
The fun part: after it aborts, Dash Core won't start again. Startup verification finds the inconsistency and refuses:
*** Found EvoDB inconsistency, you must reindex to continue
Welcome to the loop. Fix → crash 24h later → loop.
The fix (Windows)
Your wallet is fine — this only rebuilds chain databases. Close Dash Core, then in PowerShell:
& "C:\Program Files\DashCore\dash-qt.exe" -datadir=D:\path\to\your\datadir -reindex-chainstate -txindex=0
If you use the default datadir, drop the -datadir part. If you don't run txindex, drop -txindex=0. Then wait: on a decent SSD, roughly two days. Yes, really. Enjoy the progress-per-hour readout.
Linux equivalent
dashd -reindex-chainstate -txindex=0
# or for the GUI:
dash-qt -reindex-chainstate -txindex=0
The speedrun (2 minutes instead of 2 days)
If you have access to another healthy v23.1.8 node, you can copy its chainstate and evodb folders over yours (node stopped, obviously) and skip the reindex. Make sure the donor node is actually healthy and has recently passed a 576-boundary cleanly — copying a corrupted snapshot just gives you the same crash with extra steps.
Prevention options
1. Restart Dash Core before each ~24h boundary. Luddite, but effective.
2. Run the v24 rc.4 pre-release (published Oct 19, contains the fix). It's an RC — that's on you.
3. Wait for the promised v23.1.x backport, which as of today is still a sentence in a September issue comment rather than a release.
Bug reference for the curious: #7549 (dash#7549), closed Sep 22 as "fixed for v24," with the maintainer's own note that v23.1.8 "will keep hitting this at height % 576 == 0 boundaries" and the backport "will go in a v23.1.x point release." It has. Not. Yet.
7 points
Mentions
Dash Platform v5.0.0 is released 🥳 Snip from Discord #Announcements This is the biggest release since Platform started with v1.0.0. Please be sure to read the three blog posts regarding this release and what features it adds, and read the release notes very carefully. ❗ ❗Blog post: dash.org❗ ❗ Github link: github.com/dashpay/platform/releases/tag/v5.0.0 Discord link: discord.com Quick start guide: dash.org Check your evonode status: mnowatch.org AMD64/x86 (linux): wget https://github.com/dashpay/platform/releases/download/v5.0.0/dashmate_5.0.0.389dd6a16e-1_amd64.deb sudo apt update sudo apt install ./dashmate_5.0.0.389dd6a16e-1_amd64.deb dashmate stop --safe dashmate update dashmate start ARM64 (linux): wget https://github.com/dashpay/platform/releases/download/v5.0.0/dashmate_5.0.0.389dd6a16e-1_arm64.deb sudo apt update sudo apt install ./dashmate_5.0.0.389dd6a16e-1_arm64.deb dashmate stop --safe dashmate update dashmate start
How to un-crash-loop your Dash Core node Since the point release containing the EvoDB crash fix was promised on Sep 22 and has yet to materialize: The problem Run Dash Core v23.1.8 (the version still wearing the "Latest" badge on GitHub, which is a bold choice) for about 24 hours of continuous uptime and, at any 576-block disk-snapshot boundary, it aborts: Assertion failed! evo/evodb.cpp line 59: Expression: curDBTransaction.IsClean() This is issue #7549 (dash#7549) — a credit-pool snapshot written outside the block-scoped EvoDB transaction, corrupting the database at a boundary you hit roughly once a day. Not from a bad shutdown, not from a power cut, not from anything you did. Just for running the software. The crash loop The fun part: after it aborts, Dash Core won't start again. Startup verification finds the inconsistency and refuses: *** Found EvoDB inconsistency, you must reindex to continue Welcome to the loop. Fix → crash 24h later → loop. The fix (Windows) Your wallet is fine — this only rebuilds chain databases. Close Dash Core, then in PowerShell: & "C:\Program Files\DashCore\dash-qt.exe" -datadir=D:\path\to\your\datadir -reindex-chainstate -txindex=0 If you use the default datadir, drop the -datadir part. If you don't run txindex, drop -txindex=0. Then wait: on a decent SSD, roughly two days. Yes, really. Enjoy the progress-per-hour readout. Linux equivalent dashd -reindex-chainstate -txindex=0 # or for the GUI: dash-qt -reindex-chainstate -txindex=0 The speedrun (2 minutes instead of 2 days) If you have access to another healthy v23.1.8 node, you can copy its chainstate and evodb folders over yours (node stopped, obviously) and skip the reindex. Make sure the donor node is actually healthy and has recently passed a 576-boundary cleanly — copying a corrupted snapshot just gives you the same crash with extra steps. Prevention options 1. Restart Dash Core before each ~24h boundary. Luddite, but effective. 2. Run the v24 rc.4 pre-release (published Oct 19, contains the fix). It's an RC — that's on you. 3. Wait for the promised v23.1.x backport, which as of today is still a sentence in a September issue comment rather than a release. Bug reference for the curious: #7549 (dash#7549), closed Sep 22 as "fixed for v24," with the maintainer's own note that v23.1.8 "will keep hitting this at height % 576 == 0 boundaries" and the backport "will go in a v23.1.x point release." It has. Not. Yet.
Dash shielded tokens hit release candidates: what they would and wouldn't hide Dash says its next Evolution version adds shielded token support, naming stablecoins as an example, and the Platform v5.0.0 builds are still release candidates with no release date given (GitHub releases). Dash's own docs say a transfer inside the shielded pool hides sender, receiver and amount, but observers can still see that you used the pool, and amounts going in and out are public (Dash docs). Per the developer notes, each token gets its own pool, so the token type isn't hidden either (PR #4760). Dash's own guidance is that shielded to shielded is best, while going in and straight back out with matching amounts is the weakest pattern. None of this is released or independently verified yet.