DanS 5634aed750 wallet: open salvaged wallets in a degraded mode, and detect a mismatched hdchain
A wallet.dat repaired by v1.0.3-or-earlier -salvagewallet could not be opened by
this build at all. Those builds' IsKeyType has no "hdchain" case, so salvage
dropped the record; LoadWallet then returned DB_CORRUPT and told the user to
restore from a seed phrase. There is no such recovery path: the node aborts
before the RPC server exists, -usemnemonic defaulted to 0 in v1.0.3 so many of
these wallets never had a phrase, and SetHDSeedFromMnemonic refuses a non-empty
wallet, so "move wallet.dat aside" discards every non-HD key salvage preserved.

The guard itself was right to refuse to DERIVE -- a missing hdchain falls back to
SetNull defaults, clearing fMnemonicSeed and switching derivation from the
64-byte BIP39 seed to the raw 32-byte entropy, an entirely different key tree.
It was wrong to refuse to OPEN. Split the two:

  - "hdchain" record ABSENT (the salvage signature, tracked by a new
    wss.fHDChainSeen set before any parse attempt) -> open DEGRADED.
  - "hdchain" record PRESENT but unreadable -> still DB_CORRUPT; that signals
    wider file damage.

Degraded means the wallet spends, receives and rescans normally but refuses to
derive any new HD key. Gated at the single choke point GetHDSeedForDerivation
rather than at the two generators, so z_getnewaddress/sendmany/shieldcoinbase
raise a clean error and autoshield skips. hdChain.seedFp is deliberately left
null, which keeps IsHDTransparentEnabled false so getnewaddress falls back to the
legacy random-key path -- gating it instead would break TopUpKeyPool, change
addresses and block templates. -rescan is soft-set because an old salvage also
dropped defaultkey and bestblock, which would otherwise look like a first run and
skip the rescan, leaving a permanently zero balance.

NEW DETECTOR, covering strictly more damage than the guard beside it. A wallet
salvaged by v1.0.3 and then USED on v1.0.3 persists a SetNull-derived hdchain
carrying seedFp=null. On this build fHDChainRead is then true, the guard never
fires, the node starts perfectly clean -- and derives into the wrong key tree
forever, silently. That state is unforgeable by any legitimate writer, since
InstallHDSeed always stores seedFp = seed.Fingerprint(), so compare the loaded
chain's seedFp against the fingerprint taken from the hdseed/chdseed record KEY
(which works while an encrypted wallet is locked) and degrade on mismatch.

Also:
  - init.cpp: abort in the DB_CORRUPT branch itself, as DB_NEED_REWRITE already
    does. Falling through ran several hundred more lines against a wallet just
    declared corrupt, including SetHDSeedOrigin(), which WRITES to it. Error text
    no longer advises -mnemonic (wrong twice over, see above).
  - rpcdump.cpp: z_exportwallet discarded GetHDSeedForDerivation's return and
    emitted the line regardless, so a failure wrote a blank seed next to a
    legitimate-looking BLAKE2b-of-empty fingerprint -- a backup that looks valid
    and restores nothing.
  - Corrected the guard's comment: the saplingAccountCounter half was overstated.
    Both generators loop while(Have...Key(...)), so a low counter walks forward
    past existing accounts rather than colliding with them.

qa/r4-salvaged-wallet-harness.sh builds the victim wallets with the on-disk
v1.0.1 release binary and asserts the behaviour end to end. It REFUSES to run
outside a network namespace and re-checks getconnectioncount==0, because those
old binaries predate the regtest seed-injection fix and would otherwise dial the
live network. 11/11 pass:

  C healthy wallet opens and is NOT flagged   (no false positives)
  A salvaged wallet opens, flagged, persists no hdchain, z_getnewaddress refused,
    getnewaddress still works, z_exportwallet emits no bogus HDSeed line
  B poisoned wallet opens and the seedFp detector fires

Note the harness asserts "no hdchain synthesised", NOT "wallet.dat unchanged":
a control run showed normal startup rewrites wallet.dat for healthy wallets too.

This is the access/detection half. Proving fMnemonicSeed by re-deriving against
held keys, and repairing the record, is deliberately left out: it requires a
write, and the affected population is unmeasured. dev's own salvage already
preserves hdchain, so the class is closed going forward.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FU87LdsJZiZkfq1eXubpeo
2026-08-31 13:29:43 -05:00
2021-01-26 08:56:08 -05:00
2024-02-27 23:59:59 +01:00
2024-03-15 15:14:26 -04:00
2024-03-31 23:54:32 +02:00
2019-08-07 04:56:24 -07:00
2019-08-07 04:56:24 -07:00
2026-01-01 15:24:57 -05:00
2017-10-22 04:08:53 +02:00

DragonX

DragonX

A fully-private, RandomX CPU-mineable cryptocurrency.

Introduction Build Run Mine
What is DragonX? Build from source Run a node CPU mining
Key facts Install a release Fastest sync Wallets

What is DragonX?

DragonX implements extreme privacy via blockchain technology. It is private from genesis: every ordinary transaction is shielded (z2z), so your transaction metadata stays private. DragonX is based on Bitcoin code with Zcash's zero-knowledge Sapling cryptography, and its defining feature is RandomX Proof-of-Work — it is mined with a CPU, not ASICs or GPUs.

