docs: rebrand documentation, packaging, and helper scripts to DragonX

The docs/packaging were largely un-rebranded Hush3 content, with several
docs stating facts that are wrong for DragonX. This rewrites them against
the verified DragonX source state.

Corrections (not just branding):
- PoW: RandomX (CPU), not Equihash/ASIC — README, overview.md, randomx.md
- Privacy: private from genesis (ac_private=1, Sapling@height1), not "as of
  block 340000" — overview.md, payment-api.md
- Removed the false "coinbase must be shielded" consensus claim
  (shield-coinbase.md, payment-api.md); coinbase is directly spendable
- Fixed default fee 0.0001 (was 0.0010000, 10x); stratum port 22769 (was 19031)
- datadir ~/.hush/DRAGONX, DRAGONX.conf, dragonxd/dragonx-cli/dragonx-tx,
  git.dragonx.is throughout; branch model dev->dragonx
- Softened the inherited dPoW reorg claim (no live DragonX notary infra)

Packaging: fix build-debian-package.sh + gen-manpages.sh to use the dragonx
binaries/manpages; rename bash-completions to dragonx*; drop hush-arrakis-chain
from the package. Keep /usr/share/hush (hardcoded in the binary for params).

Also: README links/logo, ObsidianDragon + SilentDragonXAndroid wallets,
networking/init/dev-process/contrib/util rebrand, and leftover helper scripts.
Delete legacy duplicates (hushd.* init/service, HUSH3.conf examples,
OLD_WALLETS.md, hsc.md) and rename hush-uri.bat -> dragonx-uri.bat.

Out of scope (noted, not changed): historical changelog/copyright, the Hush
mainnet airdrop snapshot, seed data files, depends/ source mirrors, and the
in-code strCurrencyUnits="HUSH".

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

ISSUE_TEMPLATE.md

@@ -1,8 +1,8 @@
 <!--- Remove text and sections that do not apply -->
 
-This issue tracker is only for technical issues related to hushd
+This issue tracker is only for technical issues related to dragonxd
 