DragonX has its own genesis block. Its lineage is Bitcoin → Zcash → Komodo → Hush → DragonX; it is a fork of the Hush full node, with the Proof-of-Work changed from Equihash to RandomX and privacy enforced from the very first block.

This software is the DragonX full node and command-line client. It downloads and stores the entire history of DragonX transactions; depending on your computer and network connection this can take a while, so most users start from the bootstrap snapshot.

DragonX is experimental software. Use at your own risk, just like Bitcoin.

Key facts

Ticker DRAGONX
Proof-of-Work RandomX (CPU-mineable)
Privacy fully private from genesis (ac_private=1, Sapling active at height 1)
Block time 36 seconds
Block reward 3 DRAGONX, halving every 3,500,000 blocks
Max block size 4 MB
RPC port 21769
P2P port 18030
Data directory ~/.hush/DRAGONX (Linux)
Config file DRAGONX.conf
Binaries dragonxd, dragonx-cli, dragonx-tx

Fastest way to sync (bootstrap)

The quickest way to get a fully-synced node is the signed bootstrap snapshot, which installs a pre-built blockchain so you skip re-validating the whole chain from genesis:

# Stop dragonxd first if it is running, then:
./util/bootstrap-dragonx.sh

The script preserves your wallet.dat and DRAGONX.conf, verifies the download's checksums and (once a release key is published) its cryptographic signature, then starts you near the chain tip. If you prefer to sync from the network instead, a larger -dbcache (e.g. -dbcache=2048) noticeably speeds up the initial block download.

Build from source

Building uses 3 build processes by default; you need ~2GB of RAM for each.

Debian or Ubuntu

sudo apt-get install build-essential pkg-config libc6-dev m4 g++-multilib \
      autoconf libtool ncurses-dev unzip git zlib1g-dev wget \
      bsdmainutils automake curl unzip nano libsodium-dev cmake
git clone https://git.dragonx.is/DragonX/dragonx
cd dragonx
./build.sh -j3

Arch

sudo pacman -S gcc libsodium lib32-zlib unzip wget git python rust curl autoconf cmake
git clone https://git.dragonx.is/DragonX/dragonx
cd dragonx
./build.sh -j3

Fedora

sudo dnf install make automake gcc gcc-c++ kernel-devel cmake libtool ncurses-devel patch -y
git clone https://git.dragonx.is/DragonX/dragonx
cd dragonx
./build.sh -j3

macOS

Install Xcode Command Line Tools and Homebrew, then:

xcode-select --install
brew install gcc autoconf automake pkgconf libtool cmake curl

# Install Rust (needed for librustzcash on macOS Sequoia+)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"

git clone https://git.dragonx.is/DragonX/dragonx
cd dragonx
# Make sure libtool gnubin and cargo are on PATH
export PATH="$HOME/.cargo/bin:/usr/local/opt/libtool/libexec/gnubin:$PATH"
./build.sh -j3

For a release build:

export PATH="$HOME/.cargo/bin:/usr/local/opt/libtool/libexec/gnubin:$PATH"
./build.sh --mac-release -j$(sysctl -n hw.ncpu)

Windows (cross-compiled on Linux)

sudo apt-get install \
      build-essential pkg-config libc6-dev m4 g++-multilib libdb++-dev \
      autoconf libtool ncurses-dev unzip git zip \
      zlib1g-dev wget bsdmainutils automake mingw-w64 cmake libsodium-dev
git clone https://git.dragonx.is/DragonX/dragonx
cd dragonx
./util/build-win.sh -j$(nproc)

ARM (Raspberry Pi)

Any ARMv7 machine cannot build this repo because the underlying zk-SNARK library does not support that instruction set. You need an ARMv8-based board (Raspberry Pi 4 or newer). Either install an aarch64 release package (see below) or cross-compile from amd64.

Installing DragonX binaries

  1. Download a release with a .deb extension.
  2. Install it, substituting the version you downloaded: sudo dpkg -i dragonx-VERSION-amd64.deb (or -aarch64.deb on ARM).
  3. Run with: dragonxd.

Running a node

Start the daemon:

./src/dragonxd

It stores data in ~/.hush/DRAGONX and reads ~/.hush/DRAGONX/DRAGONX.conf. Query it with ./src/dragonx-cli, for example:

./src/dragonx-cli getinfo

To run DragonX as a background service, see doc/dragonxd-systemd.md.

CPU mining (RandomX)

DragonX is CPU-mineable via RandomX (the same algorithm family as Monero); ASICs and GPUs do not apply. To mine with your node, enable generation and choose how many threads to use:

# mine with 4 CPU threads
./src/dragonxd -gen=1 -genproclimit=4

or add to DRAGONX.conf:

gen=1
genproclimit=4

Mining rewards arrive as transparent coinbase, which is directly spendable; you can optionally move it into the shielded pool with z_shieldcoinbase (see doc/shield-coinbase.md). For more on the algorithm and its tuning options, see doc/randomx.md.

Wallets

The DragonX full node includes a built-in wallet, managed via dragonx-cli (see doc/wallet-backup.md and doc/seed-phrase.md).

Graphical and mobile wallets:

DragonX light and mobile wallets use BIP39 seed phrases that are compatible with the full node — see doc/seed-phrase.md.

Support and links

License

For license information see the file COPYING.

Description
No description provided
Readme 187 MiB
2026-07-23 20:06:47 -05:00
Languages
C++ 66.2%
C 21.4%
Python 6.5%
M4 1.4%
Shell 1.2%
Other 3.1%