-General Hush questions and/or support requests and are best directed to [Telegram](https://hush.is/telegram_support)
+General DragonX questions and/or support requests are best directed to [Telegram](https://dragonx.is/tg) or [Matrix](https://dragonx.is/matrix).
 
 ### Describe the issue
 
@@ -23,9 +23,9 @@ Tell us what should happen
 
 Tell us what happens instead including any noticable error output (any messages displayed on-screen when e.g. a crash occurred)
 
-### The version of Hush you were using:
+### The version of DragonX you were using:
 
-Run `hushd --version` to find out
+Run `dragonxd --version` to find out
 
 ### Machine specs:
 - OS name + version:
@@ -38,7 +38,7 @@ Run `hushd --version` to find out
 
 ### Any extra information that might be useful in the debugging process.
 
-This includes the relevant contents of `~/.hush/HUSH3/debug.log` or `~/.komodo/HUSH3/debug.log` if you have a legacy install. You can paste raw text, attach the file directly in the issue or link to the text via a pastebin type site.
+This includes the relevant contents of `~/.hush/DRAGONX/debug.log`. You can paste raw text, attach the file directly in the issue or link to the text via a pastebin type site.
 Please also include any non-standard things you did during compilation (extra flags, dependency version changes etc.) if applicable.
 
 Beware that usernames and IP addresses and other metadata is definitely in this log file!

README.md

@@ -1,31 +1,51 @@
 <p align="center">
-  <img src="doc/hush/hush0.png">
+  <img src="doc/dragonx/logo_dragonx_128.png" alt="DragonX" width="128">
 </p>
+<h1 align="center">DragonX</h1>
+<p align="center"><b>A fully-private, RandomX CPU-mineable cryptocurrency.</b></p>
 
-<h3>
+<h3 align="center">
 
-| Introduction | Install | Compile | FAQ | Documentation |
+| Introduction | Build | Run | Mine |
-| :---:         | :---:   | :---: | :---: | :---: |
+| :---: | :---: | :---: | :---: |
-| [What is Hush?](#what-is-hush) | [Windows 10 - Video Tutorial](#install-on-windows-10) | [Build on Debian or Ubuntu](#build-on-debian-or-ubuntu) | [Where can I buy Hush?](#where-can-i-buy-hush) | [Cross compiling Windows binaries](#windows-cross-compiled-on-linux)
+| [What is DragonX?](#what-is-dragonx) | [Build from source](#build-from-source) | [Run a node](#running-a-node) | [CPU mining](#cpu-mining-randomx) |
-| [Why not GitHub?](#banned-by-github) | [Build on Mac](#build-on-mac) | [Build on Arch](#build-on-arch) | [Can I mine with CPU or GPU?](#can-i-mine-with-cpu-or-gpu) | [Hush DevOps for pools and CEXs](https://git.hush.is/hush/docs/src/branch/master/advanced/devops.md)
+| [Key facts](#key-facts) | [Install a release](#installing-dragonx-binaries) | [Fastest sync](#fastest-way-to-sync-bootstrap) | [Wallets](#wallets) |
-| [What is HushChat?](#what-is-hushchat) | [Debian and Ubuntu](#installing-hush-binaries) | [Build on Fedora](#build-on-fedora) | [Claiming funds from old Hush wallets](https://git.hush.is/hush/hush3/src/branch/master/doc/OLD_WALLETS.md) | [Earn Hush bounty](#earn-hush-bounty)
-| [What is SilentDagon?](#what-is-silentdagon) | [Raspberry Pi](#install-on-arm-architecture) | [Build on Ubuntu 16.04 or older](#building-on-ubuntu-16-04-and-older-systems) | [Where can I spend Hush?](#where-can-i-spend-hush) | [Cross compiling from amd64 to arm64](https://git.hush.is/hush/docs/src/branch/master/advanced/cross-compile-hush-full-node-to-aarch64-with-docker.md)
 
 </h3>
 
-# What is Hush?
+# What is DragonX?
 
-Hush implements Extreme Privacy via blockchain tech. We have our own
+DragonX implements extreme privacy via blockchain technology. It is **private from
-genesis block. We are not a chain fork (copy) of another coin. We are based on
+genesis**: every ordinary transaction is shielded (`z2z`), so your transaction metadata
-Bitcoin code, with sophisticated zero-knowledge mathematics added for privacy.
+stays private. DragonX is based on Bitcoin code with Zcash's zero-knowledge Sapling
-This keeps your transaction metadata private!
+cryptography, and its defining feature is **RandomX Proof-of-Work — it is mined with a
+CPU**, not ASICs or GPUs.
 
-# What is this repository?
+DragonX has its own genesis block. Its lineage is Bitcoin → Zcash → Komodo → Hush → DragonX;
+it is a fork of the [Hush](https://git.hush.is/hush/hush3) full node, with the Proof-of-Work
+changed from Equihash to RandomX and privacy enforced from the very first block.
 
-This software is the Hush node and command-line client. It downloads and stores
+This software is the DragonX full node and command-line client. It downloads and stores the
-the entire history of Hush transactions; depending on the speed of your
+entire history of DragonX transactions; depending on your computer and network connection
-computer and network connection, it will likely take a few hours at least, but
+this can take a while, so most users start from the [bootstrap snapshot](#fastest-way-to-sync-bootstrap).
-some people report full nodes syncing in less than 1.5 hours.
+
+**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)
 
@@ -42,86 +62,42 @@ checksums and (once a release key is published) its cryptographic signature, the
 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.
 
-# Banned by GitHub
+# Build from source
 
-In working on this release, Duke Leto was suspended from Github, which gave Hush developers
+Building uses 3 build processes by default; you need ~2GB of RAM for each.
-the impetus to completely leave that racist and censorship-loving platform. Hush now has it's own [git.hush.is](https://git.hush.is/hush) Gitea instance,
-because we will not be silenced by Microsoft. All Hush software will be released from git.hush.is and hush.is, downloads from any other
-domains should be assumed to be backdoored.
 
-**Hush is unfinished and highly experimental.** Use at your own risk! Just like Bitcoin.
+### Debian or Ubuntu
-
-# Build on Debian or Ubuntu
 
 ```sh
-# install build dependencies
 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
-# clone git repo
+git clone https://git.dragonx.is/DragonX/dragonx
-git clone https://git.hush.is/hush/hush3
+cd dragonx
-cd hush3
-# Build
-# This uses 3 build processes, you need 2GB of RAM for each. 
 ./build.sh -j3
 ```
-Video Tutorial: https://videos.hush.is/videos/how-to-install-on-linux
 
-# Build on Arch
+### Arch
 
 ```sh
-# install build dependencies
 sudo pacman -S gcc libsodium lib32-zlib unzip wget git python rust curl autoconf cmake
-# clone git repo
+git clone https://git.dragonx.is/DragonX/dragonx
-git clone https://git.hush.is/hush/hush3
+cd dragonx
-cd hush3
-# Build
-# This uses 3 build processes, you need 2GB of RAM for each. 
 ./build.sh -j3
 ```
 
-# Build on Fedora
+### Fedora
 
 ```sh
-# install build dependencies
 sudo dnf install make automake gcc gcc-c++ kernel-devel cmake libtool ncurses-devel patch -y
-# clone git repo
+git clone https://git.dragonx.is/DragonX/dragonx
-git clone https://git.hush.is/hush/hush3
+cd dragonx
-cd hush3
-# Build
-# This uses 3 build processes, you need 2GB of RAM for each. 
 ./build.sh -j3
 ```
 
-# Install on Windows 10
+### macOS
 
-Video Tutorial: https://videos.hush.is/videos/how-to-install-on-windows
+Install Xcode Command Line Tools and [Homebrew](https://brew.sh/), then:
-
-# Install on ARM Architecture
-
-Use this if you have a Raspberry Pi or similar computer. Currently, any ARMv7 machine will not be able to build this repo, because the underlying tech (zcash and the zksnark library) do not support that instruction set. This also means that old RaspberryPi devices will not work, unless they have a newer ARMv8-based Raspberry Pi. Raspberry Pi 4 and newer are known to work.
-
-1. [Download the latest Debian package with the AARCH64 designation from the releases page](https://git.hush.is/hush/hush3/releases).
-1. Install the Debian package, substituting "VERSION-NUMBER" for the version you have downloaded: `sudo dpkg -i hush-VERSION-NUMBER-aarch64.deb`.
-1. Run with: `hushd`.
-
-If you would like to compile this for ARM yourself, then please refer to the [Cross compiling a Hush full node daemon from AMD64 to ARM64(aarch64) CPU architecture with Docker](https://git.hush.is/jahway603/hush-docs/src/branch/master/advanced/cross-compile-hush-full-node-to-aarch64-with-docker.md) documentation to do that.
-
-# Building On Ubuntu 16.04 and older systems
-
-Some older compilers may not be able to compile modern code, such as gcc 5.4 which comes with Ubuntu 16.04 by default. Here is how to install gcc 7 on Ubuntu 16.04. Run these commands as root:
-
-```
-add-apt-repository ppa:ubuntu-toolchain-r/test && \
-apt update && \
-apt-get install -y gcc-7 g++-7 && \
-  update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-7 60 && \
-  update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 60
-```
-
-# Build on Mac
-
-Install Xcode Command Line Tools and [Homebrew](https://brew.sh/), then install dependencies:
 
 ```sh
 xcode-select --install
@@ -131,10 +107,8 @@ brew install gcc autoconf automake pkgconf libtool cmake curl
 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
 source "$HOME/.cargo/env"
 
-# clone git repo
+git clone https://git.dragonx.is/DragonX/dragonx
-git clone https://git.hush.is/hush/hush3
+cd dragonx
-cd hush3
-# Build (uses 3 build processes, you need 2GB of RAM for each)
 # Make sure libtool gnubin and cargo are on PATH
 export PATH="$HOME/.cargo/bin:/usr/local/opt/libtool/libexec/gnubin:$PATH"
 ./build.sh -j3
@@ -147,77 +121,92 @@ export PATH="$HOME/.cargo/bin:/usr/local/opt/libtool/libexec/gnubin:$PATH"
 ./build.sh --mac-release -j$(sysctl -n hw.ncpu)
 ```
 
-# Installing Hush binaries
+### Windows (cross-compiled on Linux)
 
-1. [Download the release](https://git.hush.is/hush/hush3/releases) with a .deb file extension.
+```sh
-1. Install the Debian package, substituting "VERSION-NUMBER" for the version you have downloaded: `sudo dpkg -i hush-VERSION-NUMBER-amd64.deb`.
-1. Run with: `hushd`.
-
-# Windows (cross-compiled on Linux)
-Get dependencies:
-```ssh
 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)
 ```
 
-Downloading Git source repo, building and running Hush:
+### 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](https://git.dragonx.is/DragonX/dragonx/releases) with a `.deb` extension.
+1. Install it, substituting the version you downloaded:
+   `sudo dpkg -i dragonx-VERSION-amd64.deb` (or `-aarch64.deb` on ARM).
+1. Run with: `dragonxd`.
+
+# Running a node
+
+Start the daemon:
 
 ```sh
-# pull
+./src/dragonxd
-git clone https://git.hush.is/hush/hush3
-cd hush3
-# Build
-./util/build-win.sh -j$(nproc)
-# Run a HUSH node
-./src/hushd
 ```
 
-# Official Explorers
+It stores data in `~/.hush/DRAGONX` and reads `~/.hush/DRAGONX/DRAGONX.conf`. Query it with
+`./src/dragonx-cli`, for example:
 
-The links for the Official Hush explorers:
+```sh
-  * [explorer.hush.is](https://explorer.hush.is)
+./src/dragonx-cli getinfo
+```
 
-# What is SilentDragon?
+To run DragonX as a background service, see [doc/dragonxd-systemd.md](doc/dragonxd-systemd.md).
 
-* [SilentDragon](https://git.hush.is/hush/SilentDragon) is a desktop wallet for HUSH full node.<br>
+# CPU mining (RandomX)
-* [SilentDragonLite](https://git.hush.is/hush/SilentDragonLite) is a desktop wallet that does not require you to download the full blockchain.
-* [SilentDragonAndroid](https://git.hush.is/hush/SilentDragonAndroid) is a wallet for Android devices.
-* [SilentDragonPaper](https://git.hush.is/hush/SilentDragonPaper) is a paper wallet generator that can be run completely offline.
 
-# What is HushChat?
+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:
 
-HushChat is a protocol inspired by the design of Signal Protocol, it uses many of the same cryptography and ideas, but does not actually use any code from Signal. Signal requires phone numbers and is a centralized service. HushChat is completely anonymous and decentralized and requires absolutely no metadata be given to any centralized third parties.
+```sh
+# mine with 4 CPU threads
+./src/dragonxd -gen=1 -genproclimit=4
+```
 
-# Can I mine with CPU or GPU?
+or add to `DRAGONX.conf`:
 
-Hush cannot be efficiently mined with CPU or GPU, only ASIC mining is recommended. HUSH uses Equihash (200,9) algo, as does Zcash, Horizen or Komodo.
+```
+gen=1
+genproclimit=4
+```
 
-# Where can I buy Hush?
+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](doc/shield-coinbase.md)). For more on the algorithm and its tuning
+options, see [doc/randomx.md](doc/randomx.md).
 
-1. https://nonkyc.io/market/HUSH_BTC
+# Wallets
-1. https://tradeogre.com/exchange/BTC-HUSH
 
-# Where can I spend Hush?
+The DragonX full node includes a built-in wallet, managed via `dragonx-cli` (see
+[doc/wallet-backup.md](doc/wallet-backup.md) and [doc/seed-phrase.md](doc/seed-phrase.md)).
 
-AgoraX market: https://agorax.is
+Graphical and mobile wallets:
 
-# Earn Hush bounty
+* **[ObsidianDragon](https://git.dragonx.is/DragonX/ObsidianDragon/releases)** — desktop wallet, available in both full-node and light-wallet modes.
+* **[SilentDragonXAndroid](https://git.dragonx.is/DragonX/SilentDragonXAndroid/releases)** — wallet for Android devices.
 
-Developers can earn bounty by fixing bugs or solving feature requests listed in `Issues->Label`:
+DragonX light and mobile wallets use BIP39 seed phrases that are compatible with the full
-- https://git.hush.is/hush/hush3/issues
+node — see [doc/seed-phrase.md](doc/seed-phrase.md).
-- https://git.hush.is/hush/SilentDragon/issues
-- https://git.hush.is/hush/SilentDragonLite/issues
 
-![Logo](doc/hush/earnhush.png "Hush Bounty")
+# Support and links
 
-# Support and Socials
+* Website: https://dragonx.is
-
+* Source code: https://git.dragonx.is/DragonX
-* Telegram: [https://hush.is/tg](https://hush.is/tg)
+* Block explorer: https://explorer.dragonx.is
-* Matrix: [https://hush.is/matrix](https://hush.is/matrix)
+* Issues / bounties: https://git.dragonx.is/DragonX/dragonx/issues
-* Twitter: [https://hush.is/twitter](https://hush.is/twitter)
+* Telegram: https://dragonx.is/tg
-* PeerTube [https://hush.is/peertube](https://hush.is/peertube)
+* Matrix: https://dragonx.is/matrix
+* Twitter / X: https://twitter.com/DragonXchain
 
 # License
 

contrib/README.md

@@ -1,16 +1,14 @@
-# Hush Contrib
+# DragonX Contrib
 
-This is mostly very old stuff inherited from Bitcoin and Zcash!
+This directory contains various supporting tools and scripts. Much of this is
+old material inherited from the Bitcoin/Zcash/Komodo/Hush lineage, so not every
+script is guaranteed to work. Please fix bugs and report anything you find.
 
-Do not expect all scripts to work!
+# DragonX Tools
-
-Please fix bugs and report things you find.
-
-# Hush Tools
 
 ## block\_time.pl
 
-Estimate when a Hush block will happen.
+Estimate when a DragonX block will happen.
 
 Example:
 
@@ -19,65 +17,49 @@ Example:
 ## gen-zaddrs.pl
 
 Generate zaddrs in bulk, by default 50 at a time. Prints out a zaddr one per line.
+Useful on a fully-private chain where shielded addresses are the norm.
 
 Example:
 
     ./contrib/gen-zaddrs.pl     # generate 50 zaddrs
     ./contrib/gen-zaddrs.pl 500 # generate 500 zaddrs
 
-
-## Wallet Tools
-
-### [BitRPC](/contrib/bitrpc) ###
-Allows for sending of all standard Bitcoin commands via RPC rather than as command line args.
-
-### [SpendFrom](/contrib/spendfrom) ###
-
-Use the raw transactions API to send coins received on a particular
-address (or addresses).
-
 ## Repository Tools
 
-### [Developer tools](/contrib/devtools) ###
+### [Verify-Commits](/contrib/verify-commits)
-Specific tools for developers working on this repository.
+Tool to verify that merge commits were signed by a developer.
-Contains the script `github-merge.sh` for merging github pull requests securely and signing them using GPG.
 
-### [Verify-Commits](/contrib/verify-commits) ###
+### [Linearize](/contrib/linearize)
-Tool to verify that every merge commit was signed by a developer using the above `github-merge.sh` script.
-
-### [Linearize](/contrib/linearize) ###
 Construct a linear, no-fork, best version of the blockchain.
 
-### [Qos](/contrib/qos) ###
+### [Qos](/contrib/qos)
+A Linux bash script that sets up traffic control (tc) to limit the outgoing
+bandwidth for connections to the DragonX network. This lets you run an
+always-on dragonxd instance and have another local dragonxd connect to it and
+receive blocks from it.
 
-A Linux bash script that will set up traffic control (tc) to limit the outgoing bandwidth for connections to the Bitcoin network. This means one can have an always-on bitcoind instance running, and another local bitcoind/bitcoin-qt instance which connects to this node and receives blocks from it.
+### [Seeds](/contrib/seeds)
-
+Utility to generate the seed node array that is compiled into the client.
-### [Seeds](/contrib/seeds) ###
-Utility to generate the pnSeed[] array that is compiled into the client.
 
 ## Build Tools and Keys
 
-### [Debian](/contrib/debian) ###
+### [Debian](/contrib/debian)
-Contains files used to package bitcoind/bitcoin-qt
+Contains files used to package dragonxd for Debian-based Linux systems.
-for Debian-based Linux systems. If you compile bitcoind/bitcoin-qt yourself, there are some useful files here.
 
-### [Gitian-descriptors](/contrib/gitian-descriptors) ###
+### [Gitian-descriptors](/contrib/gitian-descriptors)
-Gavin's notes on getting gitian builds up and running using KVM.
+Legacy notes on getting gitian builds running. Note that the real DragonX build
+path is `./build.sh` together with the `depends/` system; gitian is legacy.
 
 ### [Gitian-downloader](/contrib/gitian-downloader)
-Various PGP files of core developers. 
+Various PGP files of developers.
 
-### [MacDeploy](/contrib/macdeploy) ###
+### [MacDeploy](/contrib/macdeploy)
-Scripts and notes for Mac builds. 
+Scripts and notes for Mac builds.
 
-## Test and Verify Tools 
+## Test and Verify Tools
 
-### [TestGen](/contrib/testgen) ###
+### [TestGen](/contrib/testgen)
-Utilities to generate test vectors for the data-driven Bitcoin tests.
+Utilities to generate test vectors for the data-driven base58 tests.
 
-### [Test Patches](/contrib/test-patches) ###
+### [Verify SF Binaries](/contrib/verifysfbinaries)
-These patches are applied when the automated pull-tester
+Legacy SourceForge-era signature verification script (unused for DragonX).
-tests each pull and when master is tested using jenkins.
-
-### [Verify SF Binaries](/contrib/verifysfbinaries) ###
-This script attempts to download and verify the signature file SHA256SUMS.asc from SourceForge.

contrib/avg_blocktime.pl

@@ -5,7 +5,7 @@
 
 use warnings;
 use strict;
-my $cli     = "./src/hush-cli";
+my $cli     = "./src/dragonx-cli";
 my $coin    = shift || '';
 unless (-e $cli) {
     die "$cli does not exist, aborting";

contrib/block_time.pl

@@ -8,17 +8,17 @@ use strict;
 # Given a block height, estimate when it will happen
 my $block      = shift || die "Usage: $0 123";
 my $coin       = shift || '';
-my $hush       = "./src/hush-cli";
+my $cli        = "./src/dragonx-cli";
-unless (-e $hush) {
+unless (-e $cli) {
-    die "$hush does not exist, aborting";
+    die "$cli does not exist, aborting";
 }
 if ($coin) {
-    $hush .= " -ac_name=$coin";
+    $cli .= " -ac_name=$coin";
 }
-my $blockcount = qx{$hush getblockcount};
+my $blockcount = qx{$cli getblockcount};
 
 unless ($blockcount = int($blockcount)) {
-    print "Invalid response from $hush\n";
+    print "Invalid response from $cli\n";
     exit 1;
 }
 
@@ -28,7 +28,7 @@ if ($block <= $blockcount) {
 	my $diff    = $block - $blockcount;
     # TODO: support custom blocktimes
     # assumes HACs use default blocktime of 60s
-    my $minpb   = $coin ? 1 : 1.25; # 75s in minutes for HUSH3
+    my $minpb   = $coin ? 1 : 0.6; # 36s in minutes for DragonX
 	my $minutes = $diff*$minpb;
 	my $seconds = $minutes*60;
 	my $now     = time;
@@ -38,7 +38,7 @@ if ($block <= $blockcount) {
     if ($coin) {
 	    print "$coin Block $block will happen at roughly:\n";
     } else {
-	    print "Hush Block $block will happen at roughly:\n";
+	    print "DragonX Block $block will happen at roughly:\n";
     }
 	print "$ldate Eastern # $then\n";
 	print "$gmdate GMT     # $then\n";

contrib/convert_address.py

@@ -11,7 +11,7 @@ from hashlib import sha256
 # based on https://github.com/KMDLabs/pos64staker/blob/master/stakerlib.py#L89
 def addr_convert(prefix, address, prefix_bytes):
     rmd160_dict  = {}
-    # ZEC/HUSH/etc have 2 prefix bytes, BTC/KMD only have 1
+    # ZEC/DRAGONX/etc have 2 prefix bytes, BTC/KMD only have 1
     # NOTE: any changes to this code should be verified against https://dexstats.info/addressconverter.php
     ripemd       = b58decode_check(address).hex()[2*prefix_bytes:]
     net_byte     = prefix + ripemd
@@ -23,7 +23,7 @@ def addr_convert(prefix, address, prefix_bytes):
     return(final.decode())
 
 if len(sys.argv) < 2:
-    sys.exit('Usage: %s hushv2address' % sys.argv[0])
+    sys.exit('Usage: %s dragonxv2address' % sys.argv[0])
 
 address = sys.argv[1]
 # convert given address to a KMD address

contrib/debian/examples/HUSH3.conf

@@ -1,209 +0,0 @@
-## HUSH3.conf configuration file. Lines beginning with # are comments.
-
-# Network-related settings:
-
-# Run a regression test network
-#regtest=0
-# Run a test node (which means you can mine with no peers)
-#testnode=1
-
-#set a custom client name/user agent
-#clientName=GoldenSandtrout
-
-# Rescan from block height
-#rescan=123
-
-# Connect via a SOCKS5 proxy
-#proxy=127.0.0.1:9050
-
-# Automatically create Tor hidden service
-#listenonion=1
-
-#Use separate SOCKS5 proxy to reach peers via Tor hidden services
-#onion=1.2.3.4:9050
-
-# Only connect to nodes in network <net> (ipv4, ipv6, onion or i2p)"));
-#onlynet=<net>
-
-#Tor control port to use if onion listening enabled
-#torcontrol=127.0.0.1:9051
-
-# Bind to given address and always listen on it. Use [host]:port notation for IPv6
-#bind=<addr>
-
-# Bind to given address and allowlist peers connecting to it. Use [host]:port notation for IPv6
-#allowbind=<addr>
-
-##############################################################
-##            Quick Primer on addnode vs connect            ##
-##  Let's say for instance you use addnode=4.2.2.4          ##
-##  addnode will connect you to and tell you about the      ##
-##    nodes connected to 4.2.2.4.  In addition it will tell ##
-##    the other nodes connected to it that you exist so     ##
-##    they can connect to you.                              ##
-##  connect will not do the above when you 'connect' to it. ##
-##    It will *only* connect you to 4.2.2.4 and no one else.##
-##                                                          ##
-##  So if you're behind a firewall, or have other problems  ##
-##  finding nodes, add some using 'addnode'.                ##
-##                                                          ##
-##  If you want to stay private, use 'connect' to only      ##
-##  connect to "trusted" nodes.                             ##
-##                                                          ##
-##  If you run multiple nodes on a LAN, there's no need for ##
-##  all of them to open lots of connections.  Instead       ##
-##  'connect' them all to one node that is port forwarded   ##
-##  and has lots of connections.                            ##
-##       Thanks goes to [Noodle] on Freenode.               ##
-##############################################################
-
-# Use as many addnode= settings as you like to connect to specific peers
-#addnode=69.164.218.197
-#addnode=10.0.0.2:8233
-
-# Alternatively use as many connect= settings as you like to connect ONLY to specific peers
-#connect=69.164.218.197
-#connect=10.0.0.1:8233
-
-# Listening mode, enabled by default except when 'connect' is being used
-#listen=1
-
-# Maximum number of inbound+outbound connections.
-#maxconnections=
-
-#
-# JSON-RPC options (for controlling a running hushd process)
-#
-
-# server=1 tells node to accept JSON-RPC commands (set as default if not specified)
-#server=1
-
-# Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6.
-# This option can be specified multiple times (default: bind to all interfaces)
-#rpcbind=<addr>
-
-# You must set rpcuser and rpcpassword to secure the JSON-RPC api
-# These will automatically be created for you
-#rpcuser=user
-#rpcpassword=supersecretpassword
-
-# How many seconds node will wait for a complete RPC HTTP request.
-# after the HTTP connection is established. 
-#rpcclienttimeout=30
-
-# By default, only RPC connections from localhost are allowed.
-# Specify as many rpcallowip= settings as you like to allow connections from other hosts,
-# either as a single IPv4/IPv6 or with a subnet specification.
-
-# NOTE: opening up the RPC port to hosts outside your local trusted network is NOT RECOMMENDED,
-# because the rpcpassword is transmitted over the network unencrypted and also because anyone 
-# that can authenticate on the RPC port can steal your keys + take over the account running hushd
-
-#rpcallowip=10.1.1.34/255.255.255.0
-#rpcallowip=1.2.3.4/24
-#rpcallowip=2001:db8:85a3:0:0:8a2e:370:7334/96
-
-# Listen for RPC connections on this TCP port:
-#rpcport=1234
-
-# You can use hushd to send commands to hushd
-# running on another host using this option:
-#rpcconnect=127.0.0.1
-
-# Transaction Fee
-
-# Send transactions as zero-fee transactions if possible (default: 0)
-#sendfreetransactions=0
-
-# Create transactions that have enough fees (or priority) so they are likely to # begin confirmation within n blocks (default: 1).
-# This setting is overridden by the -paytxfee option.
-#txconfirmtarget=n
-
-# Miscellaneous options
-
-# Enable mining at startup
-#gen=1
-
-# Set the number of threads to be used for mining (-1 = all cores).
-#genproclimit=1
-
-# Specify a different Equihash solver (e.g. "tromp") to try to mine
-# faster when gen=1.
-#equihashsolver=default
-
-# Pre-generate this many public/private key pairs, so wallet backups will be valid for
-# both prior transactions and several dozen future transactions.
-#keypool=100
-
-# Pay an optional transaction fee every time you send a tx.  Transactions with fees
-# are more likely than free transactions to be included in generated blocks, so may
-# be validated sooner. This setting does not affect private transactions created with 
-# 'z_sendmany'.
-#paytxfee=0.00
-
-#Rewind the chain to specific block height. This is useful for creating snapshots at a given block height.
-#rewind=555
-
-#Stop the chain a specific block height. This is useful for creating snapshots at a given block height.
-#stopat=1000000
-
-#Set an address to use as change address for all transactions. This value must be set to a 33 byte pubkey. All mined coins will also be sent to this address.
-#pubkey=027dc7b5cfb5efca96674b45e9fda18df069d040b9fd9ff32c35df56005e330392
-
-# Disable clearnet (ipv4 and ipv6) connections to this node
-#clearnet=0
-
-# Disable ipv4
-#disableipv4=1
-# Disable ipv6
-#disableipv6=1
-
-# Enable transaction index
-#txindex=1
-# Enable address index
-#addressindex=1
-# Enable timestamp index
-#timestampindex=1
-# Enable spent index
-#spentindex=1
-
-# Enable shielded stats index
-#zindex=1
-
-# Attempt to salvage a corrupt wallet
-# salvagewallet=1
-
-# Mine all blocks to this address (not good for your privacy and not recommended!)
-# Disallowed if clearnet=0
-# mineraddress=XXX
-
-# Disable wallet
-#disablewallet=1
-
-# Allow mining to an address that is not in the current wallet
-#minetolocalwallet=0
-
-# Delete all wallet transactions
-#zapwallettxes=1
-
-# Enable sapling consolidation
-# consolidation=1
-
-# Enable stratum server
-# stratum=1
-
-# Run a command each time a new block is seen
-# %s in command is replaced by block hash
-#blocknotify=/my/awesome/script.sh %s
-
-# Run a command when wallet gets a new tx
-# %s in command is replaced with txid
-#walletnotify=/my/cool/script.sh %s
-
-# Run a command when tx expires
-# %s in command is replaced with txid
-#txexpirynotify=/my/elite/script.sh %s
-
-# Execute this commend to send a tx
-# %s is replaced with tx hex
-#txsend=/send/it.sh %s

contrib/debian/hush.example

@@ -1 +0,0 @@
-DEBIAN/examples/HUSH3.conf

contrib/debian/hush.install

@@ -1,3 +0,0 @@
-usr/bin/hushd
-usr/bin/hush-cli
-usr/bin/hush-tx

contrib/debian/hush.manpages

@@ -1,3 +0,0 @@
-DEBIAN/manpages/hush-cli.1
-DEBIAN/manpages/hush-tx.1
-DEBIAN/manpages/hushd.1

contrib/dragonx-cli.bash-completion

@@ -1,11 +1,11 @@
-# bash programmable completion for hush-cli(1)
+# bash programmable completion for dragonx-cli(1)
 # Copyright (c) 2012-2016 The Bitcoin Core developers
 # Copyright (c) 2018-2020 The Hush developers
 # Distributed under the GPLv3 software license, see the accompanying
 # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
 
-# call $hush-cli for RPC
+# call $dragonx-cli for RPC
-_hush_rpc() {
+_dragonx_rpc() {
     # determine already specified args necessary for RPC
     local rpcargs=()
     for i in ${COMP_LINE}; do
@@ -15,25 +15,25 @@ _hush_rpc() {
                 ;;
         esac
     done
-    $hush_cli "${rpcargs[@]}" "$@"
+    $dragonx_cli "${rpcargs[@]}" "$@"
 }
 
 # Add wallet accounts to COMPREPLY
-_hush_accounts() {
+_dragonx_accounts() {
     local accounts
-    # Accounts are deprecated in hush
+    # Accounts are deprecated in dragonx
-    #accounts=$(_hush_rpc listaccounts | awk -F '"' '{ print $2 }')
+    #accounts=$(_dragonx_rpc listaccounts | awk -F '"' '{ print $2 }')
     accounts="\\\"\\\""
     COMPREPLY=( "${COMPREPLY[@]}" $( compgen -W "$accounts" -- "$cur" ) )
 }
 
-_hush_cli() {
+_dragonx_cli() {
     local cur prev words=() cword
-    local hush_cli
+    local dragonx_cli
 
-    # save and use original argument to invoke hush-cli for -help, help and RPC
+    # save and use original argument to invoke dragonx-cli for -help, help and RPC
-    # as hush-cli might not be in $PATH
+    # as dragonx-cli might not be in $PATH
-    hush_cli="$1"
+    dragonx_cli="$1"
 
     COMPREPLY=()
     _get_comp_words_by_ref -n = cur prev words cword
@@ -63,7 +63,7 @@ _hush_cli() {
     if ((cword > 3)); then
         case ${words[cword-3]} in
             addmultisigaddress)
-                _hush_accounts
+                _dragonx_accounts
                 return 0
                 ;;
             getbalance|gettxout|importaddress|importpubkey|importprivkey|listreceivedbyaccount|listreceivedbyaddress|listsinceblock)
@@ -92,7 +92,7 @@ _hush_cli() {
                 return 0
                 ;;
             move|setaccount)
-                _hush_accounts
+                _dragonx_accounts
                 return 0
                 ;;
         esac
@@ -108,7 +108,7 @@ _hush_cli() {
             return 0
             ;;
         getaccountaddress|getaddressesbyaccount|getbalance|getnewaddress|getreceivedbyaccount|listtransactions|move|sendfrom|sendmany)
-            _hush_accounts
+            _dragonx_accounts
             return 0
             ;;
     esac
@@ -132,12 +132,12 @@ _hush_cli() {
 
             # only parse -help if senseful
             if [[ -z "$cur" || "$cur" =~ ^- ]]; then
-                helpopts=$($hush_cli -help 2>&1 | awk '$1 ~ /^-/ { sub(/=.*/, "="); print $1 }' )
+                helpopts=$($dragonx_cli -help 2>&1 | awk '$1 ~ /^-/ { sub(/=.*/, "="); print $1 }' )
             fi
 
             # only parse help if senseful
             if [[ -z "$cur" || "$cur" =~ ^[a-z] ]]; then
-                commands=$(_hush_rpc help 2>/dev/null | awk '$1 ~ /^[a-z]/ { print $1; }')
+                commands=$(_dragonx_rpc help 2>/dev/null | awk '$1 ~ /^[a-z]/ { print $1; }')
             fi
 
             COMPREPLY=( $( compgen -W "$helpopts $commands" -- "$cur" ) )
@@ -150,7 +150,7 @@ _hush_cli() {
             ;;
     esac
 } &&
-complete -F _hush_cli hush-cli
+complete -F _dragonx_cli dragonx-cli
 
 # Local variables:
 # mode: shell-script

contrib/dragonx-tx.bash-completion

@@ -1,15 +1,15 @@
-# bash programmable completion for hush-tx(1)
+# bash programmable completion for dragonx-tx(1)
 # Copyright (c) 2016 The Bitcoin Core developers
 # Distributed under the GPLv3 software license, see the accompanying
 # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
 
-_hush_tx() {
+_dragonx_tx() {
     local cur prev words=() cword
-    local hush_tx
+    local dragonx_tx
 
-    # save and use original argument to invoke hush-tx for -help
+    # save and use original argument to invoke dragonx-tx for -help
     # it might not be in $PATH
-    hush_tx="$1"
+    dragonx_tx="$1"
 
     COMPREPLY=()
     _get_comp_words_by_ref -n =: cur prev words cword
@@ -27,15 +27,15 @@ _hush_tx() {
 
     if [[ "$cword" == 1 || ( "$prev" != "-create" && "$prev" == -* ) ]]; then
         # only options (or an uncompletable hex-string) allowed
-        # parse hush-tx -help for options
+        # parse dragonx-tx -help for options
         local helpopts
-        helpopts=$($hush_tx -help | sed -e '/^  -/ p' -e d )
+        helpopts=$($dragonx_tx -help | sed -e '/^  -/ p' -e d )
         COMPREPLY=( $( compgen -W "$helpopts" -- "$cur" ) )
     else
         # only commands are allowed
         # parse -help for commands
         local helpcmds
-        helpcmds=$($hush_tx -help | sed -e '1,/Commands:/d' -e 's/=.*/=/' -e '/^  [a-z]/ p' -e d )
+        helpcmds=$($dragonx_tx -help | sed -e '1,/Commands:/d' -e 's/=.*/=/' -e '/^  [a-z]/ p' -e d )
         COMPREPLY=( $( compgen -W "$helpcmds" -- "$cur" ) )
     fi
 
@@ -46,7 +46,7 @@ _hush_tx() {
 
     return 0
 } &&
-complete -F _hush_tx hush-tx
+complete -F _dragonx_tx dragonx-tx
 
 # Local variables:
 # mode: shell-script

contrib/dragonx-uri.bat

@@ -8,8 +8,8 @@ Exit
 :RegExport
 Set RegFile="%Temp%\~etsaclu.tmp"
 
-Set "hush=%~dp0"
+Set "dragonx=%~dp0"
-set "hush=%hush:\=\\%"
+set "dragonx=%dragonx:\=\\%"
 
 If Exist %RegFile% (
  Attrib -R -S -H %RegFile% &  Del /F /Q %RegFile%
@@ -17,19 +17,19 @@ If Exist %RegFile% (
 )
 > %RegFile% Echo Windows Registry Editor Version 5.00
 >> %RegFile% Echo.
->> %RegFile% Echo [HKEY_CLASSES_ROOT\hush]
+>> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx]
->> %RegFile% Echo @="URL:hush protocol"
+>> %RegFile% Echo @="URL:dragonx protocol"
 >> %RegFile% Echo "URL Protocol"=""
 >> %RegFile% Echo.
->> %RegFile% Echo [HKEY_CLASSES_ROOT\hush\DefaultIcon]
+>> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx\DefaultIcon]
 >> %RegFile% Echo @="silentdragon.exe"
 >> %RegFile% Echo.
->> %RegFile% Echo [HKEY_CLASSES_ROOT\hush\Shell]
+>> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx\Shell]
 >> %RegFile% Echo.
->> %RegFile% Echo [HKEY_CLASSES_ROOT\hush\Shell\Open]
+>> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx\Shell\Open]
 >> %RegFile% Echo.
->> %RegFile% Echo [HKEY_CLASSES_ROOT\hush\Shell\Open\Command]
+>> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx\Shell\Open\Command]
->> %RegFile% Echo @="%hush%silentdragon.exe \"%%1\""
+>> %RegFile% Echo @="%dragonx%silentdragon.exe \"%%1\""
 
 Start /Wait %systemroot%\Regedit.exe /S %RegFile%
 Del %RegFile%

contrib/dragonxd.bash-completion

@@ -1,17 +1,17 @@
-# bash programmable completion for hushd(1)
+# bash programmable completion for dragonxd(1)
 # Copyright (c) 2012-2017 The Bitcoin Core developers
 # Copyright (c) 2016-2017 The Zcash developers
 # Copyright (c) 2018      The Hush developers
 # Distributed under the GPLv3 software license, see the accompanying
 # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
 
-_hushd() {
+_dragonxd() {
     local cur prev words=() cword
-    local hushd
+    local dragonxd
 
-    # save and use original argument to invoke hushd for -help
+    # save and use original argument to invoke dragonxd for -help
     # it might not be in $PATH
-    hushd="$1"
+    dragonxd="$1"
 
     COMPREPLY=()
     _get_comp_words_by_ref -n = cur prev words cword
@@ -35,7 +35,7 @@ _hushd() {
             # only parse -help if senseful
             if [[ -z "$cur" || "$cur" =~ ^- ]]; then
                 local helpopts
-                helpopts=$($hushd -help 2>&1 | awk '$1 ~ /^-/ { sub(/=.*/, "="); print $1 }' )
+                helpopts=$($dragonxd -help 2>&1 | awk '$1 ~ /^-/ { sub(/=.*/, "="); print $1 }' )
                 COMPREPLY=( $( compgen -W "$helpopts" -- "$cur" ) )
             fi
 
@@ -47,7 +47,7 @@ _hushd() {
             ;;
     esac
 } &&
-complete -F _hushd hushd
+complete -F _dragonxd dragonxd
 
 # Local variables:
 # mode: shell-script

contrib/fresh_clone_compile_and_run.sh

@@ -11,19 +11,19 @@
 
 BRANCH=$1
 
-git clone https://git.hush.is/hush/hush3
+git clone https://git.dragonx.is/DragonX/dragonx
-cd hush3
+cd dragonx
 git checkout $BRANCH
 # You need 2GB of RAM per core, don't use too many
-# (GB of RAM)/2 - 1 is the optimal core count for compiling Hush
+# (GB of RAM)/2 - 1 is the optimal core count for compiling DragonX
 # `nproc` tells you how many cores you have
 JOBS=$2
 JOBZ=$(nproc) # if build.sh fails, we can use many more jobs with make
-# Want to fix this parrallel-only build system bug we inherited ? you are a new hush dev
+# Want to fix this parrallel-only build system bug we inherited ? you are a new DragonX dev
 # Sometimes the parrallel build fails because of a race condition, so
 # we do it a few times to Make Really Sure
 ./build.sh -j$JOBS;make -j$JOBZ;make -j$JOBZ;make -j$JOBZ
-./src/hushd &> hush.log &
+./src/dragonxd &> dragonx.log &
-# You can give the entire or parts of this file to Hush developers for debugging,
+# You can give the entire or parts of this file to DragonX developers for debugging,
 # but there is a lot of metadata!!! We don't want any more than we need to fix bugz
-tail -f hush.log
+tail -f dragonx.log

contrib/gen-zaddrs.pl

@@ -4,8 +4,8 @@
 use warnings;
 use strict;
 
-my $hush    = "./src/hush-cli";
+my $cli     = "./src/dragonx-cli";
-my $znew    = "$hush z_getnewaddress";
+my $znew    = "$cli z_getnewaddress";
 my $count   = 1;
 my $howmany = shift || 50;
 

contrib/gitian-descriptors/README.md

@@ -1,4 +1,8 @@
-### Gavin's notes on getting gitian builds up and running using KVM:###
+### Notes on getting gitian builds up and running using KVM:###
+
+Note: These are legacy notes inherited from upstream. The real, supported DragonX
+build path is `./build.sh` together with the `depends/` system; gitian is legacy
+and is retained here only for historical reference.
 
 These instructions distilled from:
 [  https://help.ubuntu.com/community/KVM/Installation](  https://help.ubuntu.com/community/KVM/Installation)
@@ -20,7 +24,7 @@ Sanity checks:
 
 Once you've got the right hardware and software:
 
-    git clone git://github.com/bitcoin/bitcoin.git
+    git clone https://git.dragonx.is/DragonX/dragonx.git
     git clone git://github.com/devrandom/gitian-builder.git
     mkdir gitian-builder/inputs
     cd gitian-builder/inputs
@@ -62,5 +66,5 @@ Here's a description of Gavin's setup on OSX 10.6:
 5. Still inside Ubuntu, tell gitian-builder to use LXC, then follow the "Once you've got the right hardware and software" instructions above:
 
 	export USE_LXC=1
-	git clone git://github.com/bitcoin/bitcoin.git
+	git clone https://git.dragonx.is/DragonX/dragonx.git
 	... etc

contrib/init/README.md

@@ -2,11 +2,11 @@
 
 Sample configuration files for:
 
-SystemD: hushd.service
+SystemD: dragonxd.service
-Upstart: hushd.conf
+Upstart: dragonxd.conf
-OpenRC:  hushd.openrc
+OpenRC:  dragonxd.openrc
-         hushd.openrcconf
+         dragonxd.openrcconf
-CentOS:  hushd.init
+CentOS:  dragonxd.init
 
 have been made available to assist packagers in creating node packages here.
 

contrib/init/dragonxd.conf

@@ -1,4 +1,4 @@
-description "Hush Daemon"
+description "DragonX Daemon"
 
 start on runlevel [2345]
 stop on starting rc RUNLEVEL=[016]
@@ -9,7 +9,7 @@ env HUSHD_GROUP="hush"
 env HUSHD_PIDDIR="/var/run/dragonxd"
 # upstart can't handle variables constructed with other variables
 env HUSHD_PIDFILE="/var/run/dragonxd/dragonxd.pid"
-env HUSHD_CONFIGFILE="/etc/hush/hush.conf"
+env HUSHD_CONFIGFILE="/etc/dragonx/DRAGONX.conf"
 env HUSHD_DATADIR="/var/lib/dragonxd"
 
 expect fork

contrib/init/dragonxd.init

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 #
-#  dragonxd The hush core server.
+#  dragonxd The DragonX core server.
 #
 #
 # chkconfig: 345 80 20

contrib/init/dragonxd.openrc

@@ -8,7 +8,7 @@ else
 	HUSHD_DEFAULT_DATADIR="/var/lib/dragonxd"
 fi
 
-HUSHD_CONFIGFILE=${HUSHD_CONFIGFILE:-/etc/hush/hush.conf}
+HUSHD_CONFIGFILE=${HUSHD_CONFIGFILE:-/etc/dragonx/DRAGONX.conf}
 HUSHD_PIDDIR=${HUSHD_PIDDIR:-/var/run/dragonxd}
 HUSHD_PIDFILE=${HUSHD_PIDFILE:-${HUSHD_PIDDIR}/dragonxd.pid}
 HUSHD_DATADIR=${HUSHD_DATADIR:-${HUSHD_DEFAULT_DATADIR}}
@@ -18,8 +18,8 @@ HUSHD_BIN=${HUSHD_BIN:-/usr/bin/dragonxd}
 HUSHD_NICE=${HUSHD_NICE:-${NICELEVEL:-0}}
 HUSHD_OPTS="${HUSHD_OPTS:-${HUSH_OPTS}}"
 
-name="Hush Full Node Daemon"
+name="DragonX Full Node Daemon"
-description="Hush cryptocurrency P2P network daemon"
+description="DragonX cryptocurrency P2P network daemon"
 
 command="/usr/bin/dragonxd"
 command_args="-pid=\"${HUSHD_PIDFILE}\" \

contrib/init/dragonxd.openrcconf

@@ -1,7 +1,7 @@
 # /etc/conf.d/dragonxd: config file for /etc/init.d/dragonxd
 
 # Config file location
-#HUSHD_CONFIGFILE="/etc/hush/hush.conf"
+#HUSHD_CONFIGFILE="/etc/dragonx/DRAGONX.conf"
 
 # What directory to write pidfile to?  (created and owned by $HUSHD_USER)
 #HUSHD_PIDDIR="/var/run/dragonxd"

contrib/init/dragonxd.service

@@ -1,15 +1,17 @@
 [Unit]
-Description=Hush: Speak And Transact Freely
+Description=DragonX: private RandomX-mined full node
 After=network.target
 
 [Service]
+# The 'hush' service user/group is intentional for packaging compatibility;
+# renaming it is a separate decision.
 User=hush
 Group=hush
 
 Type=forking
 PIDFile=/var/lib/dragonxd/dragonxd.pid
 ExecStart=/usr/bin/dragonxd -daemon -pid=/var/lib/dragonxd/dragonxd.pid \
--conf=/etc/hush/hush.conf -datadir=/var/lib/dragonxd -disablewallet
+-conf=/etc/dragonx/DRAGONX.conf -datadir=/var/lib/dragonxd -disablewallet
 
 Restart=always
 PrivateTmp=true

contrib/init/hushd.conf

@@ -1,59 +0,0 @@
-description "Hush Daemon"
-
-start on runlevel [2345]
-stop on starting rc RUNLEVEL=[016]
-
-env HUSHD_BIN="/usr/bin/hushd"
-env HUSHD_USER="hush"
-env HUSHD_GROUP="hush"
-env HUSHD_PIDDIR="/var/run/hushd"
-# upstart can't handle variables constructed with other variables
-env HUSHD_PIDFILE="/var/run/hushd/hushd.pid"
-env HUSHD_CONFIGFILE="/etc/hush/hush.conf"
-env HUSHD_DATADIR="/var/lib/hushd"
-
-expect fork
-
-respawn
-respawn limit 5 120
-kill timeout 60
-
-pre-start script
-    # this will catch non-existent config files
-    # hushd will check and exit with this very warning, but it can do so
-    # long after forking, leaving upstart to think everything started fine.
-    # since this is a commonly encountered case on install, just check and
-    # warn here.
-    if ! grep -qs '^rpcpassword=' "$HUSHD_CONFIGFILE" ; then
-        echo "ERROR: You must set a secure rpcpassword to run hushd."
-        echo "The setting must appear in $HUSHD_CONFIGFILE"
-        echo
-        echo "This password is security critical to securing wallets "
-        echo "and must not be the same as the rpcuser setting."
-        echo "You can generate a suitable random password using the following"
-        echo "command from the shell:"
-        echo
-        echo "bash -c 'tr -dc a-zA-Z0-9 < /dev/urandom | head -c32 && echo'"
-        echo
-        exit 1
-    fi
-
-    mkdir -p "$HUSHD_PIDDIR"
-    chmod 0755 "$HUSHD_PIDDIR"
-    chown $HUSHD_USER:$HUSHD_GROUP "$HUSHD_PIDDIR"
-    chown $HUSHD_USER:$HUSHD_GROUP "$HUSHD_CONFIGFILE"
-    chmod 0660 "$HUSHD_CONFIGFILE"
-end script
-
-exec start-stop-daemon \
-    --start \
-    --pidfile "$HUSHD_PIDFILE" \
-    --chuid $HUSHD_USER:$HUSHD_GROUP \
-    --exec "$HUSHD_BIN" \
-    -- \
-    -pid="$HUSHD_PIDFILE" \
-    -conf="$HUSHD_CONFIGFILE" \
-    -datadir="$HUSHD_DATADIR" \
-    -disablewallet \
-    -daemon
-

contrib/init/hushd.init

@@ -1,67 +0,0 @@
-#!/usr/bin/env bash
-#
-#  hushd The hush core server.
-#
-#
-# chkconfig: 345 80 20
-# description: hushd
-# processname: hushd
-#
-
-# Source function library.
-. /etc/init.d/functions
-
-# you can override defaults in /etc/sysconfig/hushd, see below
-if [ -f /etc/sysconfig/hushd ]; then
-        . /etc/sysconfig/hushd
-fi
-
-RETVAL=0
-
-prog=hushd
-# you can override the lockfile via HUSHD_LOCKFILE in /etc/sysconfig/hushd
-lockfile=${HUSHD_LOCKFILE-/var/lock/subsys/hushd}
-
-# hushd defaults to /usr/bin/hushd, override with HUSHD_BIN
-hushd=${HUSHD_BIN-/usr/bin/hushd}
-
-# hushd opts default to -disablewallet, override with HUSHD_OPTS
-hushd_opts=${HUSHD_OPTS--disablewallet}
-
-start() {
-    echo -n $"Starting $prog: "
-    daemon $DAEMONOPTS $hushd $hushd_opts
-    RETVAL=$?
-    echo
-    [ $RETVAL -eq 0 ] && touch $lockfile
-    return $RETVAL
-}
-
-stop() {
-    echo -n $"Stopping $prog: "
-    killproc $prog
-    RETVAL=$?
-    echo
-    [ $RETVAL -eq 0 ] && rm -f $lockfile
-    return $RETVAL
-}
-
-case "$1" in
-    start)
-        start
-        ;;
-    stop)
-        stop
-        ;;
-    status)
-        status $prog
-        ;;
-    restart)
-        stop
-        start
-        ;;
-    *)
-        echo "Usage: service $prog {start|stop|status|restart}"
-        exit 1
-        ;;
-esac

contrib/init/hushd.openrc

@@ -1,87 +0,0 @@
-#!/sbin/runscript
-
-# backward compatibility for existing gentoo layout 
-#
-if [ -d "/var/lib/hush/.hush" ]; then
-	HUSHD_DEFAULT_DATADIR="/var/lib/hush/.hush"
-else
-	HUSHD_DEFAULT_DATADIR="/var/lib/hushd"
-fi
-
-HUSHD_CONFIGFILE=${HUSHD_CONFIGFILE:-/etc/hush/hush.conf}
-HUSHD_PIDDIR=${HUSHD_PIDDIR:-/var/run/hushd}
-HUSHD_PIDFILE=${HUSHD_PIDFILE:-${HUSHD_PIDDIR}/hushd.pid}
-HUSHD_DATADIR=${HUSHD_DATADIR:-${HUSHD_DEFAULT_DATADIR}}
-HUSHD_USER=${HUSHD_USER:-${HUSH_USER:-hush}}
-HUSHD_GROUP=${HUSHD_GROUP:-hush}
-HUSHD_BIN=${HUSHD_BIN:-/usr/bin/hushd}
-HUSHD_NICE=${HUSHD_NICE:-${NICELEVEL:-0}}
-HUSHD_OPTS="${HUSHD_OPTS:-${HUSH_OPTS}}"
-
-name="Hush Full Node Daemon"
-description="Hush cryptocurrency P2P network daemon"
-
-command="/usr/bin/hushd"
-command_args="-pid=\"${HUSHD_PIDFILE}\" \
-		-conf=\"${HUSHD_CONFIGFILE}\" \
-		-datadir=\"${HUSHD_DATADIR}\" \
-		-daemon \
-		${HUSHD_OPTS}"
-
-required_files="${HUSHD_CONFIGFILE}"
-start_stop_daemon_args="-u ${HUSHD_USER} \
-			-N ${HUSHD_NICE} -w 2000"
-pidfile="${HUSHD_PIDFILE}"
-
-# The retry schedule to use when stopping the daemon. Could be either
-# a timeout in seconds or multiple signal/timeout pairs (like
-# "SIGKILL/180 SIGTERM/300")
-retry="${HUSHD_SIGTERM_TIMEOUT}"
-
-depend() {
-	need localmount net
-}
-
-# verify
-# 1) that the datadir exists and is writable (or create it)
-# 2) that a directory for the pid exists and is writable
-# 3) ownership and permissions on the config file
-start_pre() {
-	checkpath \
-	-d \
-	--mode 0750 \
-	--owner "${HUSHD_USER}:${HUSHD_GROUP}" \
-	"${HUSHD_DATADIR}"
-
-	checkpath \
-	-d \
-	--mode 0755 \
-	--owner "${HUSHD_USER}:${HUSHD_GROUP}" \
-	"${HUSHD_PIDDIR}"
-
-	checkpath -f \
-	-o ${HUSHD_USER}:${HUSHD_GROUP} \
-	-m 0660 \
-	${HUSHD_CONFIGFILE}
-
-	checkconfig || return 1
-}
-
-checkconfig()
-{
-	if ! grep -qs '^rpcpassword=' "${HUSHD_CONFIGFILE}" ; then
-		eerror ""
-		eerror "ERROR: You must set a secure rpcpassword to run hushd."
-		eerror "The setting must appear in ${HUSHD_CONFIGFILE}"
-		eerror ""
-		eerror "This password is security critical to securing wallets "
-		eerror "and must not be the same as the rpcuser setting."
-		eerror "You can generate a suitable random password using the following"
-		eerror "command from the shell:"
-		eerror ""
-		eerror "bash -c 'tr -dc a-zA-Z0-9 < /dev/urandom | head -c32 && echo'"
-		eerror ""
-		eerror ""
-		return 1
-	fi
-}

contrib/init/hushd.openrcconf

@@ -1,33 +0,0 @@
-# /etc/conf.d/hushd: config file for /etc/init.d/hushd
-
-# Config file location
-#HUSHD_CONFIGFILE="/etc/hush/hush.conf"
-
-# What directory to write pidfile to?  (created and owned by $HUSHD_USER)
-#HUSHD_PIDDIR="/var/run/hushd"
-
-# What filename to give the pidfile
-#HUSHD_PIDFILE="${HUSHD_PIDDIR}/hushd.pid"
-
-# Where to write hushd data (be mindful that the blockchain is large)
-#HUSHD_DATADIR="/var/lib/hushd"
-
-# User and group to own hushd process
-#HUSHD_USER="hush"
-#HUSHD_GROUP="hush"
-
-# Path to hushd executable
-#HUSHD_BIN="/usr/bin/hushd"
-
-# Nice value to run hushd under
-#HUSHD_NICE=0
-
-# Additional options (avoid -conf and -datadir, use flags above)
-HUSHD_OPTS="-disablewallet"
-
-# The timeout in seconds OpenRC will wait for hushd to terminate
-# after a SIGTERM has been raised.
-# Note that this will be mapped as argument to start-stop-daemon's
-# '--retry' option, which means you can specify a retry schedule
-# here. For more information see man 8 start-stop-daemon.
-HUSHD_SIGTERM_TIMEOUT=60

contrib/init/hushd.service

@@ -1,22 +0,0 @@
-[Unit]
-Description=Hush: Speak And Transact Freely
-After=network.target
-
-[Service]
-User=hush
-Group=hush
-
-Type=forking
-PIDFile=/var/lib/hushd/hushd.pid
-ExecStart=/usr/bin/hushd -daemon -pid=/var/lib/hushd/hushd.pid \
--conf=/etc/hush/hush.conf -datadir=/var/lib/hushd -disablewallet
-
-Restart=always
-PrivateTmp=true
-TimeoutStopSec=60s
-TimeoutStartSec=2s
-StartLimitInterval=120s
-StartLimitBurst=5
-
-[Install]
-WantedBy=multi-user.target

contrib/macdeploy/README.md

@@ -1,9 +1,5 @@
 ### MacDeploy ###
 
-For Snow Leopard (which uses [Python 2.6](http://www.python.org/download/releases/2.6/)), you will need the param_parser package:
-	
-	sudo easy_install argparse
-
 This script should not be run manually, instead, after building as usual:
 
 	make deploy
@@ -11,5 +7,4 @@ This script should not be run manually, instead, after building as usual:
 During the process, the disk image window will pop up briefly where the fancy
 settings are applied. This is normal, please do not interfere.
 
-When finished, it will produce `Bitcoin-Core.dmg`.
+When finished, it will produce `DragonX.dmg`.
-

contrib/qos/README.md

@@ -1,5 +1,5 @@
 ### Qos ###
 
-This is a Linux bash script that will set up tc to limit the outgoing bandwidth for connections to the Hush network. It limits outbound TCP traffic with a source or destination port of 18030, but not if the destination IP is within a LAN (defined as 192.168.x.x).
+This is a Linux bash script that will set up tc to limit the outgoing bandwidth for connections to the DragonX network. It limits outbound TCP traffic with a source or destination port of 18030, but not if the destination IP is within a LAN (defined as 192.168.x.x).
 
-This means one can have an always-on hushd instance running, and another local hushd/bitcoin-qt instance which connects to this node and receives blocks from it.
+This means one can have an always-on dragonxd instance running, and another local dragonxd instance which connects to this node and receives blocks from it.

contrib/sda_checkpoints.pl

@@ -3,22 +3,23 @@
 # Distributed under the GPLv3 software license, see the accompanying
 # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
 
-# This script is used to generate the checkpoint data used by the SilentDragon Android SDK
+# This script is used to generate the checkpoint data used by the SilentDragonX Android SDK
-# https://git.hush.is/fekt/hush-android-wallet-sdk/src/branch/main/sdk-lib/src/main/assets/co.electriccoin.zcash/checkpoint/mainnet
+# https://git.dragonx.is/DragonX/SilentDragonXAndroid
+# (checkpoint format follows the upstream co.electriccoin.zcash/checkpoint/mainnet layout)
 
 use warnings;
 use strict;
-my $hush    = "./src/hush-cli";
+my $cli     = "./src/dragonx-cli";
-my $getblock= "$hush getblock";
+my $getblock= "$cli getblock";
-my $gethash = "$hush getblockhash";
+my $gethash = "$cli getblockhash";
-my $gettree = "$hush getblockmerkletree";
+my $gettree = "$cli getblockmerkletree";
 my $start   = shift || 1390000;
 my $end     = shift || 1422000;
 my $stride  = shift || 10000;
 
-my $blocks  = qx{$hush getblockcount};
+my $blocks  = qx{$cli getblockcount};
 if($?) {
-    print "ERROR, is hushd running? exiting...\n";
+    print "ERROR, is dragonxd running? exiting...\n";
     exit 1;
 }
 

contrib/sdl_checkpoints.pl

@@ -3,7 +3,8 @@
 # Distributed under the GPLv3 software license, see the accompanying
 # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
 
-# This script is used to generate the data used by the silentdragonlite-cli checkpoints.rs file
+# This script is used to generate the data used by a light-wallet checkpoints.rs file.
+# The checkpoint format follows the upstream silentdragonlite-cli reference:
 # https://git.hush.is/hush/silentdragonlite-cli/src/branch/master/lib/src/lightclient/checkpoints.rs#L24
 
 use warnings;
@@ -12,16 +13,16 @@ use strict;
 # call this script like this to generate checkpoints for another chain:
 # CLI=./src/hac-cli ./contrib/sdl_checkpoints.pl ...
 
-my $hush    = $ENV{CLI} || "./src/hush-cli";
+my $cli     = $ENV{CLI} || "./src/dragonx-cli";
-my $gethash = "$hush getblockhash";
+my $gethash = "$cli getblockhash";
-my $gettree = "$hush getblockmerkletree";
+my $gettree = "$cli getblockmerkletree";
 my $start   = shift || 300000;
 my $end     = shift || 840000;
 my $stride  = shift || 10000;
 
-my $blocks  = qx{$hush getblockcount};
+my $blocks  = qx{$cli getblockcount};
 if($?) {
-    print "ERROR, is hushd running? exiting...\n";
+    print "ERROR, is dragonxd running? exiting...\n";
     exit 1;
 }
 

contrib/seeds/README.md

@@ -1,10 +1,8 @@
 # Seeds
 
 Utility to generate the seeds.txt list that is compiled into the client
-(see [src/chainparamsseeds.h](hush/hush3/src/branch/master/src/chainparamsseeds.h) and other utilities in [contrib/seeds](hush/hush3/src/branch/master/contrib/seeds/)).
+(see [src/chainparamsseeds.h](../../src/chainparamsseeds.h) and other utilities in [contrib/seeds](.)).
 
 ## Updating seeds
 
-Update [contrib/seeds/nodes_main.txt](hush/hush3/src/branch/master/contrib/seeds/nodes_main.txt) and run `make seeds` in the hush root directory of this repo (not the directory of this README) to update [src/chainparamsseeds.h](hush/hush3/src/branch/master/src/chainparamsseeds.h) then commit the result.
+Update [contrib/seeds/nodes_main.txt](nodes_main.txt) and run `make seeds` in the DragonX root directory of this repo (not the directory of this README) to update [src/chainparamsseeds.h](../../src/chainparamsseeds.h) then commit the result.
-
-

contrib/testgen/README.md

@@ -1,6 +1,6 @@
 ### TestGen ###
 
-Utilities to generate test vectors for the data-driven Hush tests.
+Utilities to generate test vectors for the data-driven DragonX tests.
 
 Usage: 
 

contrib/verifysfbinaries/README.md

@@ -1,6 +1,15 @@
 ### Verify SF Binaries ###
-This script attempts to download the signature file `SHA256SUMS.asc` from https://bitcoin.org.
+
+This is a legacy SourceForge-era script inherited from upstream and is not used
+for DragonX releases. It originally attempted to download a signature file
+`SHA256SUMS.asc` from an upstream release host and verify the binaries listed in
+it.
+
+For DragonX, release artifacts and checksums are published via the DragonX
+project host at https://git.dragonx.is/DragonX and https://dragonx.is . The
+script would need to be pointed at those locations before it could be useful; it
+is retained here only for historical reference.
 
 It first checks if the signature passes, and then downloads the files specified in the file, and checks if the hashes of these files match those that are specified in the signature file.
 
-The script returns 0 if everything passes the checks. It returns 1 if either the signature check or the hash check doesn't pass. If an error occurs the return value is 2.
+The script returns 0 if everything passes the checks. It returns 1 if either the signature check or the hash check doesn't pass. If an error occurs the return value is 2.

doc/CONTRIBUTING.md

@@ -1,7 +1,7 @@
 
-# Hush Core (hushd) Software Contribution Guidelines
+# DragonX Core (dragonxd) Software Contribution Guidelines
 
-Thank you for reaching out and trying to make Hush an even better software application and cryptocoin platform. These contribution guidelines shall help you figuring out where you can be helpful and how to easily get started.
+Thank you for reaching out and trying to make DragonX an even better software application and cryptocoin platform. These contribution guidelines shall help you figuring out where you can be helpful and how to easily get started.
 
 ## Table of Contents
 
@@ -14,15 +14,13 @@ Thank you for reaching out and trying to make Hush an even better software appli
 0. [Community](#community)
 
 ## Types of contributions we're looking for
-There are many ways you can directly contribute to Hush:
+There are many ways you can directly contribute to DragonX:
 
-* Debug and test the Hush Core code
+* Debug and test the DragonX Core code
 * Find and fix bugs
 * Improve suboptimal code
 * Extend our software
-* Perform a secure code review of Hush Full Node and other Hush-related software
+* Perform a secure code review of DragonX Full Node and other DragonX-related software
-
-We have a curated list of projects with details about difficulty level and languages involved: https://git.hush.is/hush/projects
 
 Interested in making a contribution? Read on!
 
@@ -31,15 +29,14 @@ Interested in making a contribution? Read on!
 Before we get started, here are a few things we expect from you (and that you should expect from others):
 
 * Be kind and thoughtful in your conversations around this project. We all come from different backgrounds and projects, which means we likely have different perspectives on "how free software and open source is done." Try to listen to others rather than convince them that your way is correct.
-* Open Source Guides are released with a [Contributor Code of Conduct](./code_of_conduct.md). By participating in this project, you agree to abide by its terms.
 * If you open a pull request, please ensure that your contribution does not increase test failures. If there are additional test failures, you will need to address them before we can merge your contribution.
 * When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created as others will do so if they appreciate it.
 
 ## How to contribute
 
-If you'd like to contribute, start by searching through the [issues](https://git.hush.is/hush/hush3/issues) and [pull requests](https://git.hush.is/hush/hush3/pulls) to see whether someone else has raised a similar idea or question.
+If you'd like to contribute, start by searching through the [issues](https://git.dragonx.is/DragonX/dragonx/issues) and [pull requests](https://git.dragonx.is/DragonX/dragonx/pulls) to see whether someone else has raised a similar idea or question.
 
-If you don't see your idea listed, and you think it can contribute to Hush, do one of the following:
+If you don't see your idea listed, and you think it can contribute to DragonX, do one of the following:
 * **If your contribution is minor,** such as a fixing a typo, open a pull request.
 * **If your contribution is major,** such as a new feature or bugfix, start by opening an issue first. That way, other contributors can weigh in on the discussion before you do any work.
 
@@ -49,9 +46,9 @@ Don't write shitty code. Do not emulate "jl777 code style" from Komodo, we consi
 
 ## Setting up your environment
 
-The Hush Core (hushd) is mainly written in C++ with specific modules written in C. Follow the [Install](https://git.hush.is/hush/hush3/src/branch/master/INSTALL.md) instructions to build hushd from sources. For more informations about the Hush Platform and a full API documentation please visit the official [Hush Developer documentation](https://faq.hush.is/rpc/)
+DragonX Core (dragonxd) is mainly written in C++ with specific modules written in C. See the build instructions in the [README](../README.md) to build dragonxd from sources.
 
-Other Hush software is written in Rust or Go. We avoid Javascript at all costs.
+Other DragonX software is written in Rust or Go. We avoid Javascript at all costs.
 
 ## Contribution review process
 

doc/DEVELOPING.md

@@ -1,6 +1,6 @@
-# Being a Hush Developer
+# Being a DragonX Developer
 
-## Compiling Hush
+## Compiling DragonX
 
 Normal compiling is as simple as:
 
@@ -20,7 +20,7 @@ Divide how many GBs of RAM you have by 2, subtract one. Use that many jobs.
 ## Dealing with dependency changes
 
 Let's say you change a dependency and want the compile to notice. If your
-change is outside of the main Hush source code, in ./src, simply running
+change is outside of the main DragonX source code, in ./src, simply running
 `make` will not notice, and sometimes not even `build.sh`. You can always
 do a fresh clone or `make clean`, but that will take a lot of time. Those
 methods are actually best for Continuous Integration systems, but to help
@@ -54,14 +54,14 @@ If `make clean` produces a compilation error, you just experienced it.
 
 ## Switching branches
 
-Switching branches and doing partial compiles in Hush source code
+Switching branches and doing partial compiles in DragonX source code
 can introduce weird bugs, which are fixed by running `build.sh` again.
 Additionally, it's a good idea to run `make clean` before you switch
 between branches.
 
 ## Partial compiles
 
-At any point, you can modify hush source code and then use `make` or `build.sh`
+At any point, you can modify DragonX source code and then use `make` or `build.sh`
 to do a partial compile. The first is faster but the latter is more likely to
 work correctly in all circustances. Sometimes partial compiles break weird
 build system dependencies, and you must do a `make clean` first, or even
@@ -75,14 +75,14 @@ of a dependency or something inside of Rust, you will need `build.sh` .
 
 ## Generating new unix man pages
 
-Make sure that you have updated all version numbers in hushd and compiled, then
+Make sure that you have updated all version numbers in dragonxd and compiled, then
 to generate new unix man pages for that version :
 
 	./util/gen-manpages.sh
 
 ## Generating new debian packages
 
-After successfully compiling Hush, you can generate a debian package of these binaries with:
+After successfully compiling DragonX, you can generate a debian package of these binaries with:
 
 	./util/build-debian-package.sh
 
@@ -113,9 +113,8 @@ port) are ways to prevent them from communicating. This is good because these
 two HACs will eventually chain fork due to their different consensus rules and
 ban each other, wasting time, bandwidth and sanity.
 
-An example of doing this can be seen in the commit
+An example of this pattern in the Git history is the commit which added the
-https://git.hush.is/hush/hush3/commit/d39503c13b7419620d138050899705ced557eef9
+`-ac_burn` consensus changing option; search the log for `ac_burn` to find it.
-which added the `-ac_burn` consensus changing option.
 
 The chain magic value is the CRC32 checksum of every non-default consensus
 option the HAC uses.
@@ -128,4 +127,4 @@ modify `src/miner.cpp` to do whatever they want.
 
 If you think something else should be in this guide, please send your suggestions!
 
-Gitea: https://git.hush.is/hush/hush3
+Gitea: https://git.dragonx.is/DragonX/dragonx

doc/OLD_WALLETS.md

@@ -1,71 +0,0 @@
-## Claiming Funds From Old Hush Wallets
-
-Hush migrated to a new mainnet after Block 500,000 on the old Hush blockchain.
-Funds in addresses as of Block 500,000 were transported to our new chain. About
-31,000 addresses with at least 0.00000001 HUSH were transported to the new Hush
-mainnet.
-
-To claim funds on the new chain, there are few options.
-
-### Funds on exchanges
-
-Firstly, no bueno! Not your keys, not your coins. It's best not to store coins
-on exchanges. But in this case, you lucked out! There is nothing to do to claim
-new coins if you have coins on an exchange that supports the new Hush chain.
-The exchange will follow the instructions from the next section and you will
-magically have funds on the new chain. Note that old Hush addresses started
-with `t1` and now they begin with `R`.
-
-To see what an old HUSH v2 address looks like on the new chain, this online tool
-can be used: https://dexstats.info/addressconverter.php
-
-or this command line tool: https://git.hush.is/hush/hush3/src/master/contrib/convert_address.py
-
-
-### Using an old wallet.dat
-
-Backup your old HUSH wallet.dat, and backup any current wallet.dat that is in
-
-        ~/.komodo/HUSH3/
-
-OR
-        ~/.hush/HUSH3/
-
-There is no way to lose funds, as long as you have backups!!! Make sure
-to make backups. Do not skip this step.
-
-Make sure any/all GUI wallets are stopped! Also make sure your old Hush node
-and new Hush3 node are stopped:
-
-        cd hush3
-        ./src/hush-cli stop
-
-Do not copy wallets or move wallets while your full node is running! This could
-corrupt your wallet!
-
-Now copy your old Hush wallet.dat to
-
-        ~/.hush/HUSH3/
-
-with a command like
-
-        # DO NOT RUN THIS WITHOUT MAKING BACKUPS!
-        cp ~/.hush/wallet.dat ~/.hush/HUSH3/
-
-The reason this works is that both old HUSH and new HUSH are still Bitcoin Protocol
-coins, which both use secp256k1 public keys. Now start your HUSH3 node again,
-with this special CLI argument that will clear out transactions from your wallet:
-
-        cd hush3
-        ./src/hushd -zapwallettxes
-
-This will cause a full history rescan, which will take some time. Once it's complete,
-you can see your funds with this command:
-
-        ./src/hush-cli getwalletinfo
-
-NOTE: Do not use this wallet except to send funds to a new wallet!
-
-### Private Keys
-
-You can also transport funds one address at a time via private keys.

doc/beefy-HUSH3.conf

@@ -1,7 +0,0 @@
-rpcuser=dontuseweakusernameoryougetrobbed
-rpcpassword=dontuseweakpasswordoryougetrobbed
-txindex=1
-server=1
-rpcworkqueue=64
-addnode=1.2.3.4
-addnode=5.6.7.8

doc/cjdns.md

@@ -1,6 +1,6 @@
-# CJDNS support in Hush
+# CJDNS support in DragonX
 
-It is possible to run Hush over CJDNS, an encrypted IPv6 network that
+It is possible to run DragonX over CJDNS, an encrypted IPv6 network that
 uses public-key cryptography for address allocation and a distributed hash table
 for routing.
 
@@ -9,7 +9,7 @@ for routing.
 CJDNS is like a distributed, shared VPN with multiple entry points where every
 participant can reach any other participant. All participants use addresses from
 the `fc00::/8` network (reserved IPv6 range). Installation and configuration is
-done outside of Hush, similarly to a VPN (either in the host/OS or on
+done outside of DragonX, similarly to a VPN (either in the host/OS or on
 the network router). See https://github.com/cjdelisle/cjdns#readme and
 https://github.com/hyperboria/docs#hyperboriadocs for more information.
 
@@ -17,7 +17,7 @@ Compared to IPv4/IPv6, CJDNS provides end-to-end encryption and protects nodes
 from traffic analysis and filtering.
 
 Used with Tor and I2P, CJDNS is a complementary option that can enhance network
-redundancy and robustness for both the Hush network and individual nodes.
+redundancy and robustness for both the DragonX network and individual nodes.
 
 Each network has different characteristics. For instance, Tor is widely used but
 somewhat centralized. I2P connections have a source address and I2P is slow.
@@ -30,7 +30,7 @@ To install and set up CJDNS, follow the instructions at
 https://github.com/cjdelisle/cjdns#how-to-install-cjdns.
 
 You need to initiate an outbound connection to a peer on the CJDNS network
-before it will work with your Hush node. This is described in steps
+before it will work with your DragonX node. This is described in steps
 ["2. Find a friend"](https://github.com/cjdelisle/cjdns#2-find-a-friend) and
 ["3. Connect your node to your friend's
 node"](https://github.com/cjdelisle/cjdns#3-connect-your-node-to-your-friends-node)
@@ -65,19 +65,19 @@ with some additional setup.
 The network connection can be checked by running `./tools/peerStats` from the
 CJDNS directory.
 
-## Run Hush with CJDNS
+## Run DragonX with CJDNS
 
-Once you are connected to the CJDNS network, the following Hush
+Once you are connected to the CJDNS network, the following DragonX
 configuration option makes CJDNS peers automatically reachable:
 
 ```
 -cjdnsreachable
 ```
 
-When enabled, this option tells Hush that it is running in an
+When enabled, this option tells DragonX that it is running in an
 environment where a connection to an `fc00::/8` address will be to the CJDNS
 network instead of to an [RFC4193](https://datatracker.ietf.org/doc/html/rfc4193)
-IPv6 local network. This helps Hush perform better address management:
+IPv6 local network. This helps DragonX perform better address management:
   - Your node can consider incoming `fc00::/8` connections to be from the CJDNS
     network rather than from an IPv6 private one.
   - If one of your node's local addresses is `fc00::/8`, then it can choose to
@@ -93,20 +93,18 @@ Make automatic outbound connections only to CJDNS addresses. Inbound and manual
 connections are not affected by this option. It can be specified multiple times
 to allow multiple networks, e.g. onlynet=cjdns, onlynet=i2p, onlynet=onion.
 
-CJDNS support was added to Hush in version 3.9.3 and there may be fewer
+There may be fewer CJDNS peers than Tor or IP ones. You can use
-CJDNS peers than Tor or IP ones. You can use `hush-cli -addrinfo` to see the
+`dragonx-cli -addrinfo` to see the number of CJDNS addresses known to your node.
-number of CJDNS addresses known to your node.
 
 In general, a node can be run with both an onion service and CJDNS (or any/all
 of IPv4/IPv6/onion/I2P/CJDNS), which can provide a potential fallback if one of
 the networks has issues. There are a number of ways to configure this; see
-[doc/tor.md](https://git.hush.is/hush/hush3/src/branch/master/doc/tor.md) for
+[doc/tor.md](tor.md) for details.
-details.
 
-## CJDNS-related information in Hush
+## CJDNS-related information in DragonX
 
-There are several ways to see your CJDNS address in Hush:
+There are several ways to see your CJDNS address in DragonX:
 - in the "localaddresses" output of RPC `getnetworkinfo`
 
-To see which CJDNS peers your node is connected to, use `hush-cli getpeerinfo`
+To see which CJDNS peers your node is connected to, use `dragonx-cli getpeerinfo`
 RPC.

doc/config.md

@@ -1,10 +1,10 @@
-# HUSH3.conf config options
+# DRAGONX.conf config options
 
-This document explains all options that can be used in HUSH3.conf
+This document explains all options that can be used in DRAGONX.conf
 
 # Basics
 
-Options can either be put in HUSH3.conf or given on the `hushd` commandline when starting. If you think you will want to continually use a feature, it's better to put it in HUSH3.conf. If you don't, and start `hushd` without an option on accident, it can cause downtime from a long rescan, that you didn't want to do anyway.
+Options can either be put in DRAGONX.conf or given on the `dragonxd` commandline when starting. If you think you will want to continually use a feature, it's better to put it in DRAGONX.conf. If you don't, and start `dragonxd` without an option on accident, it can cause downtime from a long rescan, that you didn't want to do anyway.
 
 
 ## Common Options
@@ -15,20 +15,20 @@ Tells your node to connect to another node, by IP address or hostname.
 
 ## consolidation=1
 
-Defaults to 0 in CLI hushd, defaults to 1 in SilentDragon. This option consolidates many unspent shielded UTXOs (zutxos) into one zutxo, which makes spending them in the future faster and potentially cost less in fees. It also helps prevent
+Defaults to 0 in CLI dragonxd, and may default to 1 in GUI wallets that embed a full node. This option consolidates many unspent shielded UTXOs (zutxos) into one zutxo, which makes spending them in the future faster and potentially cost less in fees. It also helps prevent
-certain kinds of metadata leakages and spam attacks. It is not recommended for very large wallets (wallet.dat files with thousands of transactions) for performance reasons. This is why it defaults to OFF for CLI full nodes but ON for GUI wallets that use an embedded hushd.
+certain kinds of metadata leakages and spam attacks. It is not recommended for very large wallets (wallet.dat files with thousands of transactions) for performance reasons. This is why it defaults to OFF for CLI full nodes but may be ON for GUI wallets that use an embedded dragonxd.
 
 ## rescan=1
 
 Defaults to 0. Performs a full rescan of all of chain history. Can take a very long time. Speed this up with `rescanheight=123` to only rescan from a certain block height. Also speed this up with `keepnotewitnesscache=1` to not rebuild the zaddr witness cache.
 
-## rpcuser=hushpuppy
+## rpcuser=yourusername
 
-No default. This option sets the RPC username and should only be used in HUSH3.conf, because setting it from the command-line makes it show up in `ps` output.
+No default. This option sets the RPC username and should only be used in DRAGONX.conf, because setting it from the command-line makes it show up in `ps` output.
 
-## rpcpassword=TOOMANYSECRETS
+## rpcpassword=aLongRandomSecret
 
-No default. This option sets the RPC password and should only be used in HUSH3.conf, because setting it from the command-line makes it show up in `ps` output.
+No default. This option sets the RPC password and should only be used in DRAGONX.conf, because setting it from the command-line makes it show up in `ps` output.
 
 ## txindex=1
 
@@ -56,7 +56,7 @@ Defaults to: bind to all interfaces. This option Binds to given address to liste
 
 ## stratumport=<port>
 
-Defaults to 19031 or 19031 for testnet. This option sets the <port> to listen for Stratum work requests on.
+Defaults to 22769. This option sets the <port> to listen for Stratum work requests on.
 
 ## stratumallowip=<ip>
 
@@ -68,12 +68,12 @@ These options are not commonly used and likely on for advanced users and/or deve
 
 ## addressindex=1
 
-Defaults to 0 in hushd, defaults to 1 in some GUI wallets. Maintain a full address index, used to query for the balance, txids and unspent outputs for addresses
+Defaults to 0 in dragonxd, defaults to 1 in some GUI wallets. Maintain a full address index, used to query for the balance, txids and unspent outputs for addresses
 
 ## timestampindex=1
 
-Defaults to 0 in hushd, defaults to 1 in some GUI wallets. Maintain a timestamp index for block hashes, used to query blocks hashes by a range of timestamps 
+Defaults to 0 in dragonxd, defaults to 1 in some GUI wallets. Maintain a timestamp index for block hashes, used to query blocks hashes by a range of timestamps 
 
 ## spentindex=1
 
-Defaults to 0 in hushd, defaults to 1 in some GUI wallets. Maintain a full spent index, used to query the spending txid and input index for an outpoint 
+Defaults to 0 in dragonxd, defaults to 1 in some GUI wallets. Maintain a full spent index, used to query the spending txid and input index for an outpoint 

doc/developer-notes.md

@@ -5,11 +5,11 @@ First the basics, how to compile code in this repo.
 First you will want to clone the code locally:
 
 ```
-git clone https://git.hush.is/hush/hush3
+git clone https://git.dragonx.is/DragonX/dragonx
-cd hush3
+cd dragonx
 ```
 
-If you want to compile a branch other than master (the default), such as
+If you want to compile a branch other than `dragonx` (the default), such as
 our development tip (the `dev` branch) you can switch to it:
 
 ```
@@ -17,7 +17,7 @@ git checkout dev
 ```
 
 Then install needed dependencies. This is different on each OS as well as
-older or newer systems. See https://git.hush.is/hush/hush3/src/branch/dev/INSTALL.md for
+older or newer systems. See the build instructions in the repo README for
 details on installing dependencies. If you are using a recent-ish Ubuntu or Debian Linux
 distro, this is probably what you need:
 
@@ -59,20 +59,21 @@ A fresh sync preserves peers.dat, so it will always be faster than a "fresh clon
 One way to do a fresh sync is:
 
 ```
-cd ~/.hush/HUSH3
+cd ~/.hush/DRAGONX
-rm blocks chainstate database notarizations hushstate
+rm -rf blocks chainstate database notarizations hushstate hushsignedmasks minerids
 ```
 
-NOTE: The legacy directory is ~/.komodo/HUSH3 and hushd will use data from either, or ~/.hush/HUSH3 if both exist.
+NOTE: The DragonX data directory is `~/.hush/DRAGONX`. The on-disk notarization/state
+files are still named `hushstate`/`hushsignedmasks` (inherited names, not rebranded).
 
 If you are using `zindex=1` then you need to also delete zindex.dat
 
 ```
-cd ~/.hush/HUSH3
+cd ~/.hush/DRAGONX
-rm zindex.dat blocks chainstate database notarizations hushstate
+rm -rf zindex.dat blocks chainstate database notarizations hushstate hushsignedmasks minerids
 ```
 
-It's possible to confused hush if you ran old code, stop, restart, and then write out zindex.dat that is incorrect, which later hushds will load from disk and believe.
+It's possible to confuse the node if you ran old code, stop, restart, and then write out a zindex.dat that is incorrect, which later dragonxd instances will load from disk and believe.
 
 # Generating a backtrace from a coredump
 
@@ -93,12 +94,11 @@ core_filename` and then type bt to generate the backtrace.
 
 For this repo, it's likely this is the command you need:
 ```
-gdb src/hushd core
+gdb src/dragonxd core
 ```
 
-NOTE: Even if you are debugging a coredump on a HAC, the file `src/blahd`
+NOTE: `src/blahd` is just a shell script that calls `src/dragonxd`; you always want to
-is just a shell script that calls `src/hushd` and you always want to give an actual executable
+give an actual executable file as the first argument to `gdb`, not a bash script.
-file as the first argument to `gdb`, not a bash script.
 
 This link about Advanced GDB is very useful: https://interrupt.memfault.com/blog/advanced-gdb
 
@@ -113,7 +113,7 @@ unspendable funds mixed together. This can happen when you import a viewing key.
 the address of a viewing key will have `spendable = false` :
 
 
-    hush-cli listunspent|jq '.[] | {spendable, address, amount} | select(.spendable != false)'
+    dragonx-cli listunspent|jq '.[] | {spendable, address, amount} | select(.spendable != false)'
 
 The above command will only show spendable UTXOs. The jq language is very powerful and is very
 useful for devops and developer scripts.
@@ -121,7 +121,7 @@ useful for devops and developer scripts.
 The jq manual can be found here: https://stedolan.github.io/jq/manual/
 
 
-# Making a new release of Hush
+# Making a new release of DragonX
 
 See doc/release-process.md for details.
 
@@ -132,39 +132,39 @@ To test a branch called `zindexdb` with a fresh clone:
 
 ```
 # TODO: this should probably become a script in ./contrib
-git clone https://git.hush.is/hush/hush3 hush3-testing
+git clone https://git.dragonx.is/DragonX/dragonx dragonx-testing
-cd hush3-testing
+cd dragonx-testing
 git checkout zindexdb
 # you need 2GB RAM free per -jN
 ./build.sh -j2; make; make; make # this deals with build-system race condition bugs
 
 # we want to test a fresh sync, so backup current data
 TIME=`perl -e "print time"`
-mv ~/.hush/{HUSH3,HUSH3-backup-$TIME}
+mv ~/.hush/{DRAGONX,DRAGONX-backup-$TIME}
-mkdir ~/.hush/HUSH3
+mkdir ~/.hush/DRAGONX
 
 # Use your previous config as a base
-cp ~/.hush/{HUSH3-backup-$TIME,HUSH3}/HUSH3.conf
+cp ~/.hush/{DRAGONX-backup-$TIME,DRAGONX}/DRAGONX.conf
 # Add zindex to your node
-echo "zindex=1" >> ~/.hush/HUSH3/HUSH3.conf
+echo "zindex=1" >> ~/.hush/DRAGONX/DRAGONX.conf
 
 
 # This is optional but will likely speed up sync time greatly
-cp ~/.hush/{HUSH3-backup,HUSH3}/peers.dat
+cp ~/.hush/{DRAGONX-backup-$TIME,DRAGONX}/peers.dat
 
 # This log file is helpful for debugging more and will contain a history of the
 # size of the anonset at every block height
-./src/hushd &> hushd.log &
+./src/dragonxd &> dragonxd.log &
 # to look at the log
-tail -f hushd.log
+tail -f dragonxd.log
 ```
 
 To get a CSV file of the value of the anonset size for every block height:
 ```
-grep anonset hushd.log | cut -d= -f2 > anonset.csv
+grep anonset dragonxd.log | cut -d= -f2 > anonset.csv
 ```
 
-This only needs to be calculated once, if we can verify it's correct. These are historical values that do not change. The goal is a web page with a historical view of the HUSH anonset size.
+This only needs to be calculated once, if we can verify it's correct. These are historical values that do not change. The goal is a web page with a historical view of the DRAGONX anonset size.
 
 
 These values should match on all nodes:
@@ -180,17 +180,22 @@ These values should match on all nodes:
 We should also check a recent block height to verify it's working correctly. The big "test" for this `zindexdb` branch is: 
 
   * If you stop a node, and restart, are the stats from `getchaintxtstats` correct, i.e. the anonset stats? For instance, `shielded_pool_size` should be close to 500000, if it's close to or exactly 0, something is wrong.
-  * Is there a new file called `zindex.dat` in `~/.hush/HUSH3/` ? 
+  * Is there a new file called `zindex.dat` in `~/.hush/DRAGONX/` ? 
   * Is `zindex.dat` 149 bytes ?
 
 # Adding a PoW algorithm
 
 We will describe here the high-level ideas on how to add a new PoW algorithm to
-the Hush codebase. Adding a new PoW algo means adding a new option to the `-ac_algo`
+the codebase. Adding a new PoW algo means adding a new option to the `-ac_algo`
-CLI param for HSC's.
+CLI param.
+
+Note: DragonX itself uses **RandomX** (CPU) as its Proof-of-Work — it is selected by
+default for the DRAGONX chain (`isdragonx ? "randomx"` in `src/hush_utils.h`). The
+generic `ASSETCHAINS_ALGORITHMS` array below still lists Equihash as its first element
+(the array default), but that is not DragonX's algorithm.
 
   * Add the new value to the end of the `ASSETCHAINS_ALGORITHMS` array in `src/hush_utils.h`
-    * You cannot add it to the front because the first element is the default "equihash"
+    * You cannot add it to the front because the first element is the array default "equihash"
     * You will also need to add a new constant, such as `ASSETCHAINS_FOOHASH` to `src/hush_globals.h`
   * Increase the value of `ASSETCHAINS_NUMALGOS` by one
     * This value cannot be automatically be determined by the length of the above array because Equihash has different supported variants of (N,K) values
@@ -263,7 +268,7 @@ on all categories (and give you a very large debug.log file).
 **test coins**
 
 The main way to test new things is directly on mainnet or you can also make a
-Hush Arrakis Chain "testcoin" with a single command: `hushd -ac_name=COIN ...`
+test "testcoin" chain with a single command: `dragonxd -ac_name=COIN ...`
 
 If you are testing something that can run on one machine you can use `-testnode=1`
 which makes it so a single machine can create a new blockchain and mine blocks, i.e.
@@ -271,7 +276,7 @@ no peers are necessary.
 
 **DEBUG_LOCKORDER**
 
-Hush is a multithreaded application, and deadlocks or other multithreading bugs
+DragonX is a multithreaded application, and deadlocks or other multithreading bugs
 can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure
 CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of which locks
 are held, and adds warnings to the debug.log file if inconsistencies are detected.
@@ -306,7 +311,7 @@ Threads
 
 - ThreadMapPort : Universal plug-and-play startup/shutdown
 
-- ThreadSocketHandler : Sends/Receives data from peers on port 8233.
+- ThreadSocketHandler : Sends/Receives data from peers on the P2P port (18030 on DragonX mainnet).
 
 - ThreadOpenAddedConnections : Opens network connections to added nodes.
 
@@ -318,9 +323,9 @@ Threads
 
 - ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used in 500ms.
 
-- ThreadRPCServer : Remote procedure call handler, listens on port 8232 for connections and services them.
+- ThreadRPCServer : Remote procedure call handler, listens on the RPC port (21769 on DragonX mainnet) for connections and services them.
 
-- HushMiner : Generates zcash (if wallet is enabled).
+- Miner threads : Generate DRAGONX blocks via RandomX (if wallet and mining are enabled).
 
 - Shutdown : Does an orderly shutdown of everything.
 

doc/dnsseed-policy.md

@@ -1,11 +1,11 @@
 # Expectations for DNS Seed operators
 
-Hush attempts to minimize the level of trust in DNS seeds,
+DragonX attempts to minimize the level of trust in DNS seeds,
 but DNS seeds still pose a small amount of risk for the network.
 As such, DNS seeds must be run by entities which have some minimum
-level of trust within the Hush community.
+level of trust within the DragonX community.
 
-Other implementations of Hush software may also use the same
+Other implementations of DragonX software may also use the same
 seeds and may be more exposed. In light of this exposure, this
 document establishes some basic expectations for operating DNS seeds.
 
@@ -15,7 +15,7 @@ and not sell or transfer control of the DNS seed. Any hosting services
 contracted by the operator are equally expected to uphold these expectations.
 
 1. The DNS seed results must consist exclusively of fairly selected and
-functioning Hush nodes from the public network to the best of the
+functioning DragonX nodes from the public network to the best of the
 operator's understanding and capability.
 
 2. For the avoidance of doubt, the results may be randomized but must not
@@ -25,7 +25,7 @@ urgent technical necessity and disclosed.
 3. The results may not be served with a DNS TTL of less than one minute.
 
 4. Any logging of DNS queries should be only that which is necessary
-for the operation of the service or urgent health of the Hush
+for the operation of the service or urgent health of the DragonX
 network and must not be retained longer than necessary nor disclosed
 to any third party.
 
@@ -41,13 +41,8 @@ details of their operating practices.
 related to the DNS seed operation.
 
 If these expectations cannot be satisfied the operator should discontinue
-providing services and contact the active Hush development team as well as
+providing services and contact the active DragonX development team as well as
-creating an issue in the [Hush Git repository](https://git.hush.is./hush/hush3).
+creating an issue in the [DragonX Git repository](https://git.dragonx.is/DragonX/dragonx).
 
 Behavior outside of these expectations may be reasonable in some
 situations but should be discussed in public in advance.
-
-See also
-----------
-- [hush-seeder](https://git.hush.is/hush/hush-seeder) is a reference
-  implementation of a DNS seed.

doc/dragonx/logo_dragonx.svg

@@ -0,0 +1,23 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 128 128">
+  <defs>
+    <style>
+      .cls-1 {
+        fill: #fff;
+      }
+
+      .cls-2 {
+        fill: #d82652;
+      }
+    </style>
+  </defs>
+  <path class="cls-2" d="M103.98,128s-6.29-24.7-18.73-34.43c-8.53-8.03-15.63-16.49-21.25-24.16-5.62,7.68-12.72,16.17-21.25,24.16-12.4,9.74-18.73,34.43-18.73,34.43-2.38-24.34,7.85-35.82,12.87-41.29,7.82-8.5,15.31-16.56,21.75-25.02-7.64-11.44-11.41-19.72-11.41-19.72-.89-3.27-3.84-6.64-3.84-6.64,6.08-8.1-1.6-16.98-1.6-16.98,5.79-5.62,6.71-10.02,8.32-18.34-1.96,22.35,4.02,39.09,13.93,54.12,9.84-15.03,15.81-31.77,13.86-54.12,1.6,8.35,2.52,12.72,8.32,18.34,0,0-7.68,8.88-1.6,16.98,0,0-2.95,3.38-3.84,6.64,0,0-3.77,8.28-11.37,19.72,6.43,8.45,13.97,16.56,21.75,25.02,4.97,5.47,15.21,16.95,12.83,41.29h0Z"/>
+  <g>
+    <path class="cls-1" d="M55.33,61.62c-3.55,4.55-7.39,8.99-11.44,13.47-5.29-4.48-11.23-5.33-11.23-5.33,22.92-7.82,2.81-15.17.28-16.31C9.28,42.78,9.1,14.78,9.1,14.78c11.51,34.15,36.42,32.3,36.42,32.3.35-.21.67-.46.92-.71,1.64,3.27,4.58,8.67,8.88,15.24h0Z"/>
+    <g>
+      <path class="cls-1" d="M68.62,40.41c-1.35,2.98-2.91,5.83-4.62,8.63-1.71-2.81-3.23-5.69-4.62-8.63,1.74-3.45,4.62-20.58,4.62-20.58,0,0,2.88,17.13,4.62,20.58Z"/>
+      <path class="cls-1" d="M76.01,97.93l-3.48,2.34s-.1-4.44-3.52-1.84c-.42.32-2.38,2.21-.03,4.27,0,0-4.05,4.08-4.97,8.21-.92-4.12-4.97-8.21-4.97-8.21,2.34-2.06.39-3.95-.03-4.27-3.41-2.59-3.52,1.84-3.52,1.84l-3.48-2.34c.28-3.55.1-6.68-.46-9.42,4.69-4.94,8.85-9.88,12.47-14.61,3.66,4.72,7.78,9.67,12.47,14.61-.57,2.74-.75,5.86-.46,9.42Z"/>
+      <path class="cls-1" d="M95.34,69.76s-5.94.85-11.23,5.33c-4.02-4.48-7.89-8.92-11.44-13.47,4.3-6.57,7.25-11.98,8.88-15.24.25.25.57.5.92.71,0,0,24.91,1.84,36.42-32.3,0,0-.18,28-23.84,38.66-2.52,1.14-22.64,8.5.28,16.31h0Z"/>
+    </g>
+  </g>
+</svg>

doc/files.md

@@ -1,17 +1,17 @@
-# Hush Files
+# DragonX Files
 
-* HUSH3.conf: contains configuration settings for hushd
+* DRAGONX.conf: contains configuration settings for dragonxd
-* hushd.pid: stores the process id of hushd while running
+* dragonxd.pid: stores the process id of dragonxd while running
 * blocks/blk000??.dat: block data (custom, 128 MiB per file)
 * blocks/rev000??.dat; block undo data (custom)
 * blocks/index/*; block index (LevelDB)
 * chainstate/*; block chain state database (LevelDB)
 * database/*: BDB database environment
 * db.log: wallet database log file
-* debug.log: contains debug information and general logging generated by hushd
+* debug.log: contains debug information and general logging generated by dragonxd
 * fee_estimates.dat: stores statistics used to estimate minimum transaction fees and priorities required for confirmation
 * peers.dat: peer IP address database (custom format)
 * wallet.dat: personal wallet (BDB) with keys and transactions
-* zindex.dat: Optional file that stores anonset (shielded pool) stats. Only created if `zindex=1` in HUSH3.conf or `hushd -zindex` is used
+* zindex.dat: Optional file that stores anonset (shielded pool) stats. Only created if `zindex=1` in DRAGONX.conf or `dragonxd -zindex` is used
 * .cookie: session RPC authentication cookie (written at start when cookie authentication is used, deleted on shutdown): since 0.12.0
 * onion_private_key: cached Tor hidden service private key for `-listenonion`: since 0.12.0

doc/help.md

@@ -17,10 +17,9 @@ where this data lives on your computer and then move some files around, then res
 
 ### On Linux
 
-If you are on Linux, your wallet lives at `~/.hush/HUSH3/wallet.dat` or if you have a really old
+If you are on Linux, your wallet lives at `~/.hush/DRAGONX/wallet.dat`.
-legacy wallet it could be at `~/.komodo/HUSH3/wallet.dat` . We will assume the first location.
 
-What we will do is backup your entire `HUSH3` directory, including the blockchain data and wallet,
+What we will do is backup your entire `DRAGONX` directory, including the blockchain data and wallet,
 then copy the wallet from there into a new directory. This is a non-destructive process that creates
 a new backup of your wallet.
 
@@ -28,25 +27,26 @@ a new backup of your wallet.
 # Make sure your node is not running before doing any of this!
 # Doing this while your node is running could corrupt your wallet.dat
 cd ~/.hush
-mv HUSH3 HUSH3-backup                       # backup all data
+mv DRAGONX DRAGONX-backup                          # backup all data
-mkdir HUSH3                                 # make a new dir
+mkdir DRAGONX                                      # make a new dir
-cp HUSH3-backup/wallet.dat HUSH3/wallet.dat # copy old wallet to new dir
+cp DRAGONX-backup/wallet.dat DRAGONX/wallet.dat    # copy old wallet to new dir
 ```
 
-At this point if you are GUI user using SilentDragon, you can restart the GUI wallet
+At this point restart your node (`dragonxd`) and it will perform a fresh sync using your
-and it should perform a fresh sync with your wallet. This will likely take at least
+wallet. This will likely take at least a few hours or much longer depending on your
-a few hours or much longer depending on your internet connection.
+internet connection.
 
 ### On Windows
 
-Basically you want to find where your Hush wallet is, move the directory that contains
+Basically you want to find where your DragonX wallet is, move the directory that contains
 that wallet.dat file to a new name, then create that same directory and then copy wallet.dat into it.
-Different versions of Windows store things in different locations.
+Different versions of Windows store things in different locations. Note the app-data folder is
+named `Hush` (inherited) with a `DRAGONX` subdirectory.
 
-For example your wallet might be in `C:\Users\Admin\AppData\Roaming\Hush\HUSH3\wallet.dat` . 
+For example your wallet might be in `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX\wallet.dat` .
 That means you need to
 
-    * Rename the directory `C:\Users\Admin\AppData\Roaming\Hush\HUSH3` to something like `C:\Users\Admin\AppData\Roaming\Hush\HUSH3-backup`
+    * Rename the directory `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX` to something like `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX-backup`
-    * Create a new directory called `C:\Users\Admin\AppData\Roaming\Hush\HUSH3`
+    * Create a new directory called `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX`
-    * Copy the file `C:\Users\Admin\AppData\Roaming\Hush\HUSH3-backup\wallet.dat` to `C:\Users\Admin\AppData\Roaming\Hush\HUSH3`
+    * Copy the file `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX-backup\wallet.dat` to `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX`
-    * Now start the SilentDragon GUI wallet
+    * Now start your DragonX node again

doc/hsc.md

@@ -1,24 +0,0 @@
-# Hush Arrakis Chains
-
-An overview of HSCs can be found here:
-
-https://git.hush.is/hush/hush-smart-chains
-
-Hush Arrakis Chains allow you to create a privacy coin with no custom C++ code, just running one command!
-The new coin that is created can use either Equihash PoW (ASIC or GPU) or RandomX PoW (CPU).
-
-## HSC Creator
-
-https://git.hush.is/hush/hsc-creator with its site https://hush.is/hsc-creator
-
-## HSC HOWTO
-
-https://git.hush.is/onryo/hush-arrakis-chain-how-to
-
-## HSC CLI
-
-https://git.hush.is/jahway603/hsc-cli
-
-## RandomX for HSCs
-
-Detailed docs on how to use RandomX Proof-of-Work is here: https://git.hush.is/hush/hush3/src/branch/dev/doc/randomx.md

doc/hushd-systemd.md

@@ -1,35 +0,0 @@
-# Systemd script for the Hush daemon
-
-## Set it up
-
-First set it up as follows:
-* Copy hushd.service to the systemd user directory, which is /usr/lib/systemd/user directory
-
-## Basic Usage
-
-How to start the script:
-`systemctl start --user hushd.service`
-
-How to stop the script:
-`systemctl stop --user hushd.service`
-
-How to restart the script:
-`systemctl restart --user hushd.service`
-
-## How to watch it as it starts
-
-Use the following on most Linux distros:
-`watch systemctl status --user hushd.service`
-
-If you're using Ubuntu 20.04, then try this instead as the above did not work for me on Ubuntu 20.04 server:
-`tail -f ~/.hush/HUSH3/debug.log`
-
-## Troubleshooting
-
-* Don't run it with sudo or root, or it won't work with the wallet.
-
-### To-do
-
-* Determine why Ubuntu 20.04 didn't produce the expected outcome with watch and systemctl
-* Create the hushd rc.d script
-* Create the hushd runit script

doc/hushd.service

@@ -1,9 +0,0 @@
-[Unit]
-Description=Hush daemon
-After=network.target
-
-[Service]
-ExecStart=/usr/bin/hushd
-
-[Install]
-WantedBy=default.target

doc/i2p.md

@@ -1,6 +1,6 @@
-# I2P support in Hush
+# I2P support in DragonX
 
-It is possible to run a Hush or HSC full node as an
+It is possible to run a DragonX full node as an
 [I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P)
 service and connect to such services.
 
@@ -42,13 +42,13 @@ configuration options:
 In a typical situation, this suffices:
 
 ```
-hushd -i2psam=127.0.0.1:7656
+dragonxd -i2psam=127.0.0.1:7656
 ```
 
-The first time hushd connects to the I2P router, if
+The first time dragonxd connects to the I2P router, if
 `-i2pacceptincoming=1`, then it will automatically generate a persistent I2P
 address and its corresponding private key. The private key will be saved in a
-file named `i2p_private_key` in the Hush data directory. The persistent
+file named `i2p_private_key` in the DragonX data directory. The persistent
 I2P address is used for accepting incoming connections and for making outgoing
 connections if `-i2pacceptincoming=1`. If `-i2pacceptincoming=0` then only
 outbound I2P connections are made and a different transient I2P address is used
@@ -71,8 +71,8 @@ Make automatic outbound connections only to I2P addresses. Inbound and manual
 connections are not affected by this option. It can be specified multiple times
 to allow multiple networks, e.g. onlynet=onion, onlynet=i2p.
 
-I2P support was added to Hush in version 3.9.3 and there may be fewer I2P
+There may be fewer I2P peers than Tor or IP ones. Therefore, using I2P alone
-peers than Tor or IP ones. Therefore, using I2P alone without other networks may
+without other networks may
 make a node more susceptible to [Sybil
 attacks](https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack). 
 
@@ -91,7 +91,7 @@ connection initiator. This is unlike the Tor network where the recipient does
 not know who is connecting to them and can't tell if two connections are from
 the same peer or not.
 
-If an I2P node is not accepting incoming connections, then Hush uses
+If an I2P node is not accepting incoming connections, then DragonX uses
 random, one-time, transient I2P addresses for itself for outbound connections
 to make it harder to discriminate, fingerprint or analyze it based on its I2P
 address.
@@ -104,35 +104,35 @@ incoming I2P connections (`-i2pacceptincoming`):
 - in the debug log (grep for `AddLocal`; the I2P address ends in `.b32.i2p`)
 - in the i2p/i2pd web console under "SAM Sessions"
 
-To see which I2P peers your node is connected to, use `hush-cli getpeerinfo`
+To see which I2P peers your node is connected to, use `dragonx-cli getpeerinfo`
 RPC.
 
 ## Compatibility
 
-Hush uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3) protocol
+DragonX uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3) protocol
 to connect to the I2P network. Any I2P router that supports it can be used.
 
-## Ports in I2P and Hush
+## Ports in I2P and DragonX
 
-Hush uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3)
+DragonX uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3)
 protocol. One particularity of SAM v3.1 is that it does not support ports,
 unlike newer versions of SAM (v3.2 and up) that do support them and default the
 port numbers to 0. From the point of view of peers that use newer versions of
 SAM or other protocols that support ports, a SAM v3.1 peer is connecting to them
 on port 0, from source port 0.
 
-To allow future upgrades to newer versions of SAM, Hush sets its
+To allow future upgrades to newer versions of SAM, DragonX sets its
 listening port to 0 when listening for incoming I2P connections and advertises
 its own I2P address with port 0. Furthermore, it will not attempt to connect to
 I2P addresses with a non-zero port number because with SAM v3.1 the destination
-port (`TO_PORT`) is always set to 0 and is not in the control of Hush.
+port (`TO_PORT`) is always set to 0 and is not in the control of DragonX.
 
 ## Bandwidth
 
 By default, your node shares bandwidth and transit tunnels with the I2P network
 in order to increase your anonymity with cover traffic, help the I2P router used
 by your node integrate optimally with the network, and give back to the network.
-It's important that the nodes of a popular application like Hush contribute
+It's important that the nodes of a popular application like DragonX contribute
 as much to the I2P network as they consume.
 
 It is possible, though strongly discouraged, to change your I2P router
@@ -159,7 +159,7 @@ in [Embedding I2P in your Application](https://geti2p.net/en/docs/applications/e
 
 In most cases, the default router settings should work fine.
 
-## Bundling I2P in a Hush application
+## Bundling I2P in a DragonX application
 
 Please see the "General Guidance for Developers" section in https://geti2p.net/en/docs/api/samv3
-if you are developing a downstream application that may be bundling I2P with Hush.
+if you are developing a downstream application that may be bundling I2P with DragonX.

doc/init.md

@@ -1,62 +1,64 @@
-*** Warning: This document has not been updated for Hush and may be inaccurate. ***
+Sample init scripts and service configuration for dragonxd
-
-Sample init scripts and service configuration for bitcoind
 ==========================================================
 
 Sample scripts and configuration files for systemd, Upstart and OpenRC
 can be found in the contrib/init folder.
 
-    contrib/init/bitcoind.service:    systemd service unit configuration
+    contrib/init/dragonxd.service:    systemd service unit configuration
-    contrib/init/bitcoind.openrc:     OpenRC compatible SysV style init script
+    contrib/init/dragonxd.openrc:     OpenRC compatible SysV style init script
-    contrib/init/bitcoind.openrcconf: OpenRC conf.d file
+    contrib/init/dragonxd.openrcconf: OpenRC conf.d file
-    contrib/init/bitcoind.conf:       Upstart service configuration file
+    contrib/init/dragonxd.conf:       Upstart service configuration file
-    contrib/init/bitcoind.init:       CentOS compatible SysV style init script
+    contrib/init/dragonxd.init:       CentOS compatible SysV style init script
+
+For a simpler per-user systemd setup, see doc/dragonxd-systemd.md.
 
 1. Service User
 ---------------------------------
 
-All three startup configurations assume the existence of a "bitcoin" user
+All startup configurations assume the existence of a "hush" user
-and group.  They must be created before attempting to use these scripts.
+and group. They must be created before attempting to use these scripts.
+(The service user is named "hush" for packaging compatibility across the
+Hush lineage; renaming it is a separate packaging decision.)
 
 2. Configuration
 ---------------------------------
 
-At a bare minimum, bitcoind requires that the rpcpassword setting be set
+At a bare minimum, dragonxd requires that the rpcpassword setting be set
-when running as a daemon.  If the configuration file does not exist or this
+when running as a daemon. If the configuration file does not exist or this
-setting is not set, bitcoind will shutdown promptly after startup.
+setting is not set, dragonxd will shutdown promptly after startup.
 
 This password does not have to be remembered or typed as it is mostly used
-as a fixed token that bitcoind and client programs read from the configuration
+as a fixed token that dragonxd and client programs read from the configuration
 file, however it is recommended that a strong and secure password be used
 as this password is security critical to securing the wallet should the
 wallet be enabled.
 
-If bitcoind is run with "-daemon" flag, and no rpcpassword is set, it will
+If dragonxd is run with "-daemon" flag, and no rpcpassword is set, it will
-print a randomly generated suitable password to stderr.  You can also
+print a randomly generated suitable password to stderr. You can also
 generate one from the shell yourself like this:
 
 bash -c 'tr -dc a-zA-Z0-9 < /dev/urandom | head -c32 && echo'
 
 
 For an example configuration file that describes the configuration settings,
-see contrib/debian/examples/bitcoin.conf.
+see contrib/debian/examples/DRAGONX.conf.
 
 3. Paths
 ---------------------------------
 
-All three configurations assume several paths that might need to be adjusted.
+All configurations assume several paths that might need to be adjusted.
 
-Binary:              /usr/bin/bitcoind
+Binary:              /usr/bin/dragonxd
-Configuration file:  /etc/bitcoin/bitcoin.conf
+Configuration file:  /etc/dragonx/DRAGONX.conf
-Data directory:      /var/lib/bitcoind
+Data directory:      /var/lib/dragonxd
-PID file:            /var/run/bitcoind/bitcoind.pid (OpenRC and Upstart)
+PID file:            /var/run/dragonxd/dragonxd.pid (OpenRC and Upstart)
-                     /var/lib/bitcoind/bitcoind.pid (systemd)
+                     /var/lib/dragonxd/dragonxd.pid (systemd)
-Lock file:           /var/lock/subsys/bitcoind (CentOS)
+Lock file:           /var/lock/subsys/dragonxd (CentOS)
 
 The configuration file, PID directory (if applicable) and data directory
-should all be owned by the bitcoin user and group.  It is advised for security
+should all be owned by the hush user and group. It is advised for security
 reasons to make the configuration file and data directory only readable by the
-bitcoin user and group.  Access to bitcoin-cli and other bitcoind rpc clients
+hush user and group. Access to dragonx-cli and other dragonxd rpc clients
 can then be controlled by group membership.
 
 4. Installing Service Configuration
@@ -68,19 +70,19 @@ Installing this .service file consists of just copying it to
 /usr/lib/systemd/system directory, followed by the command
 "systemctl daemon-reload" in order to update running systemd configuration.
 
-To test, run "systemctl start bitcoind" and to enable for system startup run
+To test, run "systemctl start dragonxd" and to enable for system startup run
-"systemctl enable bitcoind"
+"systemctl enable dragonxd"
 
 4b) OpenRC
 
-Rename bitcoind.openrc to bitcoind and drop it in /etc/init.d.  Double
+Rename dragonxd.openrc to dragonxd and drop it in /etc/init.d. Double
-check ownership and permissions and make it executable.  Test it with
+check ownership and permissions and make it executable. Test it with
-"/etc/init.d/bitcoind start" and configure it to run on startup with
+"/etc/init.d/dragonxd start" and configure it to run on startup with
-"rc-update add bitcoind"
+"rc-update add dragonxd"
 
 4c) Upstart (for Debian/Ubuntu based distributions)
 
-Drop bitcoind.conf in /etc/init.  Test by running "service bitcoind start"
+Drop dragonxd.conf in /etc/init. Test by running "service dragonxd start"
 it will automatically start on reboot.
 
 NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they
@@ -88,15 +90,18 @@ use old versions of Upstart and do not supply the start-stop-daemon utility.
 
 4d) CentOS
 
-Copy bitcoind.init to /etc/init.d/bitcoind. Test by running "service bitcoind start".
+Copy dragonxd.init to /etc/init.d/dragonxd. Test by running "service dragonxd start".
 
-Using this script, you can adjust the path and flags to the bitcoind program by
+Using this script, you can adjust the path and flags to the dragonxd program by
-setting the BITCOIND and FLAGS environment variables in the file
+setting the HUSHD_BIN and HUSHD_OPTS environment variables in the file
-/etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here.
+/etc/sysconfig/dragonxd. You can also use the DAEMONOPTS environment variable here.
+(The HUSHD_* environment variable names are retained from the Hush lineage for
+packaging compatibility.)
 
 5. Auto-respawn
 -----------------------------------
 
 Auto respawning is currently only configured for Upstart and systemd.
 Reasonable defaults have been chosen but YMMV.
-
+</content>
+</invoke>

doc/overview.md

@@ -1,25 +1,31 @@
-# Hush Overview
+# DragonX Overview
 
 ## Mining Algorithm
 
-Equihash (200,9) (ASIC)
+RandomX (CPU). DragonX is CPU-mineable using the RandomX Proof-of-Work algorithm
+(the same family used by Monero). ASIC and GPU mining are not applicable. See
+[randomx.md](randomx.md) for details.
 
 ## Block time
 
-75 seconds
+36 seconds
+
+## Block reward
+
+3 DRAGONX per block, halving every 3,500,000 blocks.
 
 ## Block size
 
-4MB
+4 MB (consensus maximum)
 
 ## P2P
 
-TLS1.3 via WolfSSL is enforced for all network connections as of v3.6.1 .
+TLS1.3 via WolfSSL is enforced for all network connections. Many ciphersuites are
-Many ciphersuites are technically supported by TLS1.3 but many of them
+technically supported by TLS1.3 but many of them are ancient, proved to be less secure
-are ancient, proved to be less secure than intended or likely backdoored.
+than intended or likely backdoored. DragonX only uses what are widely considered to be the
-Hush only uses what are widely considered to be the most secure and [best ciphersuites](https://ciphersuite.info/cs/).
+most secure and [best ciphersuites](https://ciphersuite.info/cs/).
 
-New Hush P2P connections randomly choose between these two ciphersuites each
+New DragonX P2P connections randomly choose between these two ciphersuites each
 time a new connection to a peer is created:
 
   * `TLS_AES_256_GCM_SHA384`
@@ -35,10 +41,18 @@ IP address owns which addresses.
 
 ## RPC
 
-Inherited many RPC's from Bitcoin and Zcash with many new ones
+Inherited many RPCs from Bitcoin and Zcash, with many new ones.
 
 ## Consensus
 
-Hush is a mandatory privacy blockchain as of Block 340000 (Nov 2020),
+DragonX is a fully private blockchain from genesis. The consensus parameter
-which means you can only send to a shielded address, never to a transparent
+`ac_private=1` is active from block 1 and Sapling is active at height 1, so every
-address. This is enforced via consensus rules and sometimes called "z2z".
+non-coinbase output must be shielded — you can only send to a shielded (`zs...`)
+address, never to a transparent address. This is sometimes called "z2z". Unlike
+chains that switched on mandatory privacy at a later height, DragonX enforces it
+from the very first block.
+
+Transparent addresses exist only to receive mining coinbase; mature coinbase is
+directly spendable and is not required to be shielded first (shielding it with
+`z_shieldcoinbase` is an optional privacy step). See
+[hd-transparent-keys.md](hd-transparent-keys.md).

doc/payment-api.md

@@ -1,28 +1,28 @@
-# Hush Payment API
+# DragonX Payment API
 
 ## Overview
 
-Hush extends the Bitcoin Core API with new RPC calls to support private Hush payments involving shielded addresses (zaddrs).
+DragonX extends the Bitcoin Core API with new RPC calls to support private DragonX payments involving shielded addresses (zaddrs).
 
-Hush payments make use of two address formats:
+DragonX payments make use of two address formats:
 
 * taddr - an address for transparent funds (just like a Bitcoin address, value stored in UTXOs)
 * zaddr - an address for private funds (value stored in objects called notes)
 
-As of Block 340000, taddrs cannot be recipients of transactions, they can only mine new coinbase funds, which must then be sent to a zaddr.
+DragonX is a fully private chain from genesis (`ac_private=1`, Sapling active at height 1): taddrs can never be recipients of transactions. Transparent addresses only ever receive mining coinbase, which is directly spendable and may optionally be shielded to a zaddr with `z_shieldcoinbase`.
 
-When a transfer involves zaddrs, you must use the new Hush RPC calls, such as `z_sendmany`.
+When a transfer involves zaddrs, you must use the DragonX RPC calls, such as `z_sendmany`.
 
 
 ## Compatibility with Bitcoin Core
 
-Hush supports all commands in the Bitcoin Core API (as of version 0.11.2).   Where applicable, Hush will extend commands in a backwards-compatible way to enable additional functionality.
+DragonX supports all commands in the Bitcoin Core API (as of version 0.11.2).   Where applicable, DragonX will extend commands in a backwards-compatible way to enable additional functionality.
 
 We do not recommend use of accounts which are now deprecated in Bitcoin Core.  Where the account parameter exists in the API, please use “” as its value, otherwise an error will be returned.
 
 To support multiple users in a single node’s wallet, consider using getnewaddress or z_getnewaddress to obtain a new address for each user.  Also consider mapping multiple addresses to each user.
 
-## List of Hush API commands
+## List of DragonX API commands
 
 Optional parameters are denoted in [square brackets].
 
@@ -39,7 +39,7 @@ RPC parameter conventions:
 * taddr : Transparent address
 * zaddr : Private address
 * address : Accepts both private and transparent addresses.
-* amount : JSON format decimal number with at most 8 digits of precision, with 1 HUSH expressed as 1.00000000.
+* amount : JSON format decimal number with at most 8 digits of precision, with 1 DRAGONX expressed as 1.00000000.
 * memo : Metadata expressed in hexadecimal format.  Limited to 512 bytes, the current size of the memo field of a private transaction.  Zero padding is automatic.
 
 ### Accounting
@@ -53,18 +53,18 @@ z_gettotalbalance<br>| [minconf=1] | Return the total value of funds stored in t
 
 Command | Parameters | Description
 --- | --- | ---
-z_getnewaddress | | Return a new zaddr for sending and receiving payments. The spending key for this zaddr will be added to the node’s wallet.<br><br>Output:<br>zN68D8hSs3...
+z_getnewaddress | | Return a new Sapling zaddr for sending and receiving payments. The spending key for this zaddr will be added to the node’s wallet.<br><br>Output:<br>zs1...
-z_listaddresses | | Returns a list of all the zaddrs in this node’s wallet for which you have a spending key.<br><br>Output:<br>{ [“z123…”, “z456...”, “z789...”] }
+z_listaddresses | | Returns a list of all the zaddrs in this node’s wallet for which you have a spending key.<br><br>Output:<br>{ [“zs1…”, “zs1...”, “zs1...”] }
-z_validateaddress | zaddr | Return information about a given zaddr.<br><br>Output:<br>{"isvalid" : true,<br>"address" : "zcWsmq...",<br>"type" : "sprout",<br>"payingkey" : "f5bb3c...",<br>"transmissionkey" : "7a58c7...",<br>"ismine" : true}
+z_validateaddress | zaddr | Return information about a given Sapling zaddr.<br><br>Output:<br>{"isvalid" : true,<br>"address" : "zs1...",<br>"type" : "sapling",<br>"diversifier" : "f5bb3c...",<br>"diversifiedtransmissionkey" : "7a58c7...",<br>"ismine" : true}
 
 ### Key Management
 
 Command | Parameters | Description
 --- | --- | ---
-z_exportkey | zaddr | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Return a zkey for a given zaddr belonging to the node’s wallet.<br><br>The key will be returned as a string formatted using Base58Check as described in the Hush protocol spec.<br><br>Output:AKWUAkypwQjhZ6LLNaMuuuLcmZ6gt5UFyo8m3jGutvALmwZKLdR5
+z_exportkey | zaddr | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Return a zkey for a given zaddr belonging to the node’s wallet.<br><br>The key will be returned as a string formatted using Base58Check as described in the DragonX protocol spec.<br><br>Output:AKWUAkypwQjhZ6LLNaMuuuLcmZ6gt5UFyo8m3jGutvALmwZKLdR5
-z_importkey | zkey [rescan=true] | _Wallet must be unlocked._<br><br>Add a zkey as returned by z_exportkey to a node's wallet.<br><br>The key should be formatted using Base58Check as described in the Hush protocol spec.<br><br>Set rescan to true (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transactions affecting the newly-added address for this spending key).
+z_importkey | zkey [rescan=true] | _Wallet must be unlocked._<br><br>Add a zkey as returned by z_exportkey to a node's wallet.<br><br>The key should be formatted using Base58Check as described in the DragonX protocol spec.<br><br>Set rescan to true (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transactions affecting the newly-added address for this spending key).
 z_exportwallet | filename | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Creates or overwrites a file with taddr private keys and zaddr private keys in a human-readable format.<br><br>Filename is the file in which the wallet dump will be placed. May be prefaced by an absolute file path. An existing file with that name will be overwritten.<br><br>No value is returned but a JSON-RPC error will be reported if a failure occurred.
-z_importwallet | filename | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Imports private keys from a file in wallet export file format (see z_exportwallet). These keys will be added to the keys currently in the wallet. This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes.<br><br>Filename is the file to import. The path is relative to hushd’s working directory.<br><br>No value is returned but a JSON-RPC error will be reported if a failure occurred.
+z_importwallet | filename | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Imports private keys from a file in wallet export file format (see z_exportwallet). These keys will be added to the keys currently in the wallet. This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes.<br><br>Filename is the file to import. The path is relative to dragonxd’s working directory.<br><br>No value is returned but a JSON-RPC error will be reported if a failure occurred.
 z_exportviewingkey | zaddr | Reveals the viewing key corresponding to 'zaddr'. Then the z_importviewingkey can be used with this output.
 z_importviewingkey | vkey [rescan=whenkeyisnew] [startHeight=0] | Adds a viewing key (as returned by z_exportviewingkey) to your wallet.
 
@@ -75,7 +75,7 @@ Command | Parameters | Description
 --- | --- | ---
 z_listreceivedbyaddress<br> | zaddr [minconf=1] | Return a list of amounts received by a zaddr belonging to the node’s wallet.<br><br>Optionally set the minimum number of confirmations which a received amount must have in order to be included in the result.  Use 0 to count unconfirmed transactions.<br><br>Output:<br>[{<br>“txid”: “4a0f…”,<br>“amount”: 0.54,<br>“memo”:”F0FF…”,}, {...}, {...}<br>]
 z_listunspent | [minconf=1] [maxconf=9999999] [includeWatchonly=false] [zaddrs] | Returns array of unspent shielded notes with between minconf and maxconf (inclusive) confirmations.<br><br>Optionally filter to only include notes sent to specified addresses.<br><br>When minconf is 0, unspent notes with zero confirmations are returned, even though they are not immediately spendable.<br><br>Results are an array of Objects, each of which has: {txid, jsindex, jsoutindex, confirmations, address, amount, memo}
-z_sendmany<br> | fromaddress amounts [minconf=1] [fee=0.0001] | _This is an Asynchronous RPC call_<br><br>Send funds from an address to multiple outputs.  The address can be either a taddr or a zaddr.<br><br>Amounts is a list containing key/value pairs corresponding to the addresses and amount to pay.  Each output address can be in taddr or zaddr format.<br><br>When sending to a zaddr, you also have the option of attaching a memo in hexadecimal format.<br><br>**NOTE:**When sending coinbase funds to a zaddr, the node's wallet does not allow any change. Put another way, spending a partial amount of a coinbase utxo is not allowed. This is not a consensus rule but a local wallet rule due to the current implementation of z_sendmany. In future, this rule may be removed.<br><br>Example of Outputs parameter:<br>[{“address”:”t123…”, “amount”:0.005},<br>,{“address”:”z010…”,”amount”:0.03, “memo”:”f508af…”}]<br><br>Optionally set the minimum number of confirmations which a private or transparent transaction must have in order to be used as an input.  When sending from a zaddr, minconf must be greater than zero.<br><br>Optionally set a transaction fee, which by default is 0.0001 HUSH.<br><br>Any transparent change will be sent to a new transparent address.  Any private change will be sent back to the zaddr being used as the source of funds.<br><br>Returns an operationid.  You use the operationid value with z_getoperationstatus and z_getoperationresult to obtain the result of sending funds, which if successful, will be a txid.
+z_sendmany<br> | fromaddress amounts [minconf=1] [fee=0.0001] | _This is an Asynchronous RPC call_<br><br>Send funds from an address to multiple outputs.  The address can be either a taddr or a zaddr.<br><br>Amounts is a list containing key/value pairs corresponding to the addresses and amount to pay.  Each output address can be in taddr or zaddr format.<br><br>When sending to a zaddr, you also have the option of attaching a memo in hexadecimal format.<br><br>**NOTE:**When sending coinbase funds to a zaddr, the node's wallet does not allow any change. Put another way, spending a partial amount of a coinbase utxo is not allowed. This is not a consensus rule but a local wallet rule due to the current implementation of z_sendmany. In future, this rule may be removed.<br><br>Example of Outputs parameter:<br>[{“address”:”t123…”, “amount”:0.005},<br>,{“address”:”z010…”,”amount”:0.03, “memo”:”f508af…”}]<br><br>Optionally set the minimum number of confirmations which a private or transparent transaction must have in order to be used as an input.  When sending from a zaddr, minconf must be greater than zero.<br><br>Optionally set a transaction fee, which by default is 0.0001 DRAGONX.<br><br>Any transparent change will be sent to a new transparent address.  Any private change will be sent back to the zaddr being used as the source of funds.<br><br>Returns an operationid.  You use the operationid value with z_getoperationstatus and z_getoperationresult to obtain the result of sending funds, which if successful, will be a txid.
 z_shieldcoinbase<br> | fromaddress toaddress [fee=0.0001] [limit=50] | _This is an Asynchronous RPC call_<br><br>Shield transparent coinbase funds by sending to a shielded z address.  Utxos selected for shielding will be locked.  If there is an error, they are unlocked.  The RPC call `listlockunspent` can be used to return a list of locked utxos.<br><br>The number of coinbase utxos selected for shielding can be set with the limit parameter, which has a default value of 50.  If the parameter is set to 0, the number of utxos selected is limited by the `-mempooltxinputlimit` option.  Any limit is constrained by a consensus rule defining a maximum transaction size of 100000 bytes.  <br><br>The from address is a taddr or "*" for all taddrs belonging to the wallet.  The to address is a zaddr. The default fee is 0.0001.<br><br>Returns an object containing an operationid which can be used with z_getoperationstatus and z_getoperationresult, along with key-value pairs regarding how many utxos are being shielded in this transaction and what remains to be shielded.
 
 ### Operations
@@ -105,13 +105,13 @@ It is currently not possible to cancel operations.
 
 Command | Parameters | Description
 --- | --- | ---
-z_getoperationresult <br>| [operationids] | Return OperationStatus JSON objects for all completed operations the node is currently aware of, and then remove the operation from memory.<br><br>Operationids is an optional array to filter which operations you want to receive status objects for.<br><br>Output is a list of operation status objects, where the status is either "failed", "cancelled" or "success".<br>[<br>{“operationid”: “opid-11ee…”,<br>“status”: “cancelled”},<br>{“operationid”: “opid-9876”, “status”: ”failed”},<br>{“operationid”: “opid-0e0e”,<br>“status”:”success”,<br>“execution_time”:”25”,<br>“result”: {“txid”:”af3887654…”,...}<br>},<br>]<br><br> Examples:<br>hush-cli z_getoperationresult '["opid-8120fa20-5ee7-4587-957b-f2579c2d882b"]'<br> hush-cli z_getoperationresult
+z_getoperationresult <br>| [operationids] | Return OperationStatus JSON objects for all completed operations the node is currently aware of, and then remove the operation from memory.<br><br>Operationids is an optional array to filter which operations you want to receive status objects for.<br><br>Output is a list of operation status objects, where the status is either "failed", "cancelled" or "success".<br>[<br>{“operationid”: “opid-11ee…”,<br>“status”: “cancelled”},<br>{“operationid”: “opid-9876”, “status”: ”failed”},<br>{“operationid”: “opid-0e0e”,<br>“status”:”success”,<br>“execution_time”:”25”,<br>“result”: {“txid”:”af3887654…”,...}<br>},<br>]<br><br> Examples:<br>dragonx-cli z_getoperationresult '["opid-8120fa20-5ee7-4587-957b-f2579c2d882b"]'<br> dragonx-cli z_getoperationresult
 z_getoperationstatus <br>| [operationids] | Return OperationStatus JSON objects for all operations the node is currently aware of.<br><br>Operationids is an optional array to filter which operations you want to receive status objects for.<br><br>Output is a list of operation status objects.<br>[<br>{“operationid”: “opid-12ee…”,<br>“status”: “queued”},<br>{“operationid”: “opd-098a…”, “status”: ”executing”},<br>{“operationid”: “opid-9876”, “status”: ”failed”}<br>]<br><br>When the operation succeeds, the status object will also include the result.<br><br>{“operationid”: “opid-0e0e”,<br>“status”:”success”,<br>“execution_time”:”25”,<br>“result”: {“txid”:”af3887654…”,...}<br>}
 z_listoperationids <br>| [state] | Return a list of operationids for all operations which the node is currently aware of.<br><br>State is an optional string parameter to filter the operations you want listed by their state.  Acceptable parameter values are ‘queued’, ‘executing’, ‘success’, ‘failed’, ‘cancelled’.<br><br>[“opid-0e0e…”, “opid-1af4…”, … ]
 
 ## Asynchronous RPC call Error Codes
 
-Hush error codes are defined in https://git.hush.is/hush/hush3/src/branch/master/src/rpc/protocol.h
+DragonX error codes are defined in https://git.dragonx.is/DragonX/dragonx/src/branch/dragonx/src/rpc/protocol.h
 
 ### z_sendmany error codes
 

doc/randomx.md

@@ -1,75 +1,69 @@
-# RandomX
+# How DragonX uses RandomX
 
-Hush Arrakis Chains support using RandomX as a Proof-Of-Work algorithm as of release 3.9.2 .
+DragonX uses **RandomX** as its Proof-of-Work algorithm. RandomX is CPU-friendly
-This means you can now launch a privacy coin with Hush tech that can be mined with a CPU
+and ASIC/GPU-resistant, which keeps mining accessible to ordinary hardware.
-instead of requiring an ASIC or GPU. RandomX is the same algorithm that Monero (XMR) and
+RandomX is the same family of algorithm that Monero (XMR) and various other
-various other cryptocoins use. As far as we know, Hush Arrakis Chains are the first coins
+coins use, though DragonX uses its own configuration (see "RandomX Internals"
-based on Zcash Protocol that can use the RandomX PoW algorithm. Many thanks to all the
+below), so DragonX RandomX is not compatible with Monero mining hardware.
-people who helped make this possible.
 
-# Example
+DragonX descends from the Hush lineage (Bitcoin -> Zcash -> Komodo -> Hush ->
+DragonX). The RandomX integration in this codebase originates from that Hush
+work; DragonX ships it as a fixed part of consensus rather than as a launcher
+option.
 
-The following command can be used to launch an HSC on a single computer. Each option will be explained.
+## DragonX consensus parameters
-HSC CLI arguments that start with `-ac_` means they *Affect Consensus*.
+
+DragonX is a single, fully private chain. Its consensus is fixed (you do not
+pass `-ac_*` arguments to run a DragonX node):
+
+  * **PoW algorithm:** RandomX (CPU mineable)
+  * **Block time:** 36 seconds on average
+  * **Block reward:** 3 DRAGONX per block
+  * **Halving:** every 3,500,000 blocks
+  * **Private from genesis:** `ac_private=1`, with Sapling active at height 1.
+    Transparent sends are banned from block 1; transparent addresses only
+    receive mining coinbase (directly spendable, shielding optional). There is
+    no "privacy switches on later" phase — DragonX is private from the very
+    first block.
+
+To run a DragonX node and mine on the network, use `dragonxd` (mining is
+enabled with `-gen=1` and CPU threads set via `-genproclimit=N`), for example:
 
 ```
-./src/hush-arrakis-chain -ac_halving=100 -ac_algo=randomx -ac_name=RANDOMX -ac_private=1 -ac_blocktime=15 -ac_reward=500000000 -ac_supply=55555 -gen=1 -genproclimit=1 -testnode=1
+./src/dragonxd -gen=1 -genproclimit=1
 ```
 
-  * `hush-arrakis-chain` is the script used to launch or connect to HSCs
+You do not need to choose an algorithm, block time, reward, or supply — these
-    * It lives in the `./src` directory, next to `hushd` and `hush-cli`
+are baked into DragonX consensus.
-    * It is called `hush-arrakis-chain.bat` on Windows
-  * `-ac_halving=100` means "the block reward halves every 100 blocks"
-  * `-ac_algo=randomx` means "use RandomX for Proof-Of-Work
-    * The default is Equihash (200,9)
-  * `-ac_name=RANDOMX` sets the name of the HSC to RANDOMX
-  * `-ac_private=1` means only z2z transactions will be allowed, like HUSH mainnet
-  * `-ac_blocktime=15` means blocks will be 15 seconds on average
-    * The default is 60 seconds
-  * `-ac_reward=500000000` means the block reward will start at 5 RANDOMX coins per block
-    * This argument is given in satoshis
-  * `-ac_supply=55555` means an existing supply of 55555 will exist at block 1
-    * This argument is given in coins, not satoshis
-    * This is sometimes called a "pre-mine" and is useful when migrating an existing coin
-    * Block 0 of HSC's is always the BTC mainnet genesis block.
-    * So the genesis block of HSC's is actually block 1, not block 0
-  * `-gen=1` means this node is a mining node
-  * `-genproclimit=1` means use 1 CPU thread will be used for mining
-  * `-testnode=1` means only 1 node can be used to mine a genesis block
-    * testnode is primarily for testing, when launching a real genesis block, this option should not be used
-    * By default, at least two nodes are required to mine a genesis block
-    * One node would use
-```
-# first node
-./src/hush-arrakis-chain -ac_halving=100 -ac_algo=randomx -ac_name=RANDOMX -ac_private=1 -ac_blocktime=15 -ac_reward=500000000 -ac_supply=55555
-```
-    * And the second node would use:
-```
-# mining node. NOTE: This node will mine the genesis block and pre-mine, if any
-./src/hush-arrakis-chain -ac_halving=100 -ac_algo=randomx -ac_name=RANDOMX -ac_private=1 -ac_blocktime=15 -ac_reward=500000000 -ac_supply=55555 -gen=1 -genproclimit=1
-```
 
-# Advanced Options
+## RandomX key-block tuning options
 
-HUSH RandomX currently has two advanced options that some may want to use:
+RandomX periodically rotates the "key block" it derives its dataset from. Two
+advanced options control this. They are inherited from the upstream Hush /
+Arrakis-chain tooling and default to values suited to DragonX's 36s block time;
+you should not normally change them:
 
-  * `ac_randomx_interval` controls how often the RandomX key block will change
+  * `-ac_randomx_interval` controls how often the RandomX key block changes
-    * The default is 1024 blocks and is good for most use cases.
+    * Default is 1024 blocks
-    * This corresponds to ~17 hours for HSCs with the default block time of 60s
+    * At DragonX's 36s block time this is roughly ~10.2 hours
-  * `ac_randomx_lag` sets the number of blocks to wait before updating the key block
+  * `-ac_randomx_lag` sets the number of blocks to wait before updating the key block
-    * The default is 64 blocks
+    * Default is 64 blocks
-    * This corresponds to 64 mins for HSCs with the default block time of 60s
+    * At DragonX's 36s block time this is roughly ~38 minutes
-  * `ac_randomx_interval` should always be larger than 2 times `ac_randomx_lag`
+  * `-ac_randomx_interval` should always be larger than 2 times `-ac_randomx_lag`
-  * Setting these to arbitrary values could affect the chain security of your coin
+  * Setting these to arbitrary values could affect chain security
-    * It is not recommended to change these values unless you are really sure why you are doing it
+    * Do not change these values unless you are really sure why you are doing it
 
 # RandomX Internals
 
-This section is not required reading if you just want to use it as a PoW algorithm for an HSC. Here we will explain how the internals of RandomX works inside of the Hush codebase.
+This section is not required reading if you just want to run or mine DragonX.
+Here we explain how the internals of RandomX work inside the codebase.
 
-We use the official RandomX implementation from https://github.com/tevador/RandomX with custom configuration options. If some type of hardware is created to mine the XMR RandomX algorithm, it will not be compatible with the Hush RandomX algorithm. This is by design. All Hush Arrakis Chains use the same RandomX config options, so if a hardware device is created to mine one HSC that uses RandomX, it can be used to mine any HSC using RandomX. Every HSC with unique consensus parameters will start off with it's own unique key block with at least 9 bytes of entropy.
+We use the official RandomX implementation from https://github.com/tevador/RandomX
-
+with custom configuration options. Because the configuration differs from the
-The source code of RandomX is embedded in the Hush source code at `./src/RandomX` and the configuration options used are at `./src/RandomX/src/configuration.h` .
+Monero (XMR) RandomX configuration, hardware built to mine XMR RandomX is not
+compatible with DragonX's RandomX. This is by design. The source code of RandomX
+is embedded at `./src/RandomX` and the configuration options used are at
+`./src/RandomX/src/configuration.h`.
 
 The changes from default RandomX configuration options are listed below.
 
@@ -100,5 +94,4 @@ The changes from default RandomX configuration options are listed below.
 +#define RANDOMX_PROGRAM_COUNT      16
  
 ```
-RandomX opcode frequencies were not modfiied, the defaults are used.
+RandomX opcode frequencies were not modified, the defaults are used.
-

doc/release-process.md

@@ -1,4 +1,4 @@
-# Hush Release Process
+# DragonX Release Process
 
 ## High-Level Philosophy
 
@@ -6,39 +6,39 @@ Beware of making high-risk changes (such as consensus changes, p2p layer changes
 
 It is best to keep doc/relnotes/README.md up to date as changes and bug fixes are made. It's more work to summarize all changes and bugfixes just before the release.
 
-## Check for changes on master that should be on dev
+## Branch model
 
-Often there are trivial changes made directly on master, such as documentation changes. In theory, no code changes should happen on master without being on dev first, but it's better to be safe than sorry. We want the dev branch which undergoes testing to be as close as possible to what the master branch will become, so we don't want to merge dev into master and just assume everything works. So it's best to merge the master branch into dev just before merging the dev branch into master.
+Development happens on the `dev` branch. Releases are cut on the default branch, `dragonx`. There is no `master` branch. Code changes should land on `dev` first and undergo testing before being merged into `dragonx`.
 
-To check if the master branch has any changes that the dev branch does not:
+## Check for changes on dragonx that should be on dev
+
+Occasionally trivial changes are made directly on the `dragonx` branch, such as documentation changes. In theory, no code changes should happen on `dragonx` without being on `dev` first, but it's better to be safe than sorry. We want the `dev` branch which undergoes testing to be as close as possible to what the `dragonx` branch will become, so we don't want to merge `dev` into `dragonx` and just assume everything works. So it's best to merge the `dragonx` branch into `dev` just before merging the `dev` branch into `dragonx`.
+
+To check if the `dragonx` branch has any changes that the `dev` branch does not:
 
 ```
-# this assumes you are working with https://git.hush.is/hush/hush3 as your remote
+# this assumes you are working with https://git.dragonx.is/DragonX/dragonx as your remote
-git checkout dev  
-git pull               # make sure dev is up to date
-git checkout master
-git pull               # make sure master is up to date
-git diff dev...master  # look at the set of changes which exist in master but not dev
-```
-
-If the last command has no output, congrats, there is nothing to do. If the last command has output, then you should merge master into dev:
-
-```
-git checkout master
-git merge --no-ff dev # using the default commit message is fine
-git tag vX.Y.Z # this creates a tag vX.Y.Z on current master, or you can let gitea do it later
-git push --tags origin master
 git checkout dev
-git merge master
+git pull                  # make sure dev is up to date
+git checkout dragonx
+git pull                  # make sure dragonx is up to date
+git diff dev...dragonx    # look at the set of changes which exist in dragonx but not dev
+```
+
+If the last command has no output, congrats, there is nothing to do. If the last command has output, then you should merge `dragonx` into `dev`:
+
+```
+git checkout dev
+git merge dragonx
 git push origin dev
 ```
 
-The `--no-ff` flag above makes sure to make a merge commit, no matter what, even if a "fast forward" could be done. For those in the future looking back, it's much better to see evidence of when branches were merged.
+Use the `--no-ff` flag when merging `dev` into `dragonx` for a release (see below). The `--no-ff` flag makes sure to make a merge commit, no matter what, even if a "fast forward" could be done. For those in the future looking back, it's much better to see evidence of when branches were merged.
 
 
 ### Git Issues
 
-Look for Git issues that should be fixed in the next release. Especially low-risk and simple things, like documentation changes, improvements to error messages and RPC help output. 
+Look for Git issues that should be fixed in the next release. Especially low-risk and simple things, like documentation changes, improvements to error messages and RPC help output.
 
 ### Pre-release checklist:
   * Is this release changing consensus rules? Definitely update protocol version.
@@ -65,21 +65,21 @@ Install deps on Linux:
    - Edit contrib/seeds/nodes_main.txt
    - Run "make seeds"
    - Commit the result
- - Update version in configure.ac and src/clientversion.h to update the hushd version
+ - Update version in configure.ac and src/clientversion.h to update the dragonxd version
    - In src/clientversion.h you update `CLIENT_VERSION_*` variables. Usually you will just update `CLIENT_VERSION_REVISION`
    - If there is a consensus change, it may be a good idea to update `CLIENT_VERSION_MINOR` or `CLIENT_VERSION_MAJOR`
-   - To make a pre-release "beta" you can modify `CLIENT_VERSION_BUILD` but that is rarely done in Hush world.
+   - To make a pre-release "beta" you can modify `CLIENT_VERSION_BUILD` but that is rarely done.
    - A `CLIENT_VERSION_BUILD` of 50 means "actual non-beta release"
    - Make sure to keep the values in configure.ac and src/clientversion.h the same. The variables are prefixed wth an underscore in configure.ac
  - Run `./util/gen-manpages.sh`, commit + push results
-   - There is a hack in the script where you can hardcode a version number if hushd isn't compiled on this machine
+   - There is a hack in the script where you can hardcode a version number if dragonxd isn't compiled on this machine
-   - Comment out the HUSHVER line and uncomment the line above it with a hardcoded version number
+   - Comment out the version line and uncomment the line above it with a hardcoded version number
    - PROTIP: Man page creation must be done after updating the version number and recompiling and before Debian package creation
    - TODO: How to regenerate html man pages?
  - Update checkpoints in src/chainparams.cpp via util/checkpoints.pl
    - Run "./util/checkpoints.pl help" to get example usage
-   - hushd must be running to run this script, since it uses hush-cli to get the data
+   - dragonxd must be running to run this script, since it uses dragonx-cli to get the data
-   - Look for line which says "END HUSH mainnet checkpoint data" near line 560 in chainparams.cpp , that is where checkpoint data ends
+   - Look for the line which marks the end of the mainnet checkpoint data in chainparams.cpp, that is where checkpoint data ends
    - Find the highest block height of checkpoint data, let's call it HEIGHT
    - Run `./util/checkpoints.pl 1000 HEIGHT &> checkpoints.txt` to generate the latest checkpoint data
    - To copy the new data from checkpoints.txt into the file, one way in Vim is to type ":r checkpoints.txt" which will read in a file and paste it as the current cursor
@@ -89,7 +89,6 @@ Install deps on Linux:
      - By default it will generate checkpoints for every 1000 blocks, the "stride"
      - You can get a different "stride" by passing it in as the first arg to the script
      - To get checkpoint data for every 5000 blocks: `./util/checkpoints.pl 5000 &> checkpoints.txt`
-     - Currently checkpoints from before block 340k are given for every 5k blocks to keep the data smaller
    - checkpoints.pl will just generate the data you need, it must be manually copied into the correct place
    - Checkpoints are a list of block heights and block hashes that tell a full node the correct block history of the blockchain
    - Checkpoints make block verification a bit faster, because nodes can say "is this block a descendant of a checkpoint block?" instead of doing full consensus checks, which take more time
@@ -98,15 +97,15 @@ Install deps on Linux:
    - Try to generate checkpoints as close to the release as possible, so you can have a recent block height be protected.
      - For instance, don't update checkpoints and then do a release a month later. You can always update checkpoint data again or multiple times
  - Update doc/relnotes/README.md
-   - To get the stats of file changes: `git diff --stat master...dev`
+   - To get the stats of file changes: `git diff --stat dragonx...dev`
  - Do a fresh clone and fresh sync with new checkpoints
  - Stop node, wait 20 minutes, and then do a partial sync with new checkpoints
- - Merge dev into master: `git checkout dev && git pull && git checkout master && git pull && git merge --no-ff dev && git push`
+ - Merge dev into dragonx: `git checkout dev && git pull && git checkout dragonx && git pull && git merge --no-ff dev && git push`
    - The above command makes sure that your local dev branch is up to date before doing anything
    - The above command will not merge if "git pull" creates a merge conflict
    - The above command will not push if there is a problem with merging dev
- - Make Gitea release with git tag from master branch (make sure to merge dev in first)
+ - Make Gitea release with git tag from the dragonx branch (make sure to merge dev in first)
-   - Make sure git tag starts with a `v` such as `v3.9.2`
+   - Make sure git tag starts with a `v` such as `v1.0.3`
  - Use util/gen-linux-binary-release.sh to make a Linux release binary
  - Upload Linux binary to Gitea release and add SHA256 sum
  - Create an x86 Debian package for the release:
@@ -118,18 +117,14 @@ Install deps on Linux:
    - Add SHA256 checksum of .deb to release
  - Use util/build-debian-package-ARM.sh (does this still work?) to make an ARM Debian package for the release
  - Upload the debian packages to the Gitea release page, with SHA256 sums
- - Update the rpc.hush.is repo for new release by [following these instructions](https://git.hush.is/hush/rpc.hush.is/src/branch/master/README.md)
- - Update https://faq.hush.is/rpc/ for new release after updating the rpc.hush.is repo
 
 ## Platform-specific notes
 
 - Use `./util/build-mac.sh` to compile on Apple/Mac systems
 - Use `./util/build-win.sh` to build on Windows
-- Use [these cross compile instructions](https://git.hush.is/jahway603/hush-docs/src/branch/master/advanced/cross-compile-hush-full-node-to-aarch64-with-docker.md) to build the release for ARMv8 (aarch64) systems, as the current build system does not permit us to natively build this on the SBC device
-  - Then use `./util/build-debian-package.sh aarch64` to build a Debian package for ARMv8 (aarch64)
 
 ## Optional things
 
 ### Updating RandomX
 
-If you need to update the source code of our in tree copy of RandomX, see issue https://git.hush.is/hush/hush3/issues/337#issuecomment-5114 for details. Currently we use RandomX v1.2.1 from the official repo at https://github.com/tevador/RandomX/releases/tag/v1.2.1
+If you need to update the source code of our in tree copy of RandomX, open an issue in the [DragonX Git repository](https://git.dragonx.is/DragonX/dragonx/issues) to track the details. Currently we use RandomX v1.2.1 from the official repo at https://github.com/tevador/RandomX/releases/tag/v1.2.1

doc/security-warnings.md

@@ -1,24 +1,17 @@
-#Security Warnings
+# Security Warnings
 
 ## Security Audits
 
-Hush has not been subjected to a formal third-party security review! But the
+DragonX has not been subjected to a formal third-party security review. Some of
-some of the Zcash and Komodo source code it is based on has.
+the Bitcoin, Zcash, Komodo, and Hush source code it is derived from has been
-
+audited upstream, and DragonX integrates relevant fixes and recommendations from
-Hush does our best to integrate fixes and recommendations from upstream audits
+those audits where they apply.
-to our own code, such as audits on ZecWallet that apply to SilentDragon.
-Hush used to report many new bugs and CVEs to upstream Zcash and Komodo but
-those relations have broken down.
-
-Additionally, Hush itself finds many CVE's and things-that-should-be-CVE's
-in Zcash internals. Since Zcash community treats Hush people so poorly, we
-keep these bugs and fixes to ourselves. If you want to know some of them,
-let us know and bring your wallet. Public information available at
-<a href="https://attackingzcash.com">attackingzcash.com</a>
 
 ## Wallet Encryption
 
-Wallet encryption is disabled, for several reasons:
+Wallet encryption is disabled by default, for several reasons. (It can be
+enabled by running with both `-experimentalfeatures` and
+`-developerencryptwallet`, but this is not recommended for the reasons below.)
 
 - Encrypted wallets are unable to correctly detect shielded spends (due to the
   nature of unlinkability of ShieldedSpends) and can incorrectly show larger
@@ -45,13 +38,13 @@ running on your OS can read your wallet.dat file.
 
 ## Side-Channel Attacks
 
-This implementation of Hush is not resistant to side-channel attacks. You
+This implementation of DragonX is not resistant to side-channel attacks. You
 should assume (even unprivileged) users who are running on the hardware, or who
-are physically near the hardware, that your `hushd` process is running on will
+are physically near the hardware, that your `dragonxd` process is running on will
 be able to:
 
 - Determine the values of your secret spending keys, as well as which notes you
-  are spending, by observing cache side-channels as you perform a SheildedSpend
+  are spending, by observing cache side-channels as you perform a ShieldedSpend
   operation. This is due to probable side-channel leakage in C++.
 
 - Determine which notes you own by observing cache side-channel information
@@ -61,7 +54,7 @@ be able to:
   each note ciphertext on the blockchain.
 
 You should ensure no other users have the ability to execute code (even
-unprivileged) on the hardware your `hushd` process runs on until these
+unprivileged) on the hardware your `dragonxd` process runs on until these
 vulnerabilities are fully analyzed and fixed.
 
 ## REST Interface
@@ -72,13 +65,16 @@ security review.
 
 ## RPC Interface
 
-Users should choose a strong RPC password. If no RPC username and password are set, hush will not start and will print an error message with a suggestion for a strong random password. If the client knows the RPC password, they have at least full access to the node. In addition, certain RPC commands can be misused to overwrite files and/or take over the account that is running hushd. (In the future we may restrict these commands, but full node access – including the ability to spend from and export keys held by the wallet – would still be possible unless wallet methods are disabled.)
+Users should choose a strong RPC password. If no RPC username and password are set, dragonxd will not start and will print an error message with a suggestion for a strong random password. If the client knows the RPC password, they have at least full access to the node. In addition, certain RPC commands can be misused to overwrite files and/or take over the account that is running dragonxd. (In the future we may restrict these commands, but full node access – including the ability to spend from and export keys held by the wallet – would still be possible unless wallet methods are disabled.)
 
-Users should also refrain from changing the default setting that only allows RPC connections from localhost. Allowing connections from remote hosts would enable a MITM to execute arbitrary RPC commands, which could lead to compromise of the account running hushd and loss of funds. For multi-user services that use one or more hushd instances on the backend, the parameters passed in by users should be controlled to prevent confused-deputy attacks which could spend from any keys held by that zcashd.
+Users should also refrain from changing the default setting that only allows RPC connections from localhost. Allowing connections from remote hosts would enable a MITM to execute arbitrary RPC commands, which could lead to compromise of the account running dragonxd and loss of funds. For multi-user services that use one or more dragonxd instances on the backend, the parameters passed in by users should be controlled to prevent confused-deputy attacks which could spend from any keys held by that dragonxd.
 
-## Block Chain Reorganization: Major Differences
+## Block Chain Reorganization
 
-Hush has Delayed-Proof-of-Work, which drastically improves the Zcash rule-of-thumb of "re-organize 100 blocks to crash all ZEC full nodes in the world".
+DragonX inherits Komodo's Delayed-Proof-of-Work (dPoW) notarization code from its
+Hush lineage. Note that DragonX does not currently run its own notary
+infrastructure, so you should not assume active dPoW reorg protection. Treat deep
+reorganizations as possible and wait for sufficient confirmations accordingly.
 
 ## Logging z_* RPC calls
 

doc/shield-coinbase.md

@@ -2,55 +2,69 @@
 
 **Summary**
 
-Use `z_shieldcoinbase` RPC call to shield coinbase UTXOs.
+Use the `z_shieldcoinbase` RPC call to move mining coinbase UTXOs into the shielded pool.
 
 **Who should read this document**
 
-Miners, Mining pools, Online wallets
+Miners, mining pools, online wallets.
 
 ## Background
 
-The current Hush protocol includes a consensus rule that coinbase rewards must be sent to a shielded address.
+DragonX is a fully private chain from genesis (`ac_private=1`, Sapling active at
+height 1). All ordinary payments are shielded (`z2z`) and transparent addresses can
+never be transaction recipients — they only ever receive mining coinbase.
+
+There is **no** consensus rule that coinbase must be shielded: mature coinbase is
+directly spendable. `z_shieldcoinbase` is therefore an optional convenience for
+miners who want to move coinbase into the shielded pool for privacy, and to sweep
+up many small coinbase UTXOs in a single operation. See
+[hd-transparent-keys.md](hd-transparent-keys.md) for how transparent coinbase keys
+work on a private chain.
 
 ## User Experience Challenges
 
-A user can use the z_sendmany RPC call to shield coinbase funds, but the call was not designed for sweeping up many UTXOs, and offered a suboptimal user experience.
+A user can use the `z_sendmany` RPC call to shield coinbase funds, but that call was
+not designed for sweeping up many UTXOs and offers a suboptimal experience.
 
-If customers send mining pool payouts to their online wallet, the service provider must sort through UTXOs to correctly determine the non-coinbase UTXO funds that can be withdrawn or transferred by customers to another transparent address.
+If customers send mining pool payouts to their online wallet, the service provider
+must sort through UTXOs to correctly determine the non-coinbase UTXO funds that can be
+withdrawn or transferred by customers.
 
 ## Solution
 
-The z_shieldcoinbase call makes it easy to sweep up coinbase rewards from multiple coinbase UTXOs across multiple coinbase reward addresses.
+The `z_shieldcoinbase` call makes it easy to sweep up coinbase rewards from multiple
+coinbase UTXOs across multiple coinbase reward addresses.
 
     z_shieldcoinbase fromaddress toaddress (fee) (limit)
 
-The default fee is 0.0010000 HUSH and the default limit on the maximum number of UTXOs to shield is 50.
+The default fee is 0.0001 DRAGONX and the default limit on the maximum number of UTXOs
+to shield is 50.
 
 ## Examples
 
 Sweep up coinbase UTXOs from a transparent address you use for mining:
 
-    hush-cli z_shieldcoinbase tMyMiningAddress zMyPrivateAddress
+    dragonx-cli z_shieldcoinbase RMyMiningAddress zsMyPrivateAddress
 
 Sweep up coinbase UTXOs from multiple transparent addresses to a shielded address:
 
-    hush-cli z_shieldcoinbase "*" zMyPrivateAddress
+    dragonx-cli z_shieldcoinbase "*" zsMyPrivateAddress
 
-Sweep up with a fee of 1.23 HUSH:
+Sweep up with a fee of 1.23 DRAGONX:
 
-    hush-cli z_shieldcoinbase tMyMiningAddress zMyPrivateAddress 1.23
+    dragonx-cli z_shieldcoinbase RMyMiningAddress zsMyPrivateAddress 1.23
 
-Sweep up with a fee of 0.1 HUSH and set limit on the maximum number of UTXOs to shield at 25:
+Sweep up with a fee of 0.1 DRAGONX and set limit on the maximum number of UTXOs to shield at 25:
 
-    hush-cli z_shieldcoinbase "*" zMyPrivateAddress 0.1 25
+    dragonx-cli z_shieldcoinbase "*" zsMyPrivateAddress 0.1 25
 
 ### Asynchronous Call
 
-The `z_shieldcoinbase` RPC call is an asynchronous call, so you can queue up multiple operations. 
+The `z_shieldcoinbase` RPC call is an asynchronous call, so you can queue up multiple operations.
 
 When you invoke
 
-    hush-cli z_shieldcoinbase tMyMiningAddress zMyPrivateAddress
+    dragonx-cli z_shieldcoinbase RMyMiningAddress zsMyPrivateAddress
 
 JSON will be returned immediately, with the following data fields populated:
 
@@ -70,13 +84,13 @@ You can use the RPC call `lockunspent` to see which UTXOs have been locked.  You
 
 The number of coinbase UTXOs selected for shielding can be adjusted by setting the limit parameter. The default value is 50.
 
-If the limit parameter is set to zero, the zcashd `mempooltxinputlimit` option will be used instead, where the default value for `mempooltxinputlimit` is zero, which means no limit.
+If the limit parameter is set to zero, the `mempooltxinputlimit` option will be used instead, where the default value for `mempooltxinputlimit` is zero, which means no limit.
 
 Any limit is constrained by a hard limit due to the consensus rule defining a maximum transaction size.
 
 In general, the more UTXOs that are selected, the longer it takes for the transaction to be verified.  Due to the quadratic hashing problem, some miners use the `mempooltxinputlimit` option to reject transactions with a large number of UTXO inputs.
 
-Currently, as of November 2017, there is no commonly agreed upon limit, but as a rule of thumb (a form of emergent consensus) if a transaction has less than 100 UTXO inputs, the transaction will be mined promptly by the majority of mining pools, but if it has many more UTXO inputs, such as 500, it might take several days to be mined by a miner who has higher or no limits.
+As a rule of thumb (a form of emergent consensus) if a transaction has less than 100 UTXO inputs, the transaction will be mined promptly by the majority of mining pools, but if it has many more UTXO inputs, such as 500, it might take longer to be mined by a miner who has higher or no limits.
 
 ### Anatomy of a z_shieldcoinbase transaction
 

doc/tests.md

@@ -11,12 +11,14 @@ There are two scripts for running tests:
 The main test suite uses two different testing frameworks. Tests using the Boost
 framework are under ``src/test/``; tests using the Google Test/Google Mock
 framework are under ``src/gtest/`` and ``src/wallet/gtest/``. The latter framework
-is preferred for new Hush unit tests.
+is preferred for new DragonX unit tests.
 
 RPC tests are implemented in Python under the ``qa/rpc-tests/`` directory.
 
 # Example
 
-To run the Delayed-Proof-of-Work tests:
+To run a single RPC test, pass its name to the runner. For example, the
+inherited `dpowconfs` test (a regtest-only test carried over from the upstream
+codebase):
 
 	./qa/pull-tester/rpc-tests.sh dpowconfs

doc/tor.md

@@ -1,21 +1,20 @@
 # Tor
 
-It is possible to run Hush as a Tor onion service, and connect to such services.
+It is possible to run DragonX as a Tor onion service, and connect to such services.
 
 The following directions assume you have a Tor proxy running on port 9050. Many distributions default to having a SOCKS proxy listening on port 9050, but others may not. In particular, the Tor Browser Bundle defaults to listening on port 9150. See [Tor Project FAQ:TBBSocksPort](https://www.torproject.org/docs/faq.html.en#TBBSocksPort) for how to properly
 configure Tor.
 
 ## Compatibility
 
-- Starting with version 3.9.3, Hush only supports Tor version 3 hidden
+- DragonX only supports Tor version 3 hidden services (Tor v3). Tor v2
-  services (Tor v3). Tor v2 addresses are ignored by Hush and neither
+  addresses are ignored by DragonX and neither relayed nor stored.
-  relayed nor stored.
 
 - Tor removed v2 support beginning with version 0.4.6.
 
-## How to see information about your Tor configuration via Hush
+## How to see information about your Tor configuration via DragonX
 
-There are several ways to see your local onion address in Hush:
+There are several ways to see your local onion address in DragonX:
 - in the "localaddresses" output of RPC `getnetworkinfo`
 - in the debug log (grep for "AddLocal"; the Tor address ends in `.onion`)
 
@@ -26,9 +25,9 @@ CLI `-addrinfo` returns the number of addresses known to your node per
 network. This can be useful to see how many onion peers your node knows,
 e.g. for `-onlynet=onion`.
 
-## 1. Run Hush behind a Tor proxy
+## 1. Run DragonX behind a Tor proxy
 
-The first step is running Hush behind a Tor proxy. This will already anonymize all
+The first step is running DragonX behind a Tor proxy. This will already anonymize all
 outgoing connections, but more is possible.
 
     -proxy=ip:port  Set the proxy server. If SOCKS5 is selected (default), this proxy
@@ -61,22 +60,22 @@ outgoing connections, but more is possible.
 
 In a typical situation, this suffices to run behind a Tor proxy:
 
-    ./hushd -proxy=127.0.0.1:9050
+    ./dragonxd -proxy=127.0.0.1:9050
 
-## 2. Automatically create a Hush onion service
+## 2. Automatically create a DragonX onion service
 
-Hush makes use of Tor's control socket API to create and destroy
+DragonX makes use of Tor's control socket API to create and destroy
 ephemeral onion services programmatically. This means that if Tor is running and
-proper authentication has been configured, Hush automatically creates an
+proper authentication has been configured, DragonX automatically creates an
 onion service to listen on. The goal is to increase the number of available
 onion nodes.
 
-This feature is enabled by default if Hush is listening (`-listen`) and
+This feature is enabled by default if DragonX is listening (`-listen`) and
 it requires a Tor connection to work. It can be explicitly disabled with
 `-listenonion=0`. If it is not disabled, it can be configured using the
 `-torcontrol` and `-torpassword` settings.
 
-To see verbose Tor information in the hushd debug log, pass `-debug=tor`.
+To see verbose Tor information in the dragonxd debug log, pass `-debug=tor`.
 
 ### Control Port
 
@@ -104,20 +103,20 @@ DataDirectoryGroupReadable 1
 ### Authentication
 
 Connecting to Tor's control socket API requires one of two authentication
-methods to be configured: cookie authentication or hushd's `-torpassword`
+methods to be configured: cookie authentication or dragonxd's `-torpassword`
 configuration option.
 
 #### Cookie authentication
 
-For cookie authentication, the user running hushd must have read access to
+For cookie authentication, the user running dragonxd must have read access to
 the `CookieAuthFile` specified in the Tor configuration. In some cases this is
 preconfigured and the creation of an onion service is automatic. Don't forget to
-use the `-debug=tor` hushd configuration option to enable Tor debug logging.
+use the `-debug=tor` dragonxd configuration option to enable Tor debug logging.
 
 If a permissions problem is seen in the debug log, e.g. `tor: Authentication
 cookie /run/tor/control.authcookie could not be opened (check permissions)`, it
 can be resolved by adding both the user running Tor and the user running
-hushd to the same Tor group and setting permissions appropriately.
+dragonxd to the same Tor group and setting permissions appropriately.
 
 On Debian-derived systems, the Tor group will likely be `debian-tor` and one way
 to verify could be to list the groups and grep for a "tor" group name:
@@ -134,14 +133,14 @@ TORGROUP=$(stat -c '%G' /run/tor/control.authcookie)
 ```
 
 Once you have determined the `${TORGROUP}` and selected the `${USER}` that will
-run hushd, run this as root:
+run dragonxd, run this as root:
 
 ```
 usermod -a -G ${TORGROUP} ${USER}
 ```
 
 Then restart the computer (or log out) and log in as the `${USER}` that will run
-hushd.
+dragonxd.
 
 #### `torpassword` authentication
 
@@ -155,22 +154,22 @@ Manual](https://2019.www.torproject.org/docs/tor-manual.html.en) for more
 details).
 
 
-## 3. Manually create a Hush onion service
+## 3. Manually create a DragonX onion service
 
 You can also manually configure your node to be reachable from the Tor network.
 Add these lines to your `/etc/tor/torrc` (or equivalent config file):
 
-    HiddenServiceDir /var/lib/tor/hush-service/
+    HiddenServiceDir /var/lib/tor/dragonx-service/
     HiddenServicePort 18030 127.0.0.1:18032
 
 The directory can be different of course, but virtual port numbers should be equal to
-your hushd's P2P listen port (18030 by default), and target addresses and ports
+your dragonxd's P2P listen port (18030 by default), and target addresses and ports
 should be equal to binding address and port for inbound Tor connections (127.0.0.1:18032 by default).
 
-    -externalip=X   You can tell hush about its publicly reachable addresses using
+    -externalip=X   You can tell dragonx about its publicly reachable addresses using
                     this option, and this can be an onion address. Given the above
                     configuration, you can find your onion address in
-                    /var/lib/tor/hush-service/hostname. For connections
+                    /var/lib/tor/dragonx-service/hostname. For connections
                     coming from unroutable addresses (such as 127.0.0.1, where the
                     Tor proxy typically runs), onion addresses are given
                     preference for your node to advertise itself with.
@@ -192,29 +191,29 @@ should be equal to binding address and port for inbound Tor connections (127.0.0
 
 In a typical situation, where you're only reachable via Tor, this should suffice:
 
-    ./hushd -proxy=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -listen
+    ./dragonxd -proxy=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -listen
 
 (obviously, replace the .onion address with your own). It should be noted that you still
 listen on all devices and another node could establish a clearnet connection, when knowing
 your address. To mitigate this, additionally bind the address of your Tor proxy:
 
-    ./hushd ... -bind=127.0.0.1
+    ./dragonxd ... -bind=127.0.0.1
 
 If you don't care too much about hiding your node, and want to be reachable on IPv4
 as well, use `discover` instead:
 
-    ./hushd ... -discover
+    ./dragonxd ... -discover
 
 and open port 18030 on your firewall (or use port mapping, i.e., `-upnp` or `-natpmp`).
 
 If you only want to use Tor to reach .onion addresses, but not use it as a proxy
 for normal IPv4/IPv6 communication, use:
 
-    ./hushd -onion=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -discover
+    ./dragonxd -onion=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -discover
 
 ## 4. Privacy recommendations
 
-- Do not add anything but Hush ports to the onion service created in section 3.
+- Do not add anything but DragonX ports to the onion service created in section 3.
   If you run a web service too, create a new onion service for that.
   Otherwise it is trivial to link them, which may reduce privacy. Onion
   services created automatically (as in section 2) always have only one port

doc/translation_strings_policy.md

@@ -1,6 +1,6 @@
 # Translation Strings Policy
 
-This document provides guidelines for internationalization of hushd full node software.
+This document provides guidelines for internationalization of dragonxd full node software.
 
 ## How to translate?
 

doc/wallet-backup.md

@@ -2,37 +2,42 @@
 
 ## Overview
 
-Backing up your Hush private keys is the best way to be proactive about preventing loss of access to your HUSH.
+Backing up your DragonX private keys is the best way to be proactive about preventing loss of access to your DRAGONX.
 
 Problems resulting from bugs in the code, user error, device failure, etc. may lead to losing access to your wallet (and as a result, the private keys of addresses which are required to spend from them).
 
-No matter what the cause of a corrupted or lost wallet could be, we highly recommend all users backup on a regular basis. Anytime a new address in the wallet is generated, we recommending making a new backup so all private keys for addresses in your wallet are safe.
+No matter what the cause of a corrupted or lost wallet could be, we highly recommend all users backup on a regular basis. Anytime a new address in the wallet is generated, we recommend making a new backup so all private keys for addresses in your wallet are safe.
 
-Note that a backup is a duplicate of data needed to spend HUSH so where you keep your backup(s) is another important consideration. You should not store backups where they would be equally or increasingly susceptible to loss or theft. 
+Note that a backup is a duplicate of data needed to spend DRAGONX so where you keep your backup(s) is another important consideration. You should not store backups where they would be equally or increasingly susceptible to loss or theft.
+
+Because DragonX is a fully private chain (all ordinary funds live on shielded `zs...`
+addresses), the shielded keys are what you must protect. The only transparent value a
+normal user ever holds is mining coinbase; see
+[hd-transparent-keys.md](hd-transparent-keys.md).
 
 ## Instructions for backing up your wallet and/or private keys
 
-These instructions are specific for the officially supported Hush Linux client. For backing up with third-party wallets, please consult with user guides or support channels provided for those services.
+These instructions are for the DragonX full-node command-line client. For backing up with third-party wallets, please consult the user guides or support channels provided for those services.
 
-There are multiple ways to make sure you have at least one other copy of the private keys needed to spend your HUSH and view your shielded HUSH.
+There are multiple ways to make sure you have at least one other copy of the private keys needed to spend your DRAGONX and view your shielded DRAGONX.
 
-For all methods, you will need to include an export directory setting in your config file (`HUSH3.conf` located in the data directory which is `~/.hush/HUSH3` or `~/.komodo/HUSH3` (Legacy Location) unless it's been overridden with `datadir=` setting):
+For all methods, you will need to include an export directory setting in your config file (`DRAGONX.conf` located in the data directory, which is `~/.hush/DRAGONX` unless it's been overridden with the `datadir=` setting):
 
 `exportdir=path/to/chosen/export/directory`
 
-You may chose any directory within the home directory as the location for export & backup files. If the directory doesn't exist, it will be created.
+You may choose any directory within the home directory as the location for export & backup files. If the directory doesn't exist, it will be created.
 
-Note that hushd will need to be stopped and restarted for edits in the config file to take effect. 
+Note that dragonxd will need to be stopped and restarted for edits in the config file to take effect.
 
 ### Using `backupwallet`
 
 To create a backup of your wallet, use:
 
-`hush-cli backupwallet <nameofbackup>`.
+`dragonx-cli backupwallet <nameofbackup>`.
 
 The backup will be an exact copy of the current state of your wallet.dat file stored in the export directory you specified in the config file. The file path will also be returned.
 
-If you generate a new Hush address, it will not be reflected in the backup file.
+If you generate a new DragonX address, it will not be reflected in the backup file.
 
 If your original `wallet.dat` file becomes inaccessible for whatever reason, you can use your backup by copying it into your data directory and renaming the copy to `wallet.dat`.
 
@@ -40,51 +45,56 @@ If your original `wallet.dat` file becomes inaccessible for whatever reason, you
 
 If you prefer to have an export of your private keys in human readable format, you can use:
 
-`hush-cli z_exportwallet <nameofbackup>`
+`dragonx-cli z_exportwallet <nameofbackup>`
 
 This will generate a file in the export directory listing all transparent and shielded private keys with their associated public addresses. The file path will be returned in the command line.
 
 To import keys into a wallet which were previously exported to a file, use:
 
-`hush-cli z_importwallet <path/to/exportdir/nameofbackup>`
+`dragonx-cli z_importwallet <path/to/exportdir/nameofbackup>`
 
 ### Using `z_exportkey`, `z_importkey`, `dumpprivkey` & `importprivkey`
 
-If you prefer to export a single private key for a shielded address, you can use:
+For normal use, the shielded (`z_exportkey` / `z_importkey`) commands are what you need:
+they back up and restore the `zs...` addresses that hold your spendable funds. The
+transparent commands (`dumpprivkey` / `importprivkey`) only matter if you mine, since on
+DragonX transparent value only exists as mining coinbase.
 
-`hush-cli z_exportkey <z-address>`
+To export a single private key for a shielded address, use:
+
+`dragonx-cli z_exportkey <z-address>`
 
 This will return the private key and will not create a new file.
 
-For exporting a single private key for a transparent address, you can use the command inherited from Bitcoin:
+For exporting a single private key for a transparent (mining coinbase) address, use the command inherited from Bitcoin:
 
-`hush-cli dumpprivkey <t-address>`
+`dragonx-cli dumpprivkey <t-address>`
 
 This will return the private key and will not create a new file.
 
 To import a private key for a shielded address, use:
 
-`hush-cli z_importkey <z-priv-key>`
+`dragonx-cli z_importkey <z-priv-key>`
 
 This will add the key to your wallet and rescan the wallet for associated transactions if it is not already part of the wallet.
 
 The rescanning process can take a few minutes for a new private key. To skip it, instead use:
 
-`hush-cli z_importkey <z-private-key> no`
+`dragonx-cli z_importkey <z-private-key> no`
 
 For other instructions on fine-tuning the wallet rescan, see the command's help documentation:
 
-`hush-cli help z_importkey`
+`dragonx-cli help z_importkey`
 
-To import a private key for a transparent address, use:
+To import a private key for a transparent (mining coinbase) address, use:
 
-`hush-cli importprivkey <t-priv-key>`
+`dragonx-cli importprivkey <t-priv-key>`
 
 This has the same functionality as `z_importkey` but works with transparent addresses.
 
 See the command's help documentation for instructions on fine-tuning the wallet rescan:
 
-`hush-cli help importprivkey`
+`dragonx-cli help importprivkey`
 
 ### Using `dumpwallet`
 

doc/zsweep-consolidation.md

@@ -1,6 +1,6 @@
 # zsweep and consolidation
 
-This is to document zsweep and consolidation for advanced HUSH users.
+This is to document zsweep and consolidation for advanced DragonX users.
 
 **Warning: If you don't know what Zsweep or Consolidation are, there is a good chance that you will not be using these advanced options. User beware!**
 
@@ -11,9 +11,9 @@ This is to document zsweep and consolidation for advanced HUSH users.
 
 # Pre-Step & Further Details
 
-A user can use these options at the command line, but it is **recommended to configure these options within the HUSH3.conf file**.
+A user can use these options at the command line, but it is **recommended to configure these options within the DRAGONX.conf file**.
 
-Consolidation takes many unspent shielded UTXOs (zutxos) into one zutxo, which makes spending them in the future faster and potentially cost less in fees. It also helps prevent certain kinds of metadata leakages and spam attacks. It is not recommended for very large wallets (wallet.dat files with thousands of transactions) for performance reasons. This is why it defaults to OFF for CLI full nodes but ON for GUI wallets that use an embedded hushd.
+Consolidation takes many unspent shielded UTXOs (zutxos) into one zutxo, which makes spending them in the future faster and potentially cost less in fees. It also helps prevent certain kinds of metadata leakages and spam attacks. It is not recommended for very large wallets (wallet.dat files with thousands of transactions) for performance reasons. This is why it defaults to OFF for CLI full nodes but ON for GUI wallets that use an embedded dragonxd.
 
 Zsweep is when you sweep numerous zutxos into one z-address that you configure. This z-address can be local to that system or it can be configured to sweep to a remote wallet on a different system with the zsweepexternal=1 option, which is explained below in the Zsweep section.
 
@@ -33,11 +33,11 @@ Zsweep is when you sweep numerous zutxos into one z-address that you configure.
 	|-------------------|-------------------------|
 	| zsweepexternal=1	| Will enable the option to zsweep to an "external" z-address which exists in a wallet on a different system. |
 	| zsweepinterval=5	| By default zsweep runs every 5 blocks, so set and modify this value to change that. |
-	| zsweepmaxinputs=50 | By default zsweep makes sure to not reduce the anonset in any tx by having a maximum number of inputs of 8. This should be fine for new wallets, but if you have an existing wallet with many zutxos it can be changed with this option. Keep in mind that large values will make sweeping faster at the expense of reducing the AnonSet. |
+	| zsweepmaxinputs=8 | By default zsweep makes sure to not reduce the anonset in any tx by having a maximum number of inputs of 8. This should be fine for new wallets, but if you have an existing wallet with many zutxos it can be changed with this option. Keep in mind that large values will make sweeping faster at the expense of reducing the AnonSet. |
-	| zsweepfee=0 | The default zsweep fee is 10000 puposhis or 0.0001 HUSH, the default for all transactions. To use fee=0 for zsweep transactions, set this option. |
+	| zsweepfee=0 | The default zsweep fee is 10000 puposhis or 0.0001 DRAGONX, the default for all transactions. To use fee=0 for zsweep transactions, set this option. |
     | zsweepexclude=zs1... | Exclude a certain address from being swept. Can be used multiple times to exclude multiple addressses |
 
-1. The following HUSH RPC will let you view your zsweep configuration options and run-time stats at the command line: `hush-cli z_sweepstatus`
+1. The following DragonX RPC will let you view your zsweep configuration options and run-time stats at the command line: `dragonx-cli z_sweepstatus`
 
 ## Consolidation
 
@@ -50,10 +50,10 @@ Zsweep is when you sweep numerous zutxos into one z-address that you configure.
 
 	| Consolidation Option Name| Details of what it does |
 	|--------------------------|-------------------------|
-	| consolidationtxfee=0     | The default consolidation fee is 10000 puposhis or 0.0001 HUSH, the default for all transactions. To use fee=0 for consolidation transactions, set this option. |
+	| consolidationtxfee=0     | The default consolidation fee is 10000 puposhis or 0.0001 DRAGONX, the default for all transactions. To use fee=0 for consolidation transactions, set this option. |
 	| consolidatesaplingaddress=zs1... | Default of consolidation is set to all, but you can set this option if you have one specific z-address (zs1... is a placeholder for this documentation) that you want to only consolidate to. |
 
-1. The following HUSH RPC will let you view your consolidation configuration options and run-time stats at the command line: `hush-cli z_sweepstatus`
+1. The following DragonX RPC will let you view your consolidation configuration options and run-time stats at the command line: `dragonx-cli z_sweepstatus`
 
 ## Zsweep & Consolidation Together
 
@@ -68,7 +68,7 @@ Zsweep is when you sweep numerous zutxos into one z-address that you configure.
 
 ### Copyright
 
-jahway603 and The Hush Developers
+The DragonX Developers, jahway603, and The Hush Developers
 
 ### License
 

qa/rpc-tests/README.md

@@ -20,7 +20,7 @@ Possible options:
 -h, --help       show this help message and exit
   --nocleanup      Leave binaries and test.* datadir on exit or error
   --noshutdown     Don't stop full node after the test execution
-  --srcdir=SRCDIR  Source directory containing hushd/hush-cli (default: ../../src)
+  --srcdir=SRCDIR  Source directory containing dragonxd/dragonx-cli (default: ../../src)
   --tmpdir=TMPDIR  Root directory for datadirs
   --tracerpc       Print out all RPC calls as they are made
 ```
@@ -30,7 +30,9 @@ If you set the environment variable `PYTHON_DEBUG=1` you will get some debug out
 A 200-block -regtest blockchain and wallets for four nodes
 is created the first time a regression test is run and
 is stored in the cache/ directory.  Each node has the miner
-subsidy from 25 mature blocks (`25*10=250 HUSH`) in its wallet.
+subsidy from 25 mature blocks in its wallet. The exact amount in DRAGONX
+depends on the per-test `-ac_reward` (regtest subsidy), so it is not a
+fixed figure across tests.
 
 After the first run, the cache/ blockchain and wallets are
 copied into a temporary directory and used as the initial
@@ -40,7 +42,7 @@ If you get into a bad state, you should be able to recover with:
 
 ```bash
 rm -rf cache
-killall hushd
+killall dragonxd
 ```
 
 but beware that could kill various other processes you might not want to kill!

util/README.md

@@ -1,52 +1,64 @@
-# Hush utilities
+# DragonX utilities
 
-Scripts in this directory are used by Hush developers in the process of development
+Scripts in this directory are used by DragonX developers in the process of development
-or in releasing a new version of Hush.
+or in releasing a new version of DragonX.
 
 Utilities in this directory:
 
 ## build.sh
 
-Compile Hush full node code.
+Compile DragonX full node code. This is the main build entrypoint.
 
 ## build-arm.sh
 
-Compile Hush full node code for ARM architecture.
+Compile DragonX full node code for ARM architecture.
 **has not worked for some time**
 
 ## build-arm-xcompile.sh
 
-Cross-Compile Hush full node code for ARM architecture on an x86 build server.
+Cross-Compile DragonX full node code for ARM architecture on an x86 build server.
 
 ## build-debian-package.sh
 
-Builds an x86 Debain package for Hush.
+Builds an x86 Debian package for DragonX.
 
 ## build-debian-package-ARM.sh
 
-Builds an ARM Debain package for Hush.
+Builds an ARM Debian package for DragonX.
 
 ## build-mac.sh
 
-Compile Hush full node code for mac. NOTE: This is likely broken.
+Compile DragonX full node code for mac. NOTE: This is likely broken.
 
 ## build-win.sh
 
-Compile Hush full node code for windows
+Compile DragonX full node code for windows
+
+## bootstrap-dragonx.sh
+
+Download and apply a DRAGONX blockchain bootstrap so a new node can sync quickly.
+Safely preserves wallet.dat and configuration files, and verifies the archive against
+checksums and (once configured) a detached signature. See sign-bootstrap.md for the
+signing procedure.
+
+## sign-bootstrap.md
+
+Documentation for maintainers on how to create the signing keypair and sign the
+DRAGONX.zip bootstrap archive that bootstrap-dragonx.sh verifies.
 
 ## checkpoints.pl
 
 Generate checkpoint data for chainparams.cpp . This automates the creation of
-block heights and block hashes by asking hushd for the data and then generating
+block heights and block hashes by asking dragonxd (via dragonx-cli) for the data
-the C++ code needed to embed them in the Hush source code.
+and then generating the C++ code needed to embed them in the DragonX source code.
 
 ## docker-entrypoint.sh
 
-Script to use Hush with Docker.
+Script to use DragonX with Docker.
 
 ## docker-hush-cli.sh
 
-Convenience script to run hush-cli in a running Docker container.
+Convenience script to run dragonx-cli in a running Docker container.
 
 ## replace.pl
 

util/afl/afl-get.sh

@@ -30,7 +30,7 @@ mv afl-*/* .
 # Build AFL
 make
 
-echo "You can now build hushd with AFL instrumentation as follows:"
+echo "You can now build dragonxd with AFL instrumentation as follows:"
-echo "$ make clean # if you've already built hushd without AFL instrumentation"
+echo "$ make clean # if you've already built dragonxd without AFL instrumentation"
 echo "$ ./util/afl/afl-build.sh '$(pwd)' <fuzz case> -j\$(nproc)"
 echo "...where <fuzz case> is the name of a directory in src/fuzzing."

util/afl/afl-getbuildrun.sh

@@ -2,8 +2,8 @@
 # Copyright (c) 2016-2024 The Hush developers
 # Distributed under the GPLv3 software license, see the accompanying
 # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
-# Builds AFL and an instrumented hushd, then begins fuzzing.
+# Builds AFL and an instrumented dragonxd, then begins fuzzing.
-# This script must be run from within the top level directory of a hush clone.
+# This script must be run from within the top level directory of a DragonX clone.
 # Pass it the name of a directory in ./src/fuzzing.
 # Additional arguments are passed-through to AFL.
 

util/afl/afl-run.sh

@@ -9,4 +9,4 @@ AFL_INSTALL_DIR="$1"
 FUZZ_CASE="$2"
 shift 2
 
-"$AFL_INSTALL_DIR/afl-fuzz" -i "./src/fuzzing/$FUZZ_CASE/input" -o "./src/fuzzing/$FUZZ_CASE/output" "$@" ./src/hushd @@
+"$AFL_INSTALL_DIR/afl-fuzz" -i "./src/fuzzing/$FUZZ_CASE/input" -o "./src/fuzzing/$FUZZ_CASE/output" "$@" ./src/dragonxd @@

util/build-arm-xcompile.sh

@@ -3,8 +3,8 @@
 # Distributed under the GPLv3 software license, see the accompanying
 # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
 
-# For use with https://git.hush.is/jahway603/hush-docs/src/branch/master/advanced/cross-compile-hush-full-node-to-aarch64-with-docker.md,
+# Cross-compiles a DragonX full node to aarch64 (ARM) using an aarch64 GCC toolchain.
-# Please follow that
+# Intended to be run inside a Docker builder with the aarch64-linux-gnu cross toolchain installed.
 set -eu -o pipefail
 
 # Check if cmake, a new dependency for randomx support, is installed on system and exits if it is not
@@ -21,12 +21,12 @@ function cmd_pref() {
     fi
 }
 cat <<'EOF'
- .~~~~~~~~~~~~~~~~.
+ .~~~~~~~~~~~~~~~~~~~.
-{{ Building Hush!! }}
+{{ Building DragonX!! }}
- `~~~~~~~~~~~~~~~~`
+ `~~~~~~~~~~~~~~~~~~~`
         \   ^__^
-         \  (@@)\_______            
+         \  (@@)\_______
-            (__)\ HUSH  )\/\      $
+            (__)\DRAGONX)\/\      $
     z        zz ||----w |      z  |
 zz  zz  z       || z   ||xxx   z z|z zz
 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
@@ -65,15 +65,15 @@ if [ "x$*" = 'x--help' ]
 then
     cat ./util/dragon.txt
     cat <<EOF
-Welcome To The Hush Build System, Here Be Dragons!
+Welcome To The DragonX Build System, Here Be Dragons!
 Usage:
 $0 --help
   Show this help message and exit.
 $0 [ --enable-lcov || --disable-tests ] [ --disable-mining ] [ --disable-libs ] [ MAKEARGS... ]
-  Build Hush and most of its transitive dependencies from source. MAKEARGS are applied to both dependencies and Hush itself.
+  Build DragonX and most of its transitive dependencies from source. MAKEARGS are applied to both dependencies and DragonX itself.
-  If --enable-lcov is passed, Hush is configured to add coverage instrumentation, thus enabling "make cov" to work.
+  If --enable-lcov is passed, DragonX is configured to add coverage instrumentation, thus enabling "make cov" to work.
-  If --disable-tests is passed instead, the Hush tests are not built.
+  If --disable-tests is passed instead, the DragonX tests are not built.
-  If --disable-mining is passed, Hush is configured to not build any mining code. It must be passed after the test arguments, if present.
+  If --disable-mining is passed, DragonX is configured to not build any mining code. It must be passed after the test arguments, if present.
   It must be passed after the test/mining arguments, if present.
 EOF
     exit 0

util/build-debian-package.sh

@@ -1,5 +1,6 @@
 #!/usr/bin/env bash
 # Copyright (c) 2016-2024 The Hush developers
+# Copyright (c) 2024-2026 The DragonX developers
 # Distributed under the GPLv3 software license, see the accompanying
 # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
 ## Usages:
@@ -15,7 +16,7 @@ else
 fi
 
 ARCH=${1:-amd64}
-echo "Let There Be Hush Debian Packages"
+echo "Let There Be DragonX Debian Packages"
 
 # Check if lintian is installed and give details about installing
 # It is an optional dependency
@@ -35,8 +36,8 @@ fi
 set -e
 set -x
 
-BUILD_PATH="/tmp/hush-debian-$$"
+BUILD_PATH="/tmp/dragonx-debian-$$"
-PACKAGE_NAME="hush"
+PACKAGE_NAME="dragonx"
 SRC_PATH=`pwd`
 SRC_DEB=$SRC_PATH/contrib/debian
 SRC_DOC=$SRC_PATH/doc
@@ -47,9 +48,9 @@ if [ ! -d $BUILD_PATH ]; then
     mkdir $BUILD_PATH
 fi
 
-# If hushd is not currently running, package version can be hardcoded
+# If dragonxd is not currently running, package version can be hardcoded
-#PACKAGE_VERSION=3.6.0
+#PACKAGE_VERSION=1.0.3
-PACKAGE_VERSION=$($SRC_PATH/src/hushd --version|grep version|cut -d' ' -f4|cut -d- -f1|sed 's/v//g')
+PACKAGE_VERSION=$($SRC_PATH/src/dragonxd --version|grep version|cut -d' ' -f4|cut -d- -f1|sed 's/v//g')
 DEBVERSION=$(echo $PACKAGE_VERSION | sed 's/-beta/~beta/' | sed 's/-rc/~rc/' | sed 's/-/+/')
 BUILD_DIR="$BUILD_PATH/$PACKAGE_NAME-$PACKAGE_VERSION-$ARCH"
 
@@ -61,6 +62,9 @@ DEB_BIN=$BUILD_DIR/usr/bin
 DEB_CMP=$BUILD_DIR/usr/share/bash-completion/completions
 DEB_DOC=$BUILD_DIR/usr/share/doc/$PACKAGE_NAME
 DEB_MAN=$BUILD_DIR/usr/share/man/man1
+# NOTE: /usr/share/hush is intentional and must NOT be renamed to /usr/share/dragonx.
+# The compiled binary hardcodes /usr/share/hush as the Debian global search path for the
+# sapling params and asmap.dat (see src/init.cpp and src/util.cpp).
 DEB_SHR=$BUILD_DIR/usr/share/hush
 mkdir -p $BUILD_DIR/DEBIAN $DEB_CMP $DEB_BIN $DEB_DOC $DEB_MAN $DEB_SHR
 chmod 0755 -R $BUILD_DIR/*
@@ -74,37 +78,36 @@ chmod 0755 -R $BUILD_DIR/*
 cp $SRC_PATH/contrib/asmap/asmap.dat $DEB_SHR
 cp $SRC_PATH/sapling-spend.params $DEB_SHR
 cp $SRC_PATH/sapling-output.params $DEB_SHR
-cp $SRC_PATH/src/hushd $DEB_BIN
+cp $SRC_PATH/src/dragonxd $DEB_BIN
-strip $DEB_BIN/hushd
+strip $DEB_BIN/dragonxd
-cp $SRC_PATH/src/hush-cli $DEB_BIN
+cp $SRC_PATH/src/dragonx-cli $DEB_BIN
-strip $DEB_BIN/hush-cli
+strip $DEB_BIN/dragonx-cli
-cp $SRC_PATH/src/hush-tx $DEB_BIN
+cp $SRC_PATH/src/dragonx-tx $DEB_BIN
-strip $DEB_BIN/hush-tx
+strip $DEB_BIN/dragonx-tx
 
-cp $SRC_PATH/src/hush-arrakis-chain $DEB_BIN
 cp $SRC_DEB/changelog $DEB_DOC
 cp $SRC_DEB/copyright $DEB_DOC
 cp -r $SRC_DEB/examples $DEB_DOC
 # Copy manpages
-cp $SRC_DOC/man/hushd.1 $DEB_MAN/hushd.1
+cp $SRC_DOC/man/dragonxd.1 $DEB_MAN/dragonxd.1
-cp $SRC_DOC/man/hush-cli.1 $DEB_MAN/hush-cli.1
+cp $SRC_DOC/man/dragonx-cli.1 $DEB_MAN/dragonx-cli.1
-cp $SRC_DOC/man/hush-tx.1 $DEB_MAN/hush-tx.1
+cp $SRC_DOC/man/dragonx-tx.1 $DEB_MAN/dragonx-tx.1
 
 # Copy bash completion files
-cp $SRC_PATH/contrib/hushd.bash-completion $DEB_CMP/hushd
+cp $SRC_PATH/contrib/dragonxd.bash-completion $DEB_CMP/dragonxd
-cp $SRC_PATH/contrib/hush-cli.bash-completion $DEB_CMP/hush-cli
+cp $SRC_PATH/contrib/dragonx-cli.bash-completion $DEB_CMP/dragonx-cli
-cp $SRC_PATH/contrib/hush-tx.bash-completion $DEB_CMP/hush-tx
+cp $SRC_PATH/contrib/dragonx-tx.bash-completion $DEB_CMP/dragonx-tx
 # Gzip files
 #gzip --best -n $DEB_DOC/changelog
 #gzip --best -n $DEB_DOC/changelog.Debian
-gzip --best -n $DEB_MAN/hushd.1
+gzip --best -n $DEB_MAN/dragonxd.1
-gzip --best -n $DEB_MAN/hush-cli.1
+gzip --best -n $DEB_MAN/dragonx-cli.1
-gzip --best -n $DEB_MAN/hush-tx.1
+gzip --best -n $DEB_MAN/dragonx-tx.1
 
 cd $SRC_PATH/contrib
 
 # Create the control file
-dpkg-shlibdeps $DEB_BIN/hushd $DEB_BIN/hush-cli $DEB_BIN/hush-tx
+dpkg-shlibdeps $DEB_BIN/dragonxd $DEB_BIN/dragonx-cli $DEB_BIN/dragonx-tx
 dpkg-gencontrol -P$BUILD_DIR -v$DEBVERSION
 #dpkg-gencontrol -P$BUILD_DIR
 

util/checkpoints.pl

@@ -7,7 +7,7 @@ use strict;
 
 # Generate checkpoint data for use in src/chainparams.cpp
 my $perday  = 1152;
-my $cli     = "./src/hush-cli";
+my $cli     = "./src/dragonx-cli";
 my $stride  = shift || 1000;
 if ($stride =~ m/help/) {
     print "To generate checkpoint data every 1000 blocks: $0 &> checkpoints.txt\n";
@@ -34,7 +34,7 @@ if ($acname) {
     # HSC's by default have a blocktime of 60s
     $perday = 1440;
 } else {
-    $acname = 'HUSH3';
+    $acname = 'DRAGONX';
 }
 
 my $gethash = "$cli getblockhash";
@@ -49,7 +49,7 @@ my $last    = 0;
 my $now     = time();
 chomp($blocks);
 
-print "// Generated at $now via hush3 util/checkpoints.pl by Duke Leto\n";
+print "// Generated at $now via dragonx util/checkpoints.pl\n";
 
 while (1) {
 	$count++;

util/docker-entrypoint.sh

@@ -4,17 +4,16 @@
 # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
 
 #set -ex
-echo "...Checking HUSH3.conf"
+echo "...Checking DRAGONX.conf"
 
-# TODO: support legacy location?
+if [ ! -e "$HOME/.hush/DRAGONX/DRAGONX.conf" ]; then
-if [ ! -e "$HOME/.hush/HUSH3/HUSH3.conf" ]; then
+    mkdir -p $HOME/.hush/DRAGONX
-    mkdir -p $HOME/.hush/HUSH3
 
     DATE=$(date)
-    echo "...Creating HUSH3.conf"
+    echo "...Creating DRAGONX.conf"
-    cat <<EOF > $HOME/.hush/HUSH3.conf
+    cat <<EOF > $HOME/.hush/DRAGONX/DRAGONX.conf
 # Generated by docker-entrypoint.sh at $DATE
-rpcuser=hush
+rpcuser=dragonx
 rpcpassword=${rpcpassword:-`dd if=/dev/urandom bs=33 count=1 2>/dev/null | base64`}
 txindex=1
 bind=${listenip:-127.0.0.1}
@@ -25,7 +24,7 @@ zdebug=0
 zindex=0
 EOF
 
-    cat $HOME/.hush/HUSH3/HUSH3.conf
+    cat $HOME/.hush/DRAGONX/DRAGONX.conf
 fi
 
 if [ $# -gt 0 ]; then
@@ -36,6 +35,6 @@ else
     args=("-pubkey=${pubkey} -ac_name=${assetchain} -addnode=${seednode}")
 fi
 
-echo "Running: hushd ${args[@]}"
+echo "Running: dragonxd ${args[@]}"
 
-exec hushd ${args[@]}
+exec dragonxd ${args[@]}

util/docker-hush-cli.sh

@@ -1,4 +1,4 @@
 #!/usr/bin/env bash
 # Copyright (c) 2019-2020 Hush developers
 
-/hush/src/hush-cli $@
+/hush/src/dragonx-cli $@

util/gen-manpages.sh

@@ -1,34 +1,35 @@
 #!/bin/sh
 # Copyright (c) 2016-2024 The Hush developers
+# Copyright (c) 2024-2026 The DragonX developers
 # Released under the GPLv3
 
 TOPDIR=${TOPDIR:-$(git rev-parse --show-toplevel)}
 SRCDIR=${SRCDIR:-$TOPDIR/src}
 MANDIR=${MANDIR:-$TOPDIR/doc/man}
 
-HUSHD=${HUSHD:-$SRCDIR/hushd}
+DRAGONXD=${DRAGONXD:-$SRCDIR/dragonxd}
-HUSHCLI=${HUSHCLI:-$SRCDIR/hush-cli}
+DRAGONXCLI=${DRAGONXCLI:-$SRCDIR/dragonx-cli}
-HUSHTX=${HUSHTX:-$SRCDIR/hush-tx}
+DRAGONXTX=${DRAGONXTX:-$SRCDIR/dragonx-tx}
 
-[ ! -x $HUSHD ] && echo "$HUSHD not found or not executable." && exit 1
+[ ! -x $DRAGONXD ] && echo "$DRAGONXD not found or not executable." && exit 1
 # Check if help2man is installed & if not then display error to user and exit
 [ ! -x "$(command -v help2man)" ] && echo "help2man could not be found" && echo "Please install from your Linux package manager and try again" && echo "On Debian-based systems you can do: apt-get install help2man" && exit 1
 
-# use this if hushd is not compiled
+# use this if dragonxd is not compiled
-#HUSHVER="v3.6.2"
+#DRAGONXVER="v1.0.3"
-HUSHVER=$(./src/hushd --version|head -n1|cut -d' ' -f4|cut -d- -f1)
+DRAGONXVER=$($DRAGONXD --version|head -n1|cut -d' ' -f4|cut -d- -f1)
 
 # Create a footer file with copyright content.
-# This gets autodetected fine for hushd if --version-string is not set,
+# This gets autodetected fine for dragonxd if --version-string is not set,
-# but has different outcomes for hush-cli.
+# but has different outcomes for dragonx-cli.
 echo "[COPYRIGHT]" > footer.h2m
-$HUSHD --version | sed -n '1!p' >> footer.h2m
+$DRAGONXD --version | sed -n '1!p' >> footer.h2m
 
-echo "Generating man pages for Hush $HUSHVER"
+echo "Generating man pages for DragonX $DRAGONXVER"
-for cmd in $HUSHD $HUSHCLI $HUSHTX; do
+for cmd in $DRAGONXD $DRAGONXCLI $DRAGONXTX; do
   cmdname="${cmd##*/}"
-  help2man -N --version-string=${HUSHVER} --include=footer.h2m -o ${MANDIR}/${cmdname}.1 ${cmd}
+  help2man -N --version-string=${DRAGONXVER} --include=footer.h2m -o ${MANDIR}/${cmdname}.1 ${cmd}
-  #sed -i "s/\\\-${HUSHVER[1]}//g" ${MANDIR}/${cmdname}.1
+  #sed -i "s/\\\-${DRAGONXVER[1]}//g" ${MANDIR}/${cmdname}.1
 done
 
 rm -f footer.h2m

util/gen_scriptpubs.pl

@@ -12,10 +12,10 @@ use JSON;
 # addresses must be one-per-line in the file
 
 my $file     = shift;
-my $N        = 20; # hushd is currently hardcoded to use 20 addresses
+my $N        = 20; # dragonxd is currently hardcoded to use 20 addresses
-my $hush     = "./src/hush-cli";
+my $cli      = "./src/dragonx-cli";
-my $getnew   = "$hush getnewaddress";
+my $getnew   = "$cli getnewaddress";
-my $validate = "$hush validateaddress";
+my $validate = "$cli validateaddress";
 my $fh;
 
 if($file) {

util/test_randomx

@@ -2,8 +2,8 @@
 
 # any CLI args given to this script will be passed along
 # example: ./test_randomx -debug=randomx
- ../src/hushd -ac_randomx_interval=10 -ac_randomx_lag=3 -ac_halving=20 -ac_algo=randomx -ac_name=RANDOMX10 -ac_private=1 -ac_blocktime=20 -ac_reward=500000000 -ac_supply=55555 -gen=1 -genproclimit=1 -testnode=1 $@
+ ../src/dragonxd -ac_randomx_interval=10 -ac_randomx_lag=3 -ac_halving=20 -ac_algo=randomx -ac_name=RANDOMX10 -ac_private=1 -ac_blocktime=20 -ac_reward=500000000 -ac_supply=55555 -gen=1 -genproclimit=1 -testnode=1 $@
 
 # to run via the debugger
 # type "run" when gdb prompt appears
-#gdb --args ./src/hushd -- -ac_algo=randomx -ac_name=RANDOMX -ac_private=1 -ac_blocktime=30 -ac_reward=500000000 -ac_supply=55555 -gen=1 -genproclimit=1 -testnode=1
+#gdb --args ./src/dragonxd -- -ac_algo=randomx -ac_name=RANDOMX -ac_private=1 -ac_blocktime=30 -ac_reward=500000000 -ac_supply=55555 -gen=1 -genproclimit=1 -testnode=1