DragonX/dragonx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Merge dev into dragonx: DragonX rebrand + security/consensus hardening + IBD speedups

Browse Source 
# Conflicts:
#	contrib/init/dragonxd.conf
#	contrib/init/dragonxd.init
#	contrib/init/dragonxd.openrc
#	contrib/init/dragonxd.openrcconf
#	contrib/init/dragonxd.service
This commit is contained in:
DanS
2026-07-21 18:58:33 -05:00
parent ddf6a35680 8976e020e9
commit d0657d38b4
147 changed files with 3805 additions and 311774 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
ISSUE_TEMPLATE.md
View File

@@ -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!

250
README.md
View File

@@ -1,112 +1,103 @@
<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 |
| :---: | :---: | :---: | :---: | :---: |
| [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)
| [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)
| [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)
| Introduction | Build | Run | Mine |
| :---: | :---: | :---: | :---: |
| [What is DragonX?](#what-is-dragonx) | [Build from source](#build-from-source) | [Run a node](#running-a-node) | [CPU mining](#cpu-mining-randomx) |
| [Key facts](#key-facts) | [Install a release](#installing-dragonx-binaries) | [Fastest sync](#fastest-way-to-sync-bootstrap) | [Wallets](#wallets) |
</h3>
# What is Hush?
# What is DragonX?
Hush implements Extreme Privacy via blockchain tech. We have our own
genesis block. We are not a chain fork (copy) of another coin. We are based on
Bitcoin code, with sophisticated zero-knowledge mathematics added for privacy.
This keeps your transaction metadata private!
DragonX implements extreme privacy via blockchain technology. It is **private from
genesis**: every ordinary transaction is shielded (`z2z`), so your transaction metadata
stays private. DragonX is based on Bitcoin code with Zcash's zero-knowledge Sapling
cryptography, and its defining feature is **RandomX Proof-of-Work — it is mined with a
CPU**, not ASICs or GPUs.
# 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
the entire history of Hush transactions; depending on the speed of your
computer and network connection, it will likely take a few hours at least, but
some people report full nodes syncing in less than 1.5 hours.
This software is the DragonX full node and command-line client. It downloads and stores the
entire history of DragonX transactions; depending on your computer and network connection
this can take a while, so most users start from the [bootstrap snapshot](#fastest-way-to-sync-bootstrap).
# Banned by GitHub
**DragonX is experimental software.** Use at your own risk, just like Bitcoin.
In working on this release, Duke Leto was suspended from Github, which gave Hush developers
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.
# Key facts
**Hush is unfinished and highly experimental.** Use at your own risk! Just like Bitcoin.
| | |
| --- | --- |
| 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` |
# Build on Debian or Ubuntu
# Fastest way to sync (bootstrap)
The quickest way to get a fully-synced node is the signed bootstrap snapshot, which
installs a pre-built blockchain so you skip re-validating the whole chain from genesis:
```sh
# Stop dragonxd first if it is running, then:
./util/bootstrap-dragonx.sh
```
The script preserves your `wallet.dat` and `DRAGONX.conf`, verifies the download's
checksums and (once a release key is published) its cryptographic signature, then starts
you near the chain tip. If you prefer to sync from the network instead, a larger
`-dbcache` (e.g. `-dbcache=2048`) noticeably speeds up the initial block download.
# Build from source
Building uses 3 build processes by default; you need ~2GB of RAM for each.
### Debian or Ubuntu
```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.hush.is/hush/hush3
cd hush3
# Build
# This uses 3 build processes, you need 2GB of RAM for each.
git clone https://git.dragonx.is/DragonX/dragonx
cd dragonx
./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.hush.is/hush/hush3
cd hush3
# Build
# This uses 3 build processes, you need 2GB of RAM for each.
git clone https://git.dragonx.is/DragonX/dragonx
cd dragonx
./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.hush.is/hush/hush3
cd hush3
# Build
# This uses 3 build processes, you need 2GB of RAM for each.
git clone https://git.dragonx.is/DragonX/dragonx
cd dragonx
./build.sh -j3
```
# Install on Windows 10
### macOS
Video Tutorial: https://videos.hush.is/videos/how-to-install-on-windows
# 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:
Install Xcode Command Line Tools and [Homebrew](https://brew.sh/), then:
```sh
xcode-select --install
@@ -116,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.hush.is/hush/hush3
cd hush3
# Build (uses 3 build processes, you need 2GB of RAM for each)
git clone https://git.dragonx.is/DragonX/dragonx
cd dragonx
# Make sure libtool gnubin and cargo are on PATH
export PATH="$HOME/.cargo/bin:/usr/local/opt/libtool/libexec/gnubin:$PATH"
./build.sh -j3
@@ -132,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.
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
```sh
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
git clone https://git.hush.is/hush/hush3
cd hush3
# Build
./util/build-win.sh -j$(nproc)
# Run a HUSH node
./src/hushd
./src/dragonxd
```
# 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:
* [explorer.hush.is](https://explorer.hush.is)
```sh
./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>
* [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.
# CPU mining (RandomX)
# 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
1. https://tradeogre.com/exchange/BTC-HUSH
# Wallets
# 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`:
- https://git.hush.is/hush/hush3/issues
- https://git.hush.is/hush/SilentDragon/issues
- https://git.hush.is/hush/SilentDragonLite/issues
DragonX light and mobile wallets use BIP39 seed phrases that are compatible with the full
node — see [doc/seed-phrase.md](doc/seed-phrase.md).
![Logo](doc/hush/earnhush.png "Hush Bounty")
# Support and links
# Support and Socials
* Telegram: [https://hush.is/tg](https://hush.is/tg)
* Matrix: [https://hush.is/matrix](https://hush.is/matrix)
* Twitter: [https://hush.is/twitter](https://hush.is/twitter)
* PeerTube [https://hush.is/peertube](https://hush.is/peertube)
* Website: https://dragonx.is
* Source code: https://git.dragonx.is/DragonX
* Block explorer: https://explorer.dragonx.is
* Issues / bounties: https://git.dragonx.is/DragonX/dragonx/issues
* Telegram: https://dragonx.is/tg
* Matrix: https://dragonx.is/matrix
* Twitter / X: https://twitter.com/DragonXchain
# License

2
build.sh
View File

@@ -6,7 +6,7 @@
set -eu -o pipefail
VERSION="1.0.2"
VERSION="1.0.3"
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
RELEASE_DIR="$SCRIPT_DIR/release"

2
configure.ac
View File

@@ -3,7 +3,7 @@ AC_PREREQ([2.60])
define(_CLIENT_VERSION_MAJOR, 1)
dnl Must be kept in sync with src/clientversion.h , ugh!
define(_CLIENT_VERSION_MINOR, 0)
define(_CLIENT_VERSION_REVISION, 2)
define(_CLIENT_VERSION_REVISION, 3)
define(_CLIENT_VERSION_BUILD, 50)
define(_ZC_BUILD_VAL, m4_if(m4_eval(_CLIENT_VERSION_BUILD < 25), 1, m4_incr(_CLIENT_VERSION_BUILD), m4_eval(_CLIENT_VERSION_BUILD < 50), 1, m4_eval(_CLIENT_VERSION_BUILD - 24), m4_eval(_CLIENT_VERSION_BUILD == 50), 1, , m4_eval(_CLIENT_VERSION_BUILD - 50)))
define(_CLIENT_VERSION_SUFFIX, m4_if(m4_eval(_CLIENT_VERSION_BUILD < 25), 1, _CLIENT_VERSION_REVISION-beta$1, m4_eval(_CLIENT_VERSION_BUILD < 50), 1, _CLIENT_VERSION_REVISION-rc$1, m4_eval(_CLIENT_VERSION_BUILD == 50), 1, _CLIENT_VERSION_REVISION, _CLIENT_VERSION_REVISION-$1)))

78
contrib/README.md
View File

@@ -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!
Please fix bugs and report things you find.
# Hush Tools
# DragonX 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) ###
Specific tools for developers working on this repository.
Contains the script `github-merge.sh` for merging github pull requests securely and signing them using GPG.
### [Verify-Commits](/contrib/verify-commits)
Tool to verify that merge commits were signed by a developer.
### [Verify-Commits](/contrib/verify-commits) ###
Tool to verify that every merge commit was signed by a developer using the above `github-merge.sh` script.
### [Linearize](/contrib/linearize) ###
### [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 pnSeed[] array that is compiled into the client.
### [Seeds](/contrib/seeds)
Utility to generate the seed node array that is compiled into the client.
## Build Tools and Keys
### [Debian](/contrib/debian) ###
Contains files used to package bitcoind/bitcoin-qt
for Debian-based Linux systems. If you compile bitcoind/bitcoin-qt yourself, there are some useful files here.
### [Debian](/contrib/debian)
Contains files used to package dragonxd for Debian-based Linux systems.
### [Gitian-descriptors](/contrib/gitian-descriptors) ###
Gavin's notes on getting gitian builds up and running using KVM.
### [Gitian-descriptors](/contrib/gitian-descriptors)
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) ###
Scripts and notes for Mac builds.
### [MacDeploy](/contrib/macdeploy)
Scripts and notes for Mac builds.
## Test and Verify Tools
## Test and Verify Tools
### [TestGen](/contrib/testgen) ###
Utilities to generate test vectors for the data-driven Bitcoin tests.
### [TestGen](/contrib/testgen)
Utilities to generate test vectors for the data-driven base58 tests.
### [Test Patches](/contrib/test-patches) ###
These patches are applied when the automated pull-tester
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.
### [Verify SF Binaries](/contrib/verifysfbinaries)
Legacy SourceForge-era signature verification script (unused for DragonX).

2
contrib/avg_blocktime.pl
View File

@@ -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";

16
contrib/block_time.pl
View File

@@ -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";
unless (-e $hush) {
die "$hush does not exist, aborting";
my $cli = "./src/dragonx-cli";
unless (-e $cli) {
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";

4
contrib/convert_address.py
View File

@@ -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

209
contrib/debian/examples/HUSH3.conf
View File

@@ -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

1
contrib/debian/hush.example
View File

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

3
contrib/debian/hush.install
View File

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

3
contrib/debian/hush.manpages
View File

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

36
contrib/hush-cli.bash-completion → contrib/dragonx-cli.bash-completion
View File

@@ -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
_hush_rpc() {
# call $dragonx-cli for 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=$(_hush_rpc listaccounts | awk -F '"' '{ print $2 }')
# Accounts are deprecated in dragonx
#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
# as hush-cli might not be in $PATH
hush_cli="$1"
# save and use original argument to invoke dragonx-cli for -help, help and RPC
# as dragonx-cli might not be in $PATH
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

18
contrib/hush-tx.bash-completion → contrib/dragonx-tx.bash-completion
View File

@@ -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

18
contrib/hush-uri.bat → contrib/dragonx-uri.bat
View File

@@ -8,8 +8,8 @@ Exit
:RegExport
Set RegFile="%Temp%\~etsaclu.tmp"
Set "hush=%~dp0"
set "hush=%hush:\=\\%"
Set "dragonx=%~dp0"
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 @="URL:hush protocol"
>> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx]
>> %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 @="%hush%silentdragon.exe \"%%1\""
>> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx\Shell\Open\Command]
>> %RegFile% Echo @="%dragonx%silentdragon.exe \"%%1\""
Start /Wait %systemroot%\Regedit.exe /S %RegFile%
Del %RegFile%

14
contrib/hushd.bash-completion → contrib/dragonxd.bash-completion
View File

@@ -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

14
contrib/fresh_clone_compile_and_run.sh
View File

@@ -11,19 +11,19 @@
BRANCH=$1
git clone https://git.hush.is/hush/hush3
cd hush3
git clone https://git.dragonx.is/DragonX/dragonx
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 &
# You can give the entire or parts of this file to Hush developers for debugging,
./src/dragonxd &> dragonx.log &
# 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

4
contrib/gen-zaddrs.pl
View File

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

10
contrib/gitian-descriptors/README.md
View File

@@ -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

17
contrib/hush_block_subsidy_per_halving
View File

@@ -1,17 +0,0 @@
#!/usr/bin/env perl
# Copyright 2016-2020 The Hush developers
# Released under the GPLv3
use strict;
use warnings;
my $x = 12.5 * 100000000;
my $n = 0;
while ($n<=31) {
#printf "$n,%.16g,%.16g,%.16g\n", $x, $x*0.90, $x*0.1;
printf "$n,%d,%d,%d\n", $x, $x*0.90, $x*0.1;
$x = $x / 2;
$n++;
exit if ($x <= 0);
}

22
contrib/hush_halvings
View File

@@ -1,22 +0,0 @@
#!/usr/bin/env perl
# Copyright (c) 2016-2024 The Hush developers
# Released under the GPLv3
use strict;
use warnings;
my $x = 340_000;
my $n = 0;
my $r = 12_500_000_000;
while ($n<=32) {
printf "%d,%d,%d\n", $n+1, $r, $x + 1680000*$n;
# blocktime halving at block 340000
if ($n==0) {
$r = 3.125 * 100_000_000;
} else {
$r /= 2;
}
$n++;
}

34
contrib/hush_seed_nodes.txt
View File

@@ -1,27 +1,17 @@
# This is a list of nodes which hushd attempts to connect to automatically
# This is a list of nodes which dragonxd attempts to connect to automatically
# at start up time. You can check to see if they are up/down with:
# cd contrib; cat hush_seed_nodes.txt | ./hush_scanner
# IP/tor/i2p seeds from src/chainparamsseeds.h
185.241.61.43
87.251.76.166
45.82.68.233
87.251.76.33
137.74.4.198
149.28.102.219
155.138.228.68
107.174.70.251
# hush_scanner uses nc which cannot deal with these
# iljqq7nnmw2ij2ezl334cerwwmgzmmbmoc3n4saditd2xhi3xohq.b32.i2p
# [2a0c:b641:6f1:34::2]
# [2a0c:b641:6f1:c::2]
# IP seeds from src/chainparamsseeds.h
212.56.41.63
194.140.198.176
212.56.41.47
144.126.147.165
176.126.87.241
# Hostname Seeds from src/hush_utils.h
node1.hush.is
node2.hush.is
node3.hush.is
node4.hush.is
node5.hush.is
node6.hush.is
node7.hush.is
node8.hush.is
node1.dragonx.is
node2.dragonx.is
node3.dragonx.is
node4.dragonx.is
node5.dragonx.is

218
contrib/hush_supply
View File

@@ -1,218 +0,0 @@
#!/usr/bin/env perl
# Copyright (c) 2016-2024 The Hush developers
# Released under the GPLv3
use warnings;
use strict;
my $supply = 0.0;
my $block = 0; # Block 0 in Hush Smart chains is the BTC genesis block
my $puposhis = 100_000_000;
my $subsidy0 = 1_250_000_000;
my $halvings = 0;
my $initial = 6178674 * $puposhis;
my $interval = 1_680_000; # ~4 years of 75s blocks
my $stop = shift || -1;
my $totalfr = 0; # total paid out to FR address
if ($stop eq 'help' or $stop =~ m/-h/) {
die <<HELP;
# Simulate the total supply on Hush v3 mainnet
# Block Reward: Total Coinbase In Block
# Subsidy : Coinbase Earned by Miner
# FR : Founders Reward (10%)
# Block Reward = Subsidy + FR
Usage: ./hush_supply &> supply.csv
./hush_supply HEIGHT &> supply.csv # stop at HEIGHT
# This will generate CSV in the form of:
# block, supply, reward, subsidy, fr, totalfr, halvings
HELP
}
printf "# block, supply, reward, subsidy, fr, totalfr, halvings\n";
# Block Reward Amounts in puposhis
# The non-integral amounts cannot be represented exactly
# 12.5 * 100000000 = 1250000000
# 12.5 * 100000000 / 2 = 625000000
# 12.5 * 100000000 / 4 = 312500000
# 12.5 * 100000000 / 8 = 156250000
# 12.5 * 100000000 / 16 = 78125000
# 12.5 * 100000000 / 32 = 39062500
# 12.5 * 100000000 / 64 = 19531250
# 12.5 * 100000000 / 128 = 9765625
# 12.5 * 100000000 / 256 = 4882812.5
# 12.5 * 100000000 / 512 = 2441406.25
# 12.5 * 100000000 / 1024 = 1220703.125
# 12.5 * 100000000 / 2048 = 610351.5625
# 12.5 * 100000000 / 4096 = 305175.78125
# 12.5 * 100000000 / 8192 = 152587.890625
# 12.5 * 100000000 / 16384 = 76293.9453125
# 12.5 * 100000000 / 32768 = 38146.97265625
# 12.5 * 100000000 / 65536 = 19073.486328125
# Hush Halving Heights and Block Rewards
# 1,12500000000,340000
# 2,312500000,2020000
# 3,156250000,3700000
# 4,78125000,5380000
# 5,39062500,7060000
# 6,19531250,8740000
# 7,9765625,10420000
# 8,4882812,12100000
# 9,2441406,13780000
# 10,1220703,15460000
# 11,610351,17140000
# 12,305175,18820000
# 13,152587,20500000
# 14,76293,22180000
# 15,38146,23860000
# 16,19073,25540000
# 17,9536,27220000
# 18,4768,28900000
# 19,2384,30580000
# 20,1192,32260000
# 21,596,33940000
# 22,298,35620000
# 23,149,37300000
# 24,74,38980000
# 25,37,40660000
# 26,18,42340000
# 27,9,44020000
# 28,4,45700000
# 29,2,47380000
# 30,1,49060000
# 31,0,50740000
sub hush_block_reward
{
my $reward = 0;
my $height = shift;
my $halvings = 0;
if ($height >= 50740000) {
$reward = 0;
$halvings = 31;
} elsif ($height >= 49060000) {
$reward = 1;
$halvings = 30;
} elsif ($height >= 47380000) {
$reward = 1;
$halvings = 29;
} elsif ($height >= 45700000) {
$reward = 2;
$halvings = 28;
} elsif ($height >= 44020000) {
$reward = 4;
$halvings = 27;
} elsif ($height >= 42340000) {
$reward = 9;
$halvings = 26;
} elsif ($height >= 40660000) {
$reward = 18;
$halvings = 25;
} elsif ($height >= 38980000) {
$reward = 37;
$halvings = 24;
} elsif ($height >= 37380000) {
$reward = 74;
$halvings = 23;
} elsif ($height >= 35620000) {
$reward = 149;
$halvings = 22;
} elsif ($height >= 33940000) {
$reward = 298;
$halvings = 21;
} elsif ($height >= 32260001) {
$reward = 596;
$halvings = 20;
} elsif ($height >= 30580000) {
$reward = 1192;
$halvings = 19;
} elsif ($height >= 28900000) {
$reward = 2384;
$halvings = 18;
} elsif ($height >= 27220000) {
$reward = 4768;
$halvings = 17;
} elsif ($height >= 25540000) {
$reward = 9536;
$halvings = 16;
} elsif ($height >= 23860000) {
$reward = 19073; # 0.486328125 deviation
$halvings = 15;
} elsif ($height >= 22180000) {
$reward = 38146; # 0.97265625 deviation
$halvings = 14;
} elsif ($height >= 20500000) {
$reward = 76293; # 0.9453125 deviation
$halvings = 13;
} elsif ($height >= 18820000) {
$reward = 152587; # 0.890625 deviation
$halvings = 12;
} elsif ($height >= 17140000) {
$reward = 305175; # 0.78125sat deviation
$halvings = 11;
} elsif ($height >= 15460000) {
$reward = 610351; # 0.5625sat deviation
$halvings = 10;
} elsif ($height >= 13780000) {
$reward = 1220703; # 0.125sat deviation
$halvings = 9
} elsif ($height >= 12100000) {
$reward = 2441406; # 0.25sat deviation
$halvings = 8
} elsif ($height >= 10420000) {
$reward = 4882812; # 0.5sat deviation
$halvings = 7;
} elsif ($height >= 8740000) {
$reward = 9765625; # last exact reward
$halvings = 6;
} elsif ($height >= 7060000) {
$reward = 19531250; # 0.1953125 HUSH
$halvings = 5;
} elsif ($height >= 5380000) {
$reward = 39062500; # 0.390625 HUSH
$halvings = 4;
} elsif ($height >= 3700000) {
$reward = 78125000; # 0.78125 HUSH
$halvings = 3;
} elsif ($height >= 2020000) {
$reward = 156250000; # 1.5625 HUSH
$halvings = 2;
} elsif ($height >= 340000) {
$reward = 312500000; # 3.125 HUSH
$halvings = 1;
} elsif ($height >= 128) {
$reward = 1250000000; # 12.5 HUSH
}
return ($reward,$halvings);
}
# Block reward is 0 at the 31st halving
while ($halvings <= 30) {
$block++;
my ($reward,$halvings) = hush_block_reward($block);
my $fr = int($reward / 10);
my $subsidy = $reward - $fr;
if($block == 1) {
# initial airdrop of funds from HUSH v2 network @ Block 500000
$reward = $initial;
$subsidy= $reward;
$fr = 0;
}
$supply += $reward;
$totalfr += $fr;
# all values in puposhis
# block, current supply, block reward amount, fr, totalfr, number of halvings
printf "%d,%d,%d,%d,%d,%d,%d\n", $block, $supply, $reward, $subsidy, $fr, $totalfr, $halvings;
exit(0) if $block == $stop;
exit(0) if ($block > 128 && $reward == 0);
exit(-1) if ($supply >= 21_000_000*$puposhis);
}

33
contrib/hush_supply_old
View File

@@ -1,33 +0,0 @@
#!/usr/bin/env perl
# Copyright 2016-2020 The Hush developers
# Released under the GPLv3
use warnings;
use strict;
my $supply = 0.0;
my $block = 0;
my $satoshis = 100_000_000;
my $amount = int(12.5*$satoshis);
my $halvings = 0;
# Usage: ./hush_supply &> supply.csv
# Use this to calculate when supply hits a certain value
#while ($supply <= 21_000_000*$satoshis) {
# Use this to calculate when block rewards end
while ($halvings <= 64 && $amount >= 1) {
$block++;
if ($block < 5) {
$amount = 40_000 * $satoshis;
} else {
# Halving every 840000 blocks
if ($block % 840_000 == 0) {
$amount /= 2;
$halvings++;
}
$amount = int(12.5*$satoshis) / (2**$halvings);
}
$supply += $amount;
# block, current supply, block reward amount, number of halvings
printf "%s,%s,%s,%s\n", $block,$supply / $satoshis, $amount / $satoshis, $halvings;
}

10
contrib/init/README.md
View File

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

4
contrib/init/dragonxd.conf
View File

@@ -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

2
contrib/init/dragonxd.init
View File

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

6
contrib/init/dragonxd.openrc
View File

@@ -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"
description="Hush cryptocurrency P2P network daemon"
name="DragonX Full Node Daemon"
description="DragonX cryptocurrency P2P network daemon"
command="/usr/bin/dragonxd"
command_args="-pid=\"${HUSHD_PIDFILE}\" \

2
contrib/init/dragonxd.openrcconf
View File

@@ -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"

6
contrib/init/dragonxd.service
View File

@@ -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

59
contrib/init/hushd.conf
View File

@@ -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

67
contrib/init/hushd.init
View File

@@ -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

87
contrib/init/hushd.openrc
View File

@@ -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
}

33
contrib/init/hushd.openrcconf
View File

@@ -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

22
contrib/init/hushd.service
View File

@@ -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

7
contrib/macdeploy/README.md
View File

@@ -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`.

8
contrib/notary_seeds.txt
View File

@@ -1,8 +0,0 @@
103.6.12.117
95.213.238.99
77.75.121.139
139.162.45.144
152.89.105.66
152.89.104.58
5.53.120.34
139.99.208.141

4
contrib/qos/README.md
View File

@@ -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.

17
contrib/sda_checkpoints.pl
View File

@@ -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
# https://git.hush.is/fekt/hush-android-wallet-sdk/src/branch/main/sdk-lib/src/main/assets/co.electriccoin.zcash/checkpoint/mainnet
# This script is used to generate the checkpoint data used by the SilentDragonX Android SDK
# 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 $getblock= "$hush getblock";
my $gethash = "$hush getblockhash";
my $gettree = "$hush getblockmerkletree";
my $cli = "./src/dragonx-cli";
my $getblock= "$cli getblock";
my $gethash = "$cli getblockhash";
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;
}

13
contrib/sdl_checkpoints.pl
View File

@@ -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 $gethash = "$hush getblockhash";
my $gettree = "$hush getblockmerkletree";
my $cli = $ENV{CLI} || "./src/dragonx-cli";
my $gethash = "$cli getblockhash";
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;
}

6
contrib/seeds/README.md
View File

@@ -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.

6
contrib/seeds/generate-seeds.py
View File

@@ -167,9 +167,9 @@ def main():
g.write('// Instead, update contrib/seeds/nodes_main.txt then run\n')
g.write('// ./contrib/seeds/generate-seeds.py contrib/seeds > src/chainparamsseeds.h\n')
g.write('// OR run: make seeds\n')
g.write('#ifndef HUSH_CHAINPARAMSSEEDS_H\n')
g.write('#define HUSH_CHAINPARAMSSEEDS_H\n')
g.write('// List of fixed seed nodes for the Hush network\n')
g.write('#ifndef DRAGONX_CHAINPARAMSSEEDS_H\n')
g.write('#define DRAGONX_CHAINPARAMSSEEDS_H\n')
g.write('// List of fixed seed nodes for the DragonX network\n')
g.write('// Each line contains a BIP155 serialized address.\n')
g.write('//\n')
with open(os.path.join(indir,'nodes_main.txt'), 'r', encoding="utf8") as f:

44
contrib/seeds/nodes_main.txt
View File

@@ -1,38 +1,14 @@
# node1.hush.is
103.69.128.148
# node1.dragonx.is
212.56.41.63
# node2.hush.is
194.29.100.179
# node2.dragonx.is
194.140.198.176
# node3.hush.is
45.132.75.69
# node3.dragonx.is
212.56.41.47
# node4.hush.is
170.205.39.39
# node4.dragonx.is
144.126.147.165
# lite.hushpool.is
149.28.102.219
# lite2.hushpool.is
155.138.228.68
# wtfistheinternet.hush.is
107.174.70.251
# arrakis.hush.is
178.250.189.141
# torv3
b2dln7mw7ydnuopls444tuixujhcw5kn5o22cna6gqfmw2fl6drb5nad.onion
dslbaa5gut5kapqtd44pbg65tpl5ydsamfy62hjbldhfsvk64qs57pyd.onion
vsqdumnh5khjbrzlxoeucbkiuaictdzyc3ezjpxpp2ph3gfwo2ptjmyd.onion
# ipv6
2a0c:b641:6f1:18e::2
2406:ef80:3:1269::1
2406:ef80:2:3b59::1
2406:ef80:1:146e::1
2406:ef80:4:2132::1
# i2p
7oumuppuzgbzlkahavx7qrtjnvbhkixjqdmeg7f6fhndgfhz7mlq.b32.i2p
# node5.dragonx.is
176.126.87.241

28147
contrib/snapshot/airdrop_hush3.sh
View File

File diff suppressed because it is too large Load Diff

3127
contrib/snapshot/airdrop_txids.txt
View File

File diff suppressed because it is too large Load Diff

125089
contrib/snapshot/snapshot_499958.json
View File

File diff suppressed because it is too large Load Diff

125097
contrib/snapshot/snapshot_500000.json
View File

File diff suppressed because it is too large Load Diff

28147
contrib/snapshot/testnet_airdrop_hush3.sh
View File

File diff suppressed because it is too large Load Diff

2
contrib/testgen/README.md
View File

@@ -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:

13
contrib/verifysfbinaries/README.md
View File

@@ -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.

8
depends/packages/boost.mk
View File

@@ -1,12 +1,10 @@
package=boost
$(package)_version=1_72_0
#$(package)_download_path=https://boostorg.jfrog.io/artifactory/main/release/$(subst _,.,$($(package)_version))/source/
#$(package)_file_name=$(package)_$($(package)_version).tar.bz2
$(package)_download_path=https://archives.boost.io/release/$(subst _,.,$($(package)_version))/source
$(package)_file_name=$(package)_$($(package)_version).tar.bz2
$(package)_download_file=$(package)_$($(package)_version).tar.bz2
$(package)_sha256_hash=59c9b274bc451cf91a9ba1dd2c7fdcaf5d60b1b3aa83f2c9fa143417cc660722
$(package)_download_path=https://git.hush.is/attachments
$(package)_file_name=7b13759e-8623-4e48-ae08-f78502f4b6a5
$(package)_download_file=7b13759e-8623-4e48-ae08-f78502f4b6a5
$(package)_patches=fix-Solaris.patch ignore_wnonnull_gcc_11.patch range_enums_clang_16.patch
define $(package)_set_vars

12
depends/packages/libsodium.mk
View File

@@ -1,8 +1,8 @@
package=libsodium
$(package)_version=1.0.18
$(package)_download_path=https://git.hush.is/attachments
$(package)_file_name=0d9f589e-a9f9-4ddb-acaa-0f1b423b32eb
$(package)_download_file=0d9f589e-a9f9-4ddb-acaa-0f1b423b32eb
$(package)_download_path=https://github.com/jedisct1/libsodium/releases/download/1.0.18-RELEASE
$(package)_file_name=libsodium-1.0.18.tar.gz
$(package)_download_file=libsodium-1.0.18.tar.gz
$(package)_sha256_hash=6f504490b342a4f8a4c4a02fc9b866cbef8622d5df4e5452b46be121e46636c1
$(package)_dependencies=
$(package)_config_opts=
@@ -16,8 +16,12 @@ define $(package)_set_vars
endef
endif
# libsodium's autogen.sh otherwise fetches config.sub/config.guess from
# git.savannah.gnu.org gitweb, which is frequently down (502) and writes the error
# page over config.sub, breaking configure. autoreconf -ivf (run first) already
# installs valid copies, so tell autogen.sh to skip the download.
define $(package)_preprocess_cmds
cd $($(package)_build_subdir); ./autogen.sh
cd $($(package)_build_subdir); DO_NOT_UPDATE_CONFIG_SCRIPTS=1 ./autogen.sh
endef
define $(package)_config_cmds

6
depends/packages/utfcpp.mk
View File

@@ -1,7 +1,7 @@
$(package)_version=3.1
$(package)_download_path=https://git.hush.is/attachments
$(package)_file_name=11822fe4-3846-4ce4-9c84-ba0877a7b186
$(package)_download_file=11822fe4-3846-4ce4-9c84-ba0877a7b186
$(package)_download_path=https://github.com/nemtrif/utfcpp/archive/refs/tags
$(package)_file_name=utfcpp-3.1.tar.gz
$(package)_download_file=v3.1.tar.gz
$(package)_sha256_hash=ab531c3fd5d275150430bfaca01d7d15e017a188183be932322f2f651506b096
define $(package)_stage_cmds

21
doc/CONTRIBUTING.md
View File

@@ -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
We have a curated list of projects with details about difficulty level and languages involved: https://git.hush.is/hush/projects
* Perform a secure code review of DragonX Full Node and other DragonX-related software
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

21
doc/DEVELOPING.md
View File

@@ -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
https://git.hush.is/hush/hush3/commit/d39503c13b7419620d138050899705ced557eef9
which added the `-ac_burn` consensus changing option.
An example of this pattern in the Git history is the commit which added the
`-ac_burn` consensus changing option; search the log for `ac_burn` to find it.
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

71
doc/OLD_WALLETS.md
View File

@@ -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.

7
doc/beefy-HUSH3.conf
View File

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

32
doc/cjdns.md
View File

@@ -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
CJDNS peers than Tor or IP ones. You can use `hush-cli -addrinfo` to see the
number of CJDNS addresses known to your node.
There may be fewer CJDNS peers than Tor or IP ones. You can use
`dragonx-cli -addrinfo` to see the 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
details.
[doc/tor.md](tor.md) for 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.

26
doc/config.md
View File

@@ -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
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.
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 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

77
doc/developer-notes.md
View File

@@ -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
cd hush3
git clone https://git.dragonx.is/DragonX/dragonx
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
rm blocks chainstate database notarizations hushstate
cd ~/.hush/DRAGONX
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
rm zindex.dat blocks chainstate database notarizations hushstate
cd ~/.hush/DRAGONX
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`
is just a shell script that calls `src/hushd` and you always want to give an actual executable
file as the first argument to `gdb`, not a bash script.
NOTE: `src/blahd` is just a shell script that calls `src/dragonxd`; you always want to
give an actual executable 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
cd hush3-testing
git clone https://git.dragonx.is/DragonX/dragonx dragonx-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}
mkdir ~/.hush/HUSH3
mv ~/.hush/{DRAGONX,DRAGONX-backup-$TIME}
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`
CLI param for HSC's.
the codebase. Adding a new PoW algo means adding a new option to the `-ac_algo`
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.

19
doc/dnsseed-policy.md
View File

@@ -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
creating an issue in the [Hush Git repository](https://git.hush.is./hush/hush3).
providing services and contact the active DragonX development team as well as
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.

23
doc/dragonx/logo_dragonx.svg Normal file
View File

@@ -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>
Side by Side

After

Width:  |  Height:  |  Size: 1.9 KiB

BIN
doc/dragonx/logo_dragonx_128.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.9 KiB

10
doc/files.md
View File

@@ -1,17 +1,17 @@
# Hush Files
# DragonX Files
* HUSH3.conf: contains configuration settings for hushd
* hushd.pid: stores the process id of hushd while running
* DRAGONX.conf: contains configuration settings for dragonxd
* 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

87
doc/hd-transparent-keys.md Normal file
View File

@@ -0,0 +1,87 @@
# HD transparent keys
DragonX derives **transparent** (t-address) keys deterministically from the
wallet's HD seed, so they can be recovered from the seed alone — the same way
Sapling (shielded) keys already are.
## Derivation
Transparent keys are derived over secp256k1 using BIP32/BIP44:
```
m / 44' / coin_type' / 0' / 0 / i
```
* `coin_type` is `Params().BIP44CoinType()` — **141** on mainnet, **1** on
test/regtest.
* Account is fixed at `0'` and the chain at `0` (external). The internal/change
chain (`1`) is **not** used: on this `ac_private=1` chain a non-coinbase
transparent output is consensus-invalid, so transparent change can never carry
value.
* `i` is `CHDChain.transparentChildCounter`, a monotonic index persisted in the
wallet so the same addresses regenerate after a seed-only restore.
Each derived key records its `hdKeypath` and the seed fingerprint (`seedFp`) in
its `CKeyMetadata`, matching the Sapling scheme.
## Why this matters on a private chain
On DragonX (`ac_private=1` from genesis) a normal user can never *receive* to a
transparent address — inbound t-payments are rejected by consensus. The only
thing that legitimately lands spendable value on a t-address is a **mining
coinbase** (plus notary/burn special cases). There is no "coinbase must be
shielded" rule, so mature coinbase is directly spendable.
So HD transparent keys exist to let a **miner recover coinbase rewards** that
were paid to wallet-derived t-addresses, using only the seed.
## Enabling / disabling
Controlled by `-hdtransparent` (default **on**). When on and the wallet has an
HD seed, every newly generated transparent key (receive address, change,
coinbase payout drawn from the keypool) is HD-derived.
```
-hdtransparent=0 # keep the legacy behaviour (random transparent keys)
```
## Backing up and restoring
* **Back up the seed.** `z_exportwallet <file>` writes the 32-byte HD seed as a
`# HDSeed=<hex>` line. Guard this value like a private key.
* **Restore into a fresh/empty wallet** by starting the node with:
```
-hdseed=<64-hex-character seed>
-hdtransparentgaplimit=<n> # HD transparent keys to pre-derive (default 1000)
```
On restore the node injects the seed, pre-derives `n` transparent keys with a
genesis birthday, and the normal startup rescan finds any coinbase paid to
them. Raise `-hdtransparentgaplimit` if the wallet minted more than `n`
distinct coinbase addresses.
> **Warning:** passing `-hdseed` on the command line exposes the seed to your
> shell history and the process list. Prefer putting it in `DRAGONX.conf` with
> tight file permissions, and remove it after the restore completes.
## Limitations (read before relying on recovery)
* **Legacy random keys are not recoverable.** Any transparent key created before
this feature (or with `-hdtransparent=0`) came from the CSPRNG, not the seed,
and the phrase/seed will **not** regenerate it. Keep `wallet.dat` /
`dumpwallet` backups for those. A wallet that predates the feature and then
enables it becomes a *mix* of random (old) and HD (new) keys.
* **Gap limit.** A rescan only discovers keys already present in the wallet.
Restore pre-derives `-hdtransparentgaplimit` keys; coinbase paid to an index
beyond that window is not found until you derive further and rescan again.
* **Scope.** Recovers transparent **coinbase** value only, per the consensus
rules above. Shielded funds are recovered separately via the Sapling HD keys.
## On-disk compatibility
The transparent counter is stored in `CHDChain` under a new serialization
version (`VERSION_HD_TRANSPARENT = 2`). Existing v1 `wallet.dat` records load
unchanged (the counter defaults to 0); the record is rewritten as v2 the first
time an HD transparent key is derived. Downgrading a v2 wallet to an older
binary is not supported.

32
doc/help.md
View File

@@ -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
legacy wallet it could be at `~/.komodo/HUSH3/wallet.dat` . We will assume the first location.
If you are on Linux, your wallet lives at `~/.hush/DRAGONX/wallet.dat`.
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
mkdir HUSH3 # make a new dir
cp HUSH3-backup/wallet.dat HUSH3/wallet.dat # copy old wallet to new dir
mv DRAGONX DRAGONX-backup # backup all data
mkdir DRAGONX # make a 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
and it should perform a fresh sync with your wallet. This will likely take at least
a few hours or much longer depending on your internet connection.
At this point restart your node (`dragonxd`) and it will perform a fresh sync using your
wallet. This will likely take at least a few hours or much longer depending on your
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`
* Create a new directory called `C:\Users\Admin\AppData\Roaming\Hush\HUSH3`
* Copy the file `C:\Users\Admin\AppData\Roaming\Hush\HUSH3-backup\wallet.dat` to `C:\Users\Admin\AppData\Roaming\Hush\HUSH3`
* Now start the SilentDragon GUI wallet
* 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\DRAGONX`
* Copy the file `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX-backup\wallet.dat` to `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX`
* Now start your DragonX node again

24
doc/hsc.md
View File

@@ -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

35
doc/hushd-systemd.md
View File

@@ -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

9
doc/hushd.service
View File

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

34
doc/i2p.md
View File

@@ -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
peers than Tor or IP ones. Therefore, using I2P alone without other networks may
There may be fewer I2P peers than Tor or IP ones. Therefore, using I2P alone
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.

81
doc/init.md
View File

@@ -1,62 +1,64 @@
*** Warning: This document has not been updated for Hush and may be inaccurate. ***
Sample init scripts and service configuration for bitcoind
Sample init scripts and service configuration for dragonxd
==========================================================
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/bitcoind.openrc: OpenRC compatible SysV style init script
contrib/init/bitcoind.openrcconf: OpenRC conf.d file
contrib/init/bitcoind.conf: Upstart service configuration file
contrib/init/bitcoind.init: CentOS compatible SysV style init script
contrib/init/dragonxd.service: systemd service unit configuration
contrib/init/dragonxd.openrc: OpenRC compatible SysV style init script
contrib/init/dragonxd.openrcconf: OpenRC conf.d file
contrib/init/dragonxd.conf: Upstart service configuration file
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
and group. They must be created before attempting to use these scripts.
All startup configurations assume the existence of a "hush" user
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
when running as a daemon. If the configuration file does not exist or this
setting is not set, bitcoind will shutdown promptly after startup.
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
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
print a randomly generated suitable password to stderr. You can also
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
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
Configuration file: /etc/bitcoin/bitcoin.conf
Data directory: /var/lib/bitcoind
PID file: /var/run/bitcoind/bitcoind.pid (OpenRC and Upstart)
/var/lib/bitcoind/bitcoind.pid (systemd)
Lock file: /var/lock/subsys/bitcoind (CentOS)
Binary: /usr/bin/dragonxd
Configuration file: /etc/dragonx/DRAGONX.conf
Data directory: /var/lib/dragonxd
PID file: /var/run/dragonxd/dragonxd.pid (OpenRC and Upstart)
/var/lib/dragonxd/dragonxd.pid (systemd)
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
"systemctl enable bitcoind"
To test, run "systemctl start dragonxd" and to enable for system startup run
"systemctl enable dragonxd"
4b) OpenRC
Rename bitcoind.openrc to bitcoind and drop it in /etc/init.d. Double
check ownership and permissions and make it executable. Test it with
"/etc/init.d/bitcoind start" and configure it to run on startup with
"rc-update add bitcoind"
Rename dragonxd.openrc to dragonxd and drop it in /etc/init.d. Double
check ownership and permissions and make it executable. Test it with
"/etc/init.d/dragonxd start" and configure it to run on startup with
"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
setting the BITCOIND and FLAGS environment variables in the file
/etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here.
Using this script, you can adjust the path and flags to the dragonxd program by
setting the HUSHD_BIN and HUSHD_OPTS environment variables in the file
/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>

40
doc/overview.md
View File

@@ -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 .
Many ciphersuites are technically supported by TLS1.3 but many of them
are ancient, proved to be less secure than intended or likely backdoored.
Hush only uses what are widely considered to be the most secure and [best ciphersuites](https://ciphersuite.info/cs/).
TLS1.3 via WolfSSL is enforced for all network connections. Many ciphersuites are
technically supported by TLS1.3 but many of them are ancient, proved to be less secure
than intended or likely backdoored. DragonX only uses what are widely considered to be the
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),
which means you can only send to a shielded address, never to a transparent
address. This is enforced via consensus rules and sometimes called "z2z".
DragonX is a fully private blockchain from genesis. The consensus parameter
`ac_private=1` is active from block 1 and Sapling is active at height 1, so every
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).

34
doc/payment-api.md
View File

@@ -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_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_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_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>{ [“zs1…”, “zs1...”, “zs1...”] }
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_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_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 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

113
doc/randomx.md
View File

@@ -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 .
This means you can now launch a privacy coin with Hush tech that can be mined with a CPU
instead of requiring an ASIC or GPU. RandomX is the same algorithm that Monero (XMR) and
various other cryptocoins use. As far as we know, Hush Arrakis Chains are the first coins
based on Zcash Protocol that can use the RandomX PoW algorithm. Many thanks to all the
people who helped make this possible.
DragonX uses **RandomX** as its Proof-of-Work algorithm. RandomX is CPU-friendly
and ASIC/GPU-resistant, which keeps mining accessible to ordinary hardware.
RandomX is the same family of algorithm that Monero (XMR) and various other
coins use, though DragonX uses its own configuration (see "RandomX Internals"
below), so DragonX RandomX is not compatible with Monero mining hardware.
# 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.
HSC CLI arguments that start with `-ac_` means they *Affect Consensus*.
## DragonX consensus parameters
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
* It lives in the `./src` directory, next to `hushd` and `hush-cli`
* 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
```
You do not need to choose an algorithm, block time, reward, or supply — these
are baked into DragonX consensus.
# 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
* The default is 1024 blocks and is good for most use cases.
* This corresponds to ~17 hours for HSCs with the default block time of 60s
* `ac_randomx_lag` sets the number of blocks to wait before updating the key block
* The default is 64 blocks
* This corresponds to 64 mins for HSCs with the default block time of 60s
* `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
* It is not recommended to change these values unless you are really sure why you are doing it
* `-ac_randomx_interval` controls how often the RandomX key block changes
* Default is 1024 blocks
* 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
* Default is 64 blocks
* At DragonX's 36s block time this is roughly ~38 minutes
* `-ac_randomx_interval` should always be larger than 2 times `-ac_randomx_lag`
* Setting these to arbitrary values could affect chain security
* 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.
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` .
We use the official RandomX implementation from https://github.com/tevador/RandomX
with custom configuration options. Because the configuration differs from the
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.

71
doc/release-process.md
View File

@@ -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
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
# this assumes you are working with https://git.dragonx.is/DragonX/dragonx as your remote
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
- Comment out the HUSHVER line and uncomment the line above it with a hardcoded version number
- 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 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
- Look for line which says "END HUSH mainnet checkpoint data" near line 560 in chainparams.cpp , that is where checkpoint data ends
- dragonxd must be running to run this script, since it uses dragonx-cli to get the data
- 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 sure git tag starts with a `v` such as `v3.9.2`
- 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 `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

42
doc/security-warnings.md
View File

@@ -1,24 +1,17 @@
#Security Warnings
# Security Warnings
## Security Audits
Hush has not been subjected to a formal third-party security review! But the
some of the Zcash and Komodo source code it is based on has.
Hush does our best to integrate fixes and recommendations from upstream audits
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>
DragonX has not been subjected to a formal third-party security review. Some of
the Bitcoin, Zcash, Komodo, and Hush source code it is derived from has been
audited upstream, and DragonX integrates relevant fixes and recommendations from
those audits where they apply.
## 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

90
doc/seed-phrase.md Normal file
View File

@@ -0,0 +1,90 @@
# BIP39 seed phrases (SilentDragonXLite-compatible)
DragonX full-node wallets can be created from and restored to a **BIP39 24-word
seed phrase** that is **byte-for-byte compatible with SilentDragonXLite**: the
same words produce the same transparent (t-) and shielded (z-) addresses in
either wallet, so funds move between the light wallet and the full node with one
backup.
## What makes them compatible
Compatibility requires the mnemonic, the seed derivation, and every HD path to
match exactly. They do:
| Detail | Value (both wallets) |
|---|---|
| Word list | BIP39 English, 2048 words |
| Passphrase | empty (no "25th word") |
| Mnemonic → seed | PBKDF2-HMAC-SHA512, 2048 rounds, salt `"mnemonic"`, 64-byte output |
| Coin type | 141 (KMD SLIP-0044) |
| Shielded path | `m/32'/141'/i'` (ZIP-32) |
| Transparent path | `m/44'/141'/0'/0/i` (BIP44) |
The node stores the 32-byte BIP39 **entropy** (SilentDragonXLite's on-disk
convention) and expands it to the 64-byte seed on demand for derivation. The
node's vendored BIP39 library (`src/crypto/bip39`) is byte-identical to
SilentDragonXLite's `tiny-bip39` 0.6.2, and the derivation is anchored by a
known-answer test (`src/gtest/test_mnemonic_compat.cpp`).
## Restore from a phrase
Start the node once, on a **fresh/empty datadir**, with the phrase:
```
dragonxd -mnemonic="word1 word2 ... word24"
```
or, preferably (keeps the phrase out of your shell history and process list),
put it in `DRAGONX.conf` with tight permissions:
```
mnemonic=word1 word2 ... word24
```
On restore the node pre-derives keys and rescans from genesis to recover funds:
* `-hdtransparentgaplimit=<n>` — HD transparent keys to pre-derive (default 1000)
* `-mnemonicsaplinggap=<n>` — shielded addresses to pre-derive (default 100)
Raise these if the wallet used many addresses. Restore only works on a wallet
with no seed yet (a brand-new datadir); it refuses to overwrite an existing seed.
## Create a new phrase on the node
By default new node wallets use a random (non-mnemonic) seed. To create a new
wallet from a fresh 24-word phrase instead — so you can export it and use it in
SilentDragonXLite — start with:
```
dragonxd -usemnemonic
```
## Show / back up the phrase
For a mnemonic wallet (created with `-usemnemonic` or restored with `-mnemonic`):
```
dragonx-cli z_exportmnemonic
```
returns the 24 words and the seed fingerprint. The wallet must be unlocked.
Guard the phrase like a private key.
## Limitations
* **English + empty passphrase only.** Any other word list or a BIP39 passphrase
would break compatibility, so they are not accepted.
* **Legacy / random-seed wallets have no phrase.** A wallet created before this
feature (or without `-usemnemonic`) has a random seed; `z_exportmnemonic`
returns an error for it — use `z_exportwallet` to back up the raw seed. Such
wallets are not SilentDragonXLite-compatible.
* **Scope.** Recovers HD-derived shielded funds and transparent coinbase (see
[hd-transparent-keys.md](hd-transparent-keys.md) for why only coinbase lands on
t-addresses on this `ac_private=1` chain). Keys imported with `z_importkey` are
not seed-derived and are not recovered by the phrase.
## On-disk compatibility
Mnemonic wallets set `CHDChain` version 3 (`VERSION_HD_MNEMONIC`). Older wallet
records load unchanged. Downgrading a mnemonic wallet to an older binary is not
supported.

48
doc/shield-coinbase.md
View File

@@ -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

6
doc/tests.md
View File

@@ -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

59
doc/tor.md
View File

@@ -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
services (Tor v3). Tor v2 addresses are ignored by Hush and neither
relayed nor stored.
- DragonX only supports Tor version 3 hidden services (Tor v3). Tor v2
addresses are ignored by DragonX and neither 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

2
doc/translation_strings_policy.md
View File

@@ -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?

54
doc/wallet-backup.md
View File

@@ -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`

18
doc/zsweep-consolidation.md
View File

@@ -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. |
| 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. |
| 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 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

8
qa/rpc-tests/README.md
View File

@@ -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!

34
src/Makefile.am
View File

@@ -39,15 +39,22 @@ BITCOIN_INCLUDES += -I$(srcdir)/univalue/include
BITCOIN_INCLUDES += -I$(srcdir)/leveldb/include
if TARGET_WINDOWS
LIBBITCOIN_SERVER=libbitcoin_server.a -lcurl
LIBBITCOIN_SERVER=libbitcoin_server.a
endif
if TARGET_DARWIN
LIBBITCOIN_SERVER=libbitcoin_server.a -lcurl
LIBBITCOIN_SERVER=libbitcoin_server.a
endif
if TARGET_LINUX
LIBBITCOIN_SERVER=libbitcoin_server.a -lcurl
LIBBITCOIN_SERVER=libbitcoin_server.a
endif
# libcurl is a linker flag, not a buildable library file. It must NOT live inside
# LIBBITCOIN_SERVER, which is also fed into EXTRA_LIBRARIES (a list of files automake
# builds) where a -l flag is illegal and triggers a portability error. Keep it as its
# own variable, added to each binary's _LDADD after libbitcoin_server.a (whose objects
# reference curl symbols) so static link order stays correct.
LIBCURL = -lcurl
LIBBITCOIN_WALLET=libbitcoin_wallet.a
LIBBITCOIN_COMMON=libbitcoin_common.a
LIBBITCOIN_CLI=libbitcoin_cli.a
@@ -318,6 +325,7 @@ libbitcoin_wallet_a_SOURCES = \
wallet/asyncrpcoperation_shieldcoinbase.cpp \
wallet/crypter.cpp \
wallet/db.cpp \
wallet/mnemonic.cpp \
zcash/Note.cpp \
transaction_builder.cpp \
wallet/rpcdump.cpp \
@@ -354,6 +362,23 @@ crypto_libbitcoin_crypto_a_SOURCES = \
crypto/sha512.cpp \
crypto/sha512.h
# Vendored trezor-crypto BIP39 (mnemonic seed phrases). Kept self-contained so
# the same 24 words are compatible with SilentDragonXLite (tiny-bip39 0.6.2).
crypto_libbitcoin_crypto_a_SOURCES += \
crypto/bip39/bip39.c \
crypto/bip39/bip39.h \
crypto/bip39/bip39_english.h \
crypto/bip39/pbkdf2.c \
crypto/bip39/pbkdf2.h \
crypto/bip39/hmac.c \
crypto/bip39/hmac.h \
crypto/bip39/sha2.c \
crypto/bip39/sha2.h \
crypto/bip39/memzero.c \
crypto/bip39/memzero.h \
crypto/bip39/options.h \
crypto/bip39/rand.h
if EXPERIMENTAL_ASM
crypto_libbitcoin_crypto_a_SOURCES += crypto/sha256_sse4.cpp
endif
@@ -464,6 +489,7 @@ endif
dragonxd_LDADD = \
$(LIBBITCOIN_SERVER) \
$(LIBCURL) \
$(LIBBITCOIN_COMMON) \
$(LIBUNIVALUE) \
$(LIBBITCOIN_UTIL) \
@@ -685,5 +711,5 @@ endif
if ENABLE_TESTS
#include Makefile.test-hush.include
#include Makefile.test.include
#include Makefile.gtest.include
include Makefile.gtest.include
endif

88
src/Makefile.gtest.include
View File

@@ -4,65 +4,61 @@ TESTS += hush-gtest
bin_PROGRAMS += hush-gtest
# tool for generating our public parameters
# NOTE: the original test list used an invalid automake form (comment after a trailing
# backslash, and `zcash_gtest_SOURCES +=` with no prior `=`), which is why the whole
# gtest harness was disabled via a `#include`. Minimal valid set: the harness + the
# Re-add other gtest sources here as they are revived.
hush_gtest_SOURCES = \
gtest/main.cpp \
gtest/utils.cpp \
gtest/test_checktransaction.cpp \
gtest/json_test_vectors.cpp \
gtest/json_test_vectors.h \
gtest/test_wallet_zkeys.cpp \
# These tests are order-dependent, because they
# depend on global state (see #1539)
if ENABLE_WALLET
zcash_gtest_SOURCES += \
wallet/gtest/test_wallet_zkeys.cpp
endif
zcash_gtest_SOURCES += \
gtest/test_tautology.cpp \
gtest/test_deprecation.cpp \
gtest/test_equihash.cpp \
gtest/test_httprpc.cpp \
gtest/test_keys.cpp \
gtest/test_keystore.cpp \
gtest/test_noteencryption.cpp \
gtest/test_mempool.cpp \
gtest/test_merkletree.cpp \
gtest/test_metrics.cpp \
gtest/test_miner.cpp \
gtest/test_pow.cpp \
gtest/test_random.cpp \
gtest/test_rpc.cpp \
gtest/test_sapling_note.cpp \
gtest/test_transaction.cpp \
gtest/test_transaction_builder.cpp \
gtest/test_upgrades.cpp \
gtest/test_validation.cpp \
gtest/test_circuit.cpp \
gtest/test_txid.cpp \
gtest/test_libzcash_utils.cpp \
gtest/test_proofs.cpp \
gtest/test_pedersen_hash.cpp \
gtest/test_checkblock.cpp \
gtest/test_zip32.cpp
if ENABLE_WALLET
zcash_gtest_SOURCES += \
wallet/gtest/test_wallet.cpp
endif
gtest/test_randomx_preverify.cpp \
gtest/test_hdtransparent.cpp \
gtest/test_mnemonic_compat.cpp
hush_gtest_CPPFLAGS = $(AM_CPPFLAGS) -DMULTICORE -fopenmp -DBINARY_OUTPUT -DCURVE_ALT_BN128 -DSTATIC $(BITCOIN_INCLUDES)
hush_gtest_CXXFLAGS = $(AM_CXXFLAGS) $(PIE_FLAGS)
hush_gtest_LDADD = -lgtest -lgmock $(LIBBITCOIN_SERVER) $(LIBBITCOIN_CLI) $(LIBBITCOIN_COMMON) $(LIBBITCOIN_UTIL) $(LIBBITCOIN_CRYPTO) $(LIBBITCOIN_UNIVALUE) $(LIBLEVELDB) $(LIBMEMENV) \
$(BOOST_LIBS) $(BOOST_UNIT_TEST_FRAMEWORK_LIB) $(LIBSECP256K1)
# Mirror dragonxd_LDADD's working library set/order (the old list used a non-existent
# $(LIBBITCOIN_UNIVALUE) so univalue was never linked, and omitted LIBHUSH/LIBRANDOMX/libcc).
hush_gtest_LDADD = -lgtest -lgmock \
$(LIBBITCOIN_SERVER) \
$(LIBCURL) \
$(LIBBITCOIN_COMMON) \
$(LIBUNIVALUE) \
$(LIBBITCOIN_UTIL) \
$(LIBBITCOIN_CRYPTO) \
$(LIBZCASH) \
$(LIBHUSH) \
$(LIBLEVELDB) \
$(LIBMEMENV) \
$(LIBSECP256K1) \
$(LIBRANDOMX)
if ENABLE_WALLET
hush_gtest_LDADD += $(LIBBITCOIN_WALLET)
endif
hush_gtest_LDADD += $(LIBZCASH_CONSENSUS) $(BDB_LIBS) $(SSL_LIBS) $(CRYPTO_LIBS) $(EVENT_PTHREADS_LIBS) $(EVENT_LIBS) $(LIBZCASH) $(LIBZCASH_LIBS)
hush_gtest_LDADD += \
$(BOOST_LIBS) \
$(BOOST_UNIT_TEST_FRAMEWORK_LIB) \
$(BDB_LIBS) \
$(SSL_LIBS) \
$(CRYPTO_LIBS) \
$(EVENT_PTHREADS_LIBS) \
$(EVENT_LIBS) \
$(LIBBITCOIN_CRYPTO) \
$(LIBZCASH_LIBS)
hush_gtest_LDFLAGS = $(RELDFLAGS) $(AM_LDFLAGS) $(LIBTOOL_APP_LDFLAGS) -static
if TARGET_DARWIN
hush_gtest_LDADD += libcc.dylib $(LIBSECP256K1)
endif
if TARGET_WINDOWS
hush_gtest_LDADD += libcc.dll $(LIBSECP256K1)
endif
if TARGET_LINUX
hush_gtest_LDADD += libcc.so $(LIBSECP256K1)
endif
hush_gtest_LDFLAGS = $(RELDFLAGS) $(AM_LDFLAGS) $(LIBTOOL_APP_LDFLAGS) -static
hush_gtest_LDFLAGS = $(RELDFLAGS) $(AM_LDFLAGS) $(LIBTOOL_APP_LDFLAGS)
hush-gtest-expected-failures: hush-gtest FORCE
./hush-gtest --gtest_filter=*DISABLED_* --gtest_also_run_disabled_tests

4
src/Makefile.test.include
View File

@@ -112,13 +112,13 @@ endif
test_test_bitcoin_SOURCES = $(BITCOIN_TESTS) $(JSON_TEST_FILES) $(RAW_TEST_FILES)
test_test_bitcoin_CPPFLAGS = $(AM_CPPFLAGS) -fopenmp $(BITCOIN_INCLUDES) -I$(builddir)/test/ $(TESTDEFS) $(EVENT_CFLAGS)
test_test_bitcoin_LDADD = $(LIBBITCOIN_SERVER) $(LIBBITCOIN_CLI) $(LIBBITCOIN_COMMON) $(LIBBITCOIN_UTIL) $(LIBBITCOIN_CRYPTO) $(LIBUNIVALUE) $(LIBLEVELDB) $(LIBMEMENV) \
test_test_bitcoin_LDADD = $(LIBBITCOIN_SERVER) $(LIBCURL) $(LIBBITCOIN_CLI) $(LIBBITCOIN_COMMON) $(LIBBITCOIN_UTIL) $(LIBBITCOIN_CRYPTO) $(LIBUNIVALUE) $(LIBLEVELDB) $(LIBMEMENV) \
$(BOOST_LIBS) $(BOOST_UNIT_TEST_FRAMEWORK_LIB) $(LIBSECP256K1) $(EVENT_PTHREADS_LIBS) $(EVENT_LIBS)
test_test_bitcoin_CXXFLAGS = $(AM_CXXFLAGS) $(PIE_FLAGS)
if ENABLE_WALLET
test_test_bitcoin_LDADD += $(LIBBITCOIN_WALLET)
endif
test_test_bitcoin_LDADD += $(LIBBITCOIN_SERVER) $(LIBBITCOIN_CLI) $(LIBBITCOIN_COMMON) $(LIBBITCOIN_UTIL) $(LIBBITCOIN_CRYPTO) $(LIBUNIVALUE) \
test_test_bitcoin_LDADD += $(LIBBITCOIN_SERVER) $(LIBCURL) $(LIBBITCOIN_CLI) $(LIBBITCOIN_COMMON) $(LIBBITCOIN_UTIL) $(LIBBITCOIN_CRYPTO) $(LIBUNIVALUE) \
$(LIBLEVELDB) $(LIBMEMENV) $(BOOST_LIBS) $(BOOST_UNIT_TEST_FRAMEWORK_LIB) $(LIBSECP256K1) $(EVENT_LIBS) $(EVENT_PTHREADS_LIBS)
test_test_bitcoin_CXXFLAGS = $(AM_CXXFLAGS) $(PIE_FLAGS)

2
src/amount.cpp
View File

@@ -20,7 +20,7 @@
#include "amount.h"
#include "tinyformat.h"
const std::string CURRENCY_UNIT = "HUSH";
const std::string CURRENCY_UNIT = "DRAGONX";
CFeeRate::CFeeRate(const CAmount& nFeePaid, size_t nSize)
{

50
src/chain.h
View File

@@ -35,9 +35,15 @@ extern bool fZindex;
// These version thresholds control whether nSproutValue/nSaplingValue are
// serialized in the block index. They must be <= CLIENT_VERSION or the
// values will never be persisted, causing nChainSaplingValue to reset
// to 0 after node restart. DragonX CLIENT_VERSION is 1000250 (v1.0.2.50).
// to 0 after node restart. DragonX CLIENT_VERSION is 1000350 (v1.0.3.50).
static const int SPROUT_VALUE_VERSION = 1000000;
static const int SAPLING_VALUE_VERSION = 1000000;
// Block-index records written at >= this version store nSaplingValue as a boost::optional
// (1-byte discriminant + value). Earlier records stored it as a raw 8-byte CAmount; the
// deserializer consumes those bytes but reads the value as boost::none (untrusted) so the
// turnstile guard stays dormant until such a node reindexes. Keep == the CLIENT_VERSION that
// introduced the optional format (v1.0.3, CLIENT_VERSION 1000350).
static const int SAPLING_VALUE_OPTIONAL_VERSION = 1000350;
extern int32_t ASSETCHAINS_LWMAPOS;
extern char SMART_CHAIN_SYMBOL[65];
extern uint64_t ASSETCHAINS_NOTARY_PAY[];
@@ -373,10 +379,10 @@ public:
//! Will be boost::none if nChainTx is zero.
boost::optional<CAmount> nChainSproutValue;
//! Change in value held by the Sapling circuit over this block.
//! Not a boost::optional because this was added before Sapling activated, so we can
//! rely on the invariant that every block before this was added had nSaplingValue = 0.
CAmount nSaplingValue;
//! Change in value held by the Sapling circuit over this block. boost::none for blocks
//! before nSaplingValue was tracked, or on nodes that loaded an older-format block index
//! (see SAPLING_VALUE_OPTIONAL_VERSION) -- propagates to nChainSaplingValue == none.
boost::optional<CAmount> nSaplingValue;
//! (memory only) Total value held by the Sapling circuit up to and including this block.
//! Will be boost::none if nChainTx is zero.
@@ -399,7 +405,16 @@ public:
//! (memory only) Sequential id assigned to distinguish order in which blocks are received.
uint32_t nSequenceId;
//! (memory only) Set true once this block's RandomX PoW has been verified by the parallel
//! pre-verification pool, letting the inline check in CheckBlockHeader skip the recompute.
//! Written by exactly one pre-verify worker (1:1 with the block) and read by the connect
//! thread only AFTER the pool barrier (CCheckQueue::Wait provides the happens-before), so a
//! plain bool is race-free here. NOT serialized — a pure optimization hint; the inline
//! CheckRandomXSolution remains the consensus authority. (Plain bool, not std::atomic, so
//! CBlockIndex stays copyable for CDiskBlockIndex's `CBlockIndex(*pindex)` construction.)
bool fRandomXVerified;
void SetNull()
{
phashBlock = NULL;
@@ -414,6 +429,7 @@ public:
chainPower = CChainPower();
nTx = 0;
nChainTx = 0;
fRandomXVerified = false;
// Shieldex Index chain stats
nChainPayments = 0;
@@ -450,7 +466,7 @@ public:
nSequenceId = 0;
nSproutValue = boost::none;
nChainSproutValue = boost::none;
nSaplingValue = 0;
nSaplingValue = boost::none;
nChainSaplingValue = boost::none;
nVersion = 0;
@@ -657,10 +673,22 @@ public:
READWRITE(nSproutValue);
}
// Only read/write nSaplingValue if the client version used to create
// this index was storing them.
if ((s.GetType() & SER_DISK) && (nVersion >= SAPLING_VALUE_VERSION)) {
READWRITE(nSaplingValue);
// nSaplingValue is a boost::optional so "not reliably tracked" reads back as none,
// keeping the turnstile guard dormant on old/snapshot-bootstrapped DBs. Records written
// before SAPLING_VALUE_OPTIONAL_VERSION stored it as a raw 8-byte CAmount: consume those
// bytes for alignment but DISCARD the value (read as none), since it may be understated on
// a node that never tracked the pool from genesis. That node stays dormant until it
// reindexes, which rewrites records at the current version -> the optional path below.
if (s.GetType() & SER_DISK) {
if (nVersion >= SAPLING_VALUE_OPTIONAL_VERSION) {
READWRITE(nSaplingValue); // new format: boost::optional<CAmount>
} else if (nVersion >= SAPLING_VALUE_VERSION) {
CAmount nLegacySaplingValue = 0; // old format: raw 8 bytes present in the stream
READWRITE(nLegacySaplingValue); // consume for alignment; value is discarded
if (ser_action.ForRead())
nSaplingValue = boost::none;
}
// else (< SAPLING_VALUE_VERSION): field was never stored -> nSaplingValue stays none
}
// These values only serialized when -zindex enabled

8
src/chainparams.cpp
View File

@@ -101,7 +101,7 @@ public:
{
strNetworkID = "main";
strCurrencyUnits = "HUSH";
strCurrencyUnits = "DRAGONX";
bip44CoinType = 141; // As registered in https://github.com/satoshilabs/slips/blob/master/slip-0044.md
consensus.fCoinbaseMustBeProtected = false;
@@ -131,7 +131,9 @@ public:
consensus.vUpgrades[Consensus::UPGRADE_SAPLING].nActivationHeight = Consensus::NetworkUpgrade::NO_ACTIVATION_HEIGHT;
// The best chain should have at least this much work.
consensus.nMinimumChainWork = uint256S("0x00000000000000000000000000000000000000000000000000281b32ff3198a1");
// DRAGONX mainnet chainwork @ height ~3,100,000 (2026-07), safely below the live tip.
// (Previous value 0x281b32ff3198a1 was a stale inherited figure ABOVE the live chain.) Bump on release.
consensus.nMinimumChainWork = uint256S("0x0000000000000000000000000000000000000000000000000026dfbdb6fa39e0");
/**
* The message start string is designed to be unlikely to occur in normal data.
@@ -500,7 +502,7 @@ void hush_changeblocktime()
{
pCurrentParams->consensus.nMaxFutureBlockTime = 7 * ASSETCHAINS_BLOCKTIME;
pCurrentParams->consensus.nPowTargetSpacing = ASSETCHAINS_BLOCKTIME;
fprintf(stderr,"HUSH blocktime changing to %d seconds\n",ASSETCHAINS_BLOCKTIME);
fprintf(stderr,"DragonX blocktime changing to %d seconds\n",ASSETCHAINS_BLOCKTIME);
}
void hush_setactivation(int32_t height)

28
src/chainparamsseeds.h
View File

@@ -5,29 +5,17 @@
// Instead, update contrib/seeds/nodes_main.txt then run
// ./contrib/seeds/generate-seeds.py contrib/seeds > src/chainparamsseeds.h
// OR run: make seeds
#ifndef HUSH_CHAINPARAMSSEEDS_H
#define HUSH_CHAINPARAMSSEEDS_H
// List of fixed seed nodes for the Hush network
#ifndef DRAGONX_CHAINPARAMSSEEDS_H
#define DRAGONX_CHAINPARAMSSEEDS_H
// List of fixed seed nodes for the DragonX network
// Each line contains a BIP155 serialized address.
//
static const uint8_t chainparams_seed_main[] = {
0x01,0x04,0x67,0x45,0x80,0x94,0x00,0x00, // 103.69.128.148
0x01,0x04,0xc2,0x1d,0x64,0xb3,0x00,0x00, // 194.29.100.179
0x01,0x04,0x2d,0x84,0x4b,0x45,0x00,0x00, // 45.132.75.69
0x01,0x04,0xaa,0xcd,0x27,0x27,0x00,0x00, // 170.205.39.39
0x01,0x04,0x95,0x1c,0x66,0xdb,0x00,0x00, // 149.28.102.219
0x01,0x04,0x9b,0x8a,0xe4,0x44,0x00,0x00, // 155.138.228.68
0x01,0x04,0x6b,0xae,0x46,0xfb,0x00,0x00, // 107.174.70.251
0x01,0x04,0xb2,0xfa,0xbd,0x8d,0x00,0x00, // 178.250.189.141
0x04,0x20,0x0e,0x86,0xb6,0xfd,0x96,0xfe,0x06,0xda,0x39,0xeb,0x97,0x39,0xc9,0xd1,0x17,0xa2,0x4e,0x2b,0x75,0x4d,0xeb,0xb5,0xa1,0x34,0x1e,0x34,0x0a,0xcb,0x68,0xab,0xf0,0xe2,0x00,0x00, // b2dln7mw7ydnuopls444tuixujhcw5kn5o22cna6gqfmw2fl6drb5nad.onion
0x04,0x20,0x1c,0x96,0x10,0x03,0xa6,0xa4,0xfa,0xa0,0x3e,0x13,0x1f,0x38,0xf0,0x9b,0xdd,0x9b,0xd7,0xdc,0x0e,0x40,0x61,0x71,0xed,0x1d,0x21,0x58,0xce,0x59,0x55,0x5e,0xe4,0x25,0x00,0x00, // dslbaa5gut5kapqtd44pbg65tpl5ydsamfy62hjbldhfsvk64qs57pyd.onion
0x04,0x20,0xac,0xa0,0x3a,0x31,0xa7,0xea,0x8e,0x90,0xc7,0x2b,0xbb,0x89,0x41,0x05,0x48,0xa0,0x10,0x29,0x8f,0x38,0x16,0xc9,0x94,0xbe,0xef,0x7e,0x9e,0x7d,0x98,0xb6,0x76,0x9f,0x00,0x00, // vsqdumnh5khjbrzlxoeucbkiuaictdzyc3ezjpxpp2ph3gfwo2ptjmyd.onion
0x02,0x10,0x2a,0x0c,0xb6,0x41,0x06,0xf1,0x01,0x8e,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02,0x00,0x00, // 2a0c:b641:6f1:18e::2
0x02,0x10,0x24,0x06,0xef,0x80,0x00,0x03,0x12,0x69,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00, // 2406:ef80:3:1269::1
0x02,0x10,0x24,0x06,0xef,0x80,0x00,0x02,0x3b,0x59,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00, // 2406:ef80:2:3b59::1
0x02,0x10,0x24,0x06,0xef,0x80,0x00,0x01,0x14,0x6e,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00, // 2406:ef80:1:146e::1
0x02,0x10,0x24,0x06,0xef,0x80,0x00,0x04,0x21,0x32,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00, // 2406:ef80:4:2132::1
0x05,0x20,0xfb,0xa8,0xca,0x3d,0xf4,0xc9,0x83,0x95,0xa8,0x07,0x05,0x6f,0xf8,0x46,0x69,0x6d,0x42,0x75,0x22,0xe9,0x80,0xd8,0x43,0x7c,0xbe,0x29,0xda,0x33,0x14,0xf9,0xfb,0x17,0x00,0x00, // 7oumuppuzgbzlkahavx7qrtjnvbhkixjqdmeg7f6fhndgfhz7mlq.b32.i2p
0x01,0x04,0xd4,0x38,0x29,0x3f,0x00,0x00, // 212.56.41.63
0x01,0x04,0xc2,0x8c,0xc6,0xb0,0x00,0x00, // 194.140.198.176
0x01,0x04,0xd4,0x38,0x29,0x2f,0x00,0x00, // 212.56.41.47
0x01,0x04,0x90,0x7e,0x93,0xa5,0x00,0x00, // 144.126.147.165
0x01,0x04,0xb0,0x7e,0x57,0xf1,0x00,0x00, // 176.126.87.241
};
static const uint8_t chainparams_seed_test[] = {

2
src/clientversion.h
View File

@@ -30,7 +30,7 @@
// Must be kept in sync with configure.ac , ugh!
#define CLIENT_VERSION_MAJOR 1
#define CLIENT_VERSION_MINOR 0
#define CLIENT_VERSION_REVISION 2
#define CLIENT_VERSION_REVISION 3
#define CLIENT_VERSION_BUILD 50
//! Set to true for release, false for prerelease or test build

7
src/crypto/bip39/bip39.c
View File

@@ -33,10 +33,13 @@
#include "rand.h"
#include "sha2.h"
#if USE_BIP39_CACHE
// BIP39_WORDS is used unconditionally by the wordlist helpers below, so it must
// be defined even when the BIP39 cache is disabled (upstream places it inside
// the cache block by mistake).
int BIP39_WORDS = 2048;
#if USE_BIP39_CACHE
static int bip39_cache_index = 0;
static CONFIDENTIAL struct {

4
src/crypto/bip39/options.h
View File

@@ -56,8 +56,10 @@
#endif
// implement BIP39 caching
// Disabled: caching keeps the plaintext mnemonic/passphrase/seed in a static
// process-lifetime buffer, which we do not want in a wallet daemon.
#ifndef USE_BIP39_CACHE
#define USE_BIP39_CACHE 1
#define USE_BIP39_CACHE 0
#define BIP39_CACHE_SIZE 4
#endif

171
src/gtest/test_hdtransparent.cpp Normal file
View File

@@ -0,0 +1,171 @@
// 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
//
// Tests for HD-derived transparent keys (m/44'/coin'/0'/0/i) and the
// version-gated CHDChain serialization used to persist the transparent counter.
#include <gtest/gtest.h>
#include "key.h"
#include "chainparams.h"
#include "streams.h"
#include "uint256.h"
#include "util.h"
#include "version.h"
#include "wallet/wallet.h"
#include "wallet/walletdb.h"
#include "zcash/zip32.h"
// Build an in-memory wallet with a known seed + hdChain so that the
// HD-transparent path (IsHDTransparentEnabled) is active.
static void LoadSeedForTest(CWallet& wallet, const HDSeed& seed)
{
wallet.LoadHDSeed(seed);
CHDChain chain;
chain.nVersion = CHDChain::VERSION_HD_TRANSPARENT;
chain.seedFp = seed.Fingerprint();
chain.nCreateTime = 1;
wallet.SetHDChain(chain, true /* memonly */);
}
// Same seed must reproduce the same transparent addresses in the same order:
// this is the recovery guarantee that lets a seed-only restore find coinbase.
TEST(hdtransparent_tests, DeterministicFromSeed)
{
SelectParams(CBaseChainParams::MAIN);
RawHDSeed rawSeed(HD_WALLET_SEED_LENGTH, 0x42);
HDSeed seed(rawSeed);
std::vector<CKeyID> keysA;
{
CWallet wallet;
LoadSeedForTest(wallet, seed);
ASSERT_TRUE(wallet.IsHDTransparentEnabled());
LOCK(wallet.cs_wallet);
for (int i = 0; i < 5; i++) {
CPubKey pk = wallet.GenerateNewKey();
keysA.push_back(pk.GetID());
const CKeyMetadata& md = wallet.mapKeyMetadata[pk.GetID()];
EXPECT_EQ(md.seedFp, seed.Fingerprint());
EXPECT_EQ(md.hdKeypath, std::string("m/44'/141'/0'/0/") + std::to_string(i));
}
}
// Fresh wallet, same seed -> identical keys.
{
CWallet wallet;
LoadSeedForTest(wallet, seed);
LOCK(wallet.cs_wallet);
for (int i = 0; i < 5; i++) {
CPubKey pk = wallet.GenerateNewKey();
EXPECT_EQ(pk.GetID(), keysA[i]);
}
}
}
// Pin the exact derivation path so it can never silently change.
TEST(hdtransparent_tests, KnownDerivationPath)
{
SelectParams(CBaseChainParams::MAIN);
RawHDSeed rawSeed(HD_WALLET_SEED_LENGTH, 0x42);
HDSeed seed(rawSeed);
// Independently derive m/44'/141'/0'/0/0.
RawHDSeed raw = seed.RawSeed();
CExtKey m, purpose, coinType, account, external, child;
m.SetMaster(raw.data(), raw.size());
m.Derive(purpose, 44 | BIP32_HARDENED_KEY_LIMIT);
purpose.Derive(coinType, 141 | BIP32_HARDENED_KEY_LIMIT);
coinType.Derive(account, 0 | BIP32_HARDENED_KEY_LIMIT);
account.Derive(external, 0);
external.Derive(child, 0);
CKeyID expected = child.key.GetPubKey().GetID();
CWallet wallet;
LoadSeedForTest(wallet, seed);
LOCK(wallet.cs_wallet);
CPubKey pk = wallet.GenerateNewKey();
EXPECT_EQ(pk.GetID(), expected);
}
// A pre-existing v1 CHDChain record (no transparent counter) must still
// deserialize under v2 code, leaving transparentChildCounter at 0; and a v2
// record must round-trip the counter.
TEST(hdtransparent_tests, HDChainVersionCompat)
{
CHDChain v1;
v1.nVersion = CHDChain::VERSION_HD_BASE; // 1: transparentChildCounter not serialized
v1.seedFp = uint256S("0000000000000000000000000000000000000000000000000000000000000001");
v1.nCreateTime = 12345;
v1.saplingAccountCounter = 7;
CDataStream ss(SER_DISK, PROTOCOL_VERSION);
ss << v1;
CHDChain out; // default-constructed: SetNull() zeroes transparentChildCounter
ss >> out;
EXPECT_EQ(out.nVersion, +CHDChain::VERSION_HD_BASE); // unary + -> rvalue, avoid ODR-use of static const
EXPECT_EQ(out.seedFp, v1.seedFp);
EXPECT_EQ(out.nCreateTime, (int64_t)12345);
EXPECT_EQ(out.saplingAccountCounter, (uint32_t)7);
EXPECT_EQ(out.transparentChildCounter, (uint32_t)0);
CHDChain v2;
v2.nVersion = CHDChain::VERSION_HD_TRANSPARENT;
v2.saplingAccountCounter = 3;
v2.transparentChildCounter = 42;
CDataStream ss2(SER_DISK, PROTOCOL_VERSION);
ss2 << v2;
CHDChain out2;
ss2 >> out2;
EXPECT_EQ(out2.nVersion, +CHDChain::VERSION_HD_TRANSPARENT);
EXPECT_EQ(out2.saplingAccountCounter, (uint32_t)3);
EXPECT_EQ(out2.transparentChildCounter, (uint32_t)42);
}
// Restoring from a 32-byte seed hex reproduces the same keys as the source
// wallet, and refuses to run when a seed already exists.
TEST(hdtransparent_tests, RestoreFromSeedHex)
{
SelectParams(CBaseChainParams::MAIN);
RawHDSeed rawSeed(HD_WALLET_SEED_LENGTH, 0x7a);
HDSeed seed(rawSeed);
std::string seedHex = HexStr(seed.RawSeed());
// Source wallet: derive some keys.
std::vector<CKeyID> expected;
{
CWallet wallet;
LoadSeedForTest(wallet, seed);
LOCK(wallet.cs_wallet);
for (int i = 0; i < 3; i++)
expected.push_back(wallet.GenerateNewKey().GetID());
}
// Restored wallet: inject the seed hex, pre-derive, and compare.
{
CWallet wallet;
ASSERT_TRUE(wallet.SetHDSeedFromHex(seedHex));
// Second attempt must fail: a seed already exists.
EXPECT_FALSE(wallet.SetHDSeedFromHex(seedHex));
wallet.TopUpHDTransparentKeys(3, 1);
LOCK(wallet.cs_wallet);
for (int i = 0; i < 3; i++)
EXPECT_TRUE(wallet.HaveKey(expected[i]));
}
// Bad input is rejected.
{
CWallet wallet;
EXPECT_FALSE(wallet.SetHDSeedFromHex("nothex"));
EXPECT_FALSE(wallet.SetHDSeedFromHex("abcd")); // too short
}
}

141
src/gtest/test_mnemonic_compat.cpp Normal file
View File

@@ -0,0 +1,141 @@
// 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
//
// Proves that a BIP39 seed phrase produces the SAME transparent and shielded
// addresses on the DragonX full node as in SilentDragonXLite. The proof chain:
// phrase -> entropy (round-trip) -> 64-byte BIP39 seed (known-answer)
// -> z/t addresses (wallet path == direct ZIP-32/BIP44 derivation).
// The 64-byte seed is anchored to the well-known BIP39 value for the all-zero
// "abandon...art" entropy with an EMPTY passphrase, which is exactly what
// SilentDragonXLite's tiny-bip39 0.6.2 feeds into the same coin_type=141 paths.
#include <gtest/gtest.h>
#include "chainparams.h"
#include "key.h"
#include "key_io.h"
#include "util.h"
#include "wallet/mnemonic.h"
#include "wallet/wallet.h"
#include "zcash/Address.hpp"
#include "zcash/zip32.h"
// The canonical 24-word phrase for 32 bytes of all-zero entropy.
static const char* ABANDON_ART =
"abandon abandon abandon abandon abandon abandon abandon abandon "
"abandon abandon abandon abandon abandon abandon abandon abandon "
"abandon abandon abandon abandon abandon abandon abandon art";
// The standard BIP39 seed for that phrase with an EMPTY passphrase
// (PBKDF2-HMAC-SHA512, 2048 rounds, salt "mnemonic"). Matches tiny-bip39.
static const char* SEED64_HEX =
"408b285c123836004f4b8842c89324c1f01382450c0d439af345ba7fc49acf70"
"5489c6fc77dbd4e3dc1dd8cc6bc9f043db8ada1e243c4a0eafb290d399480840";
// First shielded address for a 64-byte seed: m/32'/141'/0' default address.
static std::string DeriveZAddrFromSeed64(RawHDSeed seed64)
{
HDSeed s(seed64);
auto m = libzcash::SaplingExtendedSpendingKey::Master(s);
auto xsk = m.Derive(32 | ZIP32_HARDENED_KEY_LIMIT)
.Derive(141 | ZIP32_HARDENED_KEY_LIMIT)
.Derive(0 | ZIP32_HARDENED_KEY_LIMIT);
return EncodePaymentAddress(xsk.DefaultAddress());
}
// First transparent address for a BIP32 master over `seedBytes`:
// m/44'/141'/0'/0/0.
static std::string DeriveTAddrFromSeedBytes(RawHDSeed seedBytes)
{
CExtKey master, purpose, coinType, account, external, child;
master.SetMaster(seedBytes.data(), seedBytes.size());
master.Derive(purpose, 44 | BIP32_HARDENED_KEY_LIMIT);
purpose.Derive(coinType, 141 | BIP32_HARDENED_KEY_LIMIT);
coinType.Derive(account, 0 | BIP32_HARDENED_KEY_LIMIT);
account.Derive(external, 0);
external.Derive(child, 0);
return EncodeDestination(child.key.GetPubKey().GetID());
}
// The 64-byte seed derived from the mnemonic must equal the known BIP39 value.
// This is the cross-wallet anchor: SilentDragonXLite feeds the identical seed.
TEST(mnemonic_compat, Bip39SeedKnownAnswer)
{
RawHDSeed entropy(32, 0);
RawHDSeed seed64;
ASSERT_TRUE(Bip39SeedFromEntropy(entropy, seed64));
ASSERT_EQ(seed64.size(), (size_t)64);
EXPECT_EQ(HexStr(seed64.begin(), seed64.end()), std::string(SEED64_HEX));
}
TEST(mnemonic_compat, EntropyPhraseRoundTrip)
{
RawHDSeed zeros(32, 0);
std::string phrase;
ASSERT_TRUE(EntropyToMnemonic(zeros, phrase));
EXPECT_EQ(phrase, std::string(ABANDON_ART));
EXPECT_TRUE(MnemonicIsValid(ABANDON_ART));
RawHDSeed entropy;
ASSERT_TRUE(MnemonicToEntropy(ABANDON_ART, entropy));
EXPECT_EQ(entropy.size(), (size_t)32);
EXPECT_EQ(HexStr(entropy.begin(), entropy.end()), std::string(64, '0'));
// Bad checksum / unknown words are rejected.
EXPECT_FALSE(MnemonicIsValid("abandon abandon abandon"));
EXPECT_FALSE(MnemonicIsValid("clearly not valid bip39 words at all here"));
RawHDSeed junk;
EXPECT_FALSE(MnemonicToEntropy("clearly not valid bip39 words at all here", junk));
}
// The wallet's mnemonic derivation must reproduce the exact addresses obtained
// by driving ZIP-32 / BIP44 directly from the known 64-byte seed, and must be
// deterministic across wallets.
TEST(mnemonic_compat, WalletDerivesSdxliteAddresses)
{
SelectParams(CBaseChainParams::MAIN);
RawHDSeed zeros(32, 0), seed64;
ASSERT_TRUE(Bip39SeedFromEntropy(zeros, seed64));
const std::string expZ = DeriveZAddrFromSeed64(seed64);
const std::string expT = DeriveTAddrFromSeedBytes(seed64);
EXPECT_EQ(expZ.substr(0, 2), "zs"); // sapling HRP for mainnet
CWallet wallet;
ASSERT_TRUE(wallet.SetHDSeedFromMnemonic(ABANDON_ART));
ASSERT_TRUE(wallet.IsMnemonicSeed());
{
LOCK(wallet.cs_wallet);
EXPECT_EQ(EncodePaymentAddress(wallet.GenerateNewSaplingZKey()), expZ);
EXPECT_EQ(EncodeDestination(wallet.GenerateNewKey().GetID()), expT);
}
// Same phrase, fresh wallet -> identical first addresses.
CWallet wallet2;
ASSERT_TRUE(wallet2.SetHDSeedFromMnemonic(ABANDON_ART));
{
LOCK(wallet2.cs_wallet);
EXPECT_EQ(EncodePaymentAddress(wallet2.GenerateNewSaplingZKey()), expZ);
EXPECT_EQ(EncodeDestination(wallet2.GenerateNewKey().GetID()), expT);
}
// The phrase round-trips out of the wallet.
std::string exported;
ASSERT_TRUE(wallet.GetMnemonicPhrase(exported));
EXPECT_EQ(exported, std::string(ABANDON_ART));
}
// Negative: feeding the 32-byte entropy DIRECTLY as the seed (the classic
// interop bug) must produce a different address than the 64-byte BIP39 seed.
TEST(mnemonic_compat, RawEntropyDiffersFromMnemonicSeed)
{
SelectParams(CBaseChainParams::MAIN);
RawHDSeed zeros(32, 0), seed64;
ASSERT_TRUE(Bip39SeedFromEntropy(zeros, seed64));
const std::string seedT = DeriveTAddrFromSeedBytes(seed64); // correct (64-byte)
const std::string entropyT = DeriveTAddrFromSeedBytes(zeros); // wrong (32-byte)
EXPECT_NE(seedT, entropyT);
}

172
src/gtest/test_randomx_preverify.cpp Normal file
View File

@@ -0,0 +1,172 @@
// 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
//
// Consensus-equivalence test for the parallel RandomX pre-verification pool. The pool is purely an
// optimization: a block's transient fRandomXVerified flag (set by CRandomXCheck on a real hash
// match) only lets CheckBlockHeader SKIP the inline recompute. So for every block the pool's
// outcome must equal the inline CheckRandomXSolution outcome — `(preVerified || inline) == inline`.
// We exercise a valid solution, a corrupted solution, and confirm the pool never "succeeds" on a
// block the inline check would reject.
#include <gtest/gtest.h>
#include <string>
#include <vector>
#include "arith_uint256.h"
#include "chain.h"
#include "chainparams.h"
#include "pow.h"
#include "primitives/block.h"
#include "RandomX/src/randomx.h"
#include "hush_defs.h"
#include "util.h"
#include <boost/thread.hpp>
#include <memory>
extern int32_t HUSH_LOADINGBLOCKS;
extern bool fCheckpointsEnabled;
namespace {
// Compute the correct RandomX solution for a header using a standalone reference light VM, via the
// SAME key + input helpers the validator uses (so the bytes/key match exactly).
void ReferenceRandomXHash(const CBlockHeader& hdr, const std::string& key, unsigned char out[RANDOMX_HASH_SIZE])
{
std::vector<unsigned char> in = GetRandomXInput(hdr);
randomx_flags flags = randomx_get_flags();
randomx_cache* c = randomx_alloc_cache(flags);
ASSERT_NE(c, nullptr);
randomx_init_cache(c, key.data(), key.size());
randomx_vm* vm = randomx_create_vm(flags, c, nullptr);
ASSERT_NE(vm, nullptr);
randomx_calculate_hash(vm, in.data(), in.size(), out);
randomx_destroy_vm(vm);
randomx_release_cache(c);
}
} // namespace
TEST(RandomXPreVerify, ConsensusEquivalence)
{
// Force RandomX validation to actually run at low heights in the test harness.
uint32_t savedAlgo = ASSETCHAINS_ALGO, savedRx = ASSETCHAINS_RANDOMX;
int32_t savedVal = ASSETCHAINS_RANDOMX_VALIDATION, savedLoad = HUSH_LOADINGBLOCKS;
bool savedCkpt = fCheckpointsEnabled;
ASSETCHAINS_RANDOMX = 2; // a distinct nonzero algo id
ASSETCHAINS_ALGO = ASSETCHAINS_RANDOMX;
ASSETCHAINS_RANDOMX_VALIDATION = 1; // enforce from height 1
HUSH_LOADINGBLOCKS = 0; // not in initial-load (else RandomX skipped)
fCheckpointsEnabled = false; // avoid the below-checkpoint skip
const int32_t height = 10; // < interval+lag -> the chain-params initial key (no chainActive needed)
CBlockHeader hdr;
hdr.nVersion = 4;
hdr.hashPrevBlock = uint256S("0x0000000000000000000000000000000000000000000000000000000000000001");
hdr.hashMerkleRoot = uint256S("0x0000000000000000000000000000000000000000000000000000000000000002");
hdr.hashFinalSaplingRoot = uint256S("0x0000000000000000000000000000000000000000000000000000000000000003");
hdr.nTime = 1700000000;
hdr.nBits = 0x200f0f0f;
hdr.nNonce = uint256S("0x0000000000000000000000000000000000000000000000000000000000000004");
std::string key = GetRandomXKey(height);
ASSERT_FALSE(key.empty());
unsigned char good[RANDOMX_HASH_SIZE];
ReferenceRandomXHash(hdr, key, good);
// Run the pool path synchronously on this thread (CRandomXCheck creates its own thread_local VM).
auto poolVerifies = [&](const CBlockHeader& h) -> bool {
RandomXValidatorPrepareKey(key); // load the shared cache with this key
bool slot = false;
CRandomXCheck chk(key, GetRandomXInput(h), h.nSolution.data(), &slot);
chk();
return slot;
};
// Case 1 — valid solution: both inline and pool accept; equivalence holds.
hdr.nSolution.assign(good, good + RANDOMX_HASH_SIZE);
EXPECT_TRUE(CheckRandomXSolution(&hdr, height));
EXPECT_TRUE(poolVerifies(hdr));
EXPECT_EQ(poolVerifies(hdr) || CheckRandomXSolution(&hdr, height), CheckRandomXSolution(&hdr, height));
// Case 2 — corrupted solution: both reject; the pool must NOT set verified.
{
CBlockHeader bad = hdr;
bad.nSolution[0] ^= 0xff;
EXPECT_FALSE(CheckRandomXSolution(&bad, height));
EXPECT_FALSE(poolVerifies(bad));
EXPECT_EQ(poolVerifies(bad) || CheckRandomXSolution(&bad, height), CheckRandomXSolution(&bad, height));
}
// Case 3 — a verified flag on the block lets CheckBlockHeader skip, but verified is only ever set
// by a real hash match, so it can never mask an invalid block. (Pool returns false for the bad
// block above, so its fRandomXVerified stays false and the inline path rejects it at connect.)
ASSETCHAINS_ALGO = savedAlgo; ASSETCHAINS_RANDOMX = savedRx;
ASSETCHAINS_RANDOMX_VALIDATION = savedVal; HUSH_LOADINGBLOCKS = savedLoad;
fCheckpointsEnabled = savedCkpt;
}
// A/B: serial inline verification (single VM) vs the parallel pool (worker threads). Directly
// measures the speedup the pool delivers. We don't care about validity here (mismatched solutions
// still cost a full hash), only wall-clock. parallel must beat serial whenever >1 core is used.
TEST(RandomXPreVerify, ParallelSpeedup)
{
uint32_t savedAlgo = ASSETCHAINS_ALGO, savedRx = ASSETCHAINS_RANDOMX;
int32_t savedVal = ASSETCHAINS_RANDOMX_VALIDATION, savedLoad = HUSH_LOADINGBLOCKS;
bool savedCkpt = fCheckpointsEnabled;
ASSETCHAINS_RANDOMX = 2; ASSETCHAINS_ALGO = ASSETCHAINS_RANDOMX;
ASSETCHAINS_RANDOMX_VALIDATION = 1; HUSH_LOADINGBLOCKS = 0; fCheckpointsEnabled = false;
const int32_t height = 10;
std::string key = GetRandomXKey(height);
ASSERT_FALSE(key.empty());
ASSERT_TRUE(RandomXValidatorPrepareKey(key));
const int M = 16; // blocks to verify in the window
std::vector<CBlockHeader> hdrs(M);
for (int i = 0; i < M; i++) {
hdrs[i].nVersion = 4;
hdrs[i].nTime = 1700000000 + i;
hdrs[i].nBits = 0x200f0f0f;
hdrs[i].nNonce = ArithToUint256(arith_uint256(i + 1)); // distinct inputs
hdrs[i].nSolution.assign(RANDOMX_HASH_SIZE, 0); // arbitrary; we time the hash
}
// Serial baseline: inline single-VM verification (each call hashes, then mismatches -> false).
int64_t t0 = GetTimeMicros();
for (int i = 0; i < M; i++) CheckRandomXSolution(&hdrs[i], height);
int64_t serialUs = GetTimeMicros() - t0;
// Parallel: spawn K-1 workers + the master (this thread) joining via Wait().
int K = std::min(8, std::max(2, (int)boost::thread::hardware_concurrency()));
boost::thread_group workers;
for (int i = 0; i < K - 1; i++) workers.create_thread(&ThreadRandomXVerify);
std::unique_ptr<bool[]> slots(new bool[M]());
std::vector<CRandomXCheck> checks;
checks.reserve(M);
for (int i = 0; i < M; i++)
checks.push_back(CRandomXCheck(key, GetRandomXInput(hdrs[i]), hdrs[i].nSolution.data(), &slots[i]));
int64_t t1 = GetTimeMicros();
{
CCheckQueueControl<CRandomXCheck> control(&rxCheckQueue);
control.Add(checks);
control.Wait();
}
int64_t parallelUs = GetTimeMicros() - t1;
workers.interrupt_all();
workers.join_all();
printf("[ RandomX A/B ] %d blocks: serial(1 VM)=%ldms, parallel(%d threads)=%ldms, speedup=%.1fx\n",
M, (long)(serialUs / 1000), K, (long)(parallelUs / 1000),
(double)serialUs / (double)std::max<int64_t>(1, parallelUs));
EXPECT_LT(parallelUs, serialUs); // parallel must be faster than serial on a multi-core box
ASSETCHAINS_ALGO = savedAlgo; ASSETCHAINS_RANDOMX = savedRx;
ASSETCHAINS_RANDOMX_VALIDATION = savedVal; HUSH_LOADINGBLOCKS = savedLoad;
fCheckpointsEnabled = savedCkpt;
}

14
src/hush.h
View File

@@ -510,7 +510,9 @@ int32_t hush_validate_chain(uint256 srchash,int32_t notarized_height)
return(0);
if ( IsInitialBlockDownload() == 0 && ((pindex= hush_getblockindex(srchash)) == 0 || pindex->GetHeight() != notarized_height) )
{
fprintf(stderr,"%s: Not in IBD, height=%d\n", __func__, pindex->GetHeight() );
// SECURITY (null-deref crash DoS): this branch is entered when pindex==0 (srchash, taken
// from an attacker-controlled notarization OP_RETURN, is not a known block). Guard the deref.
fprintf(stderr,"%s: Not in IBD, height=%d\n", __func__, pindex != 0 ? pindex->GetHeight() : -1 );
if ( sp->NOTARIZED_HEIGHT > 0 && sp->NOTARIZED_HEIGHT < notarized_height )
rewindtarget = sp->NOTARIZED_HEIGHT - 1;
else if ( notarized_height > 101 )
@@ -589,6 +591,14 @@ int32_t hush_voutupdate(bool fJustCheck,int32_t *isratificationp,int32_t notaryi
opretlen += (scriptbuf[len++] << 8);
}
opoffset = len;
// SECURITY (Finding #4): opretlen is attacker-controlled (up to 65535 via OP_PUSHDATA2)
// and was previously used with no bounds check. scriptbuf is a fixed DRAGON_MAXSCRIPTSIZE
// stack buffer in hush_connectblock, so an oversized opretlen drives out-of-bounds reads in
// the downstream 'K'/KV and notarization paths (persisted to disk, leaked via kvsearch RPC,
// reliable crash on block connect). Reject any opret claiming more bytes than actually
// remain in the real script; this mirrors the no-OP_RETURN fall-through so nothing valid changes.
if ( opretlen < 0 || opretlen > scriptlen - len )
return(notaryid);
matched = 0;
if ( SMART_CHAIN_SYMBOL[0] == 0 )
{
@@ -931,7 +941,7 @@ int32_t hush_connectblock(bool fJustCheck, CBlockIndex *pindex,CBlock& block)
if ( len >= sizeof(uint32_t) && len <= sizeof(scriptbuf) )
{
memcpy(scriptbuf,(uint8_t *)&block.vtx[i].vout[j].scriptPubKey[0],len);
if ( len == 35 && scriptbuf[0] == 33 && scriptbuf[34] == 0xac )
if ( len == 35 && scriptbuf[0] == 33 && scriptbuf[34] == 0xac && numvalid < (int32_t)(sizeof(pubkeys)/sizeof(pubkeys[0])) )
{
memcpy(pubkeys[numvalid++],scriptbuf+1,33);
for (k=0; k<33; k++)

139
src/hush/tlsmanager.cpp
View File

@@ -580,70 +580,103 @@ int TLSManager::threadSocketHandler(CNode* pnode, fd_set& fdsetRecv, fd_set& fds
char pchBuf[0x10000];
bool bIsSSL = false;
int nBytes = 0, nRet = 0;
// Drain the socket in a bounded loop rather than one read per select pass: a single
// 64K read per pass underfills high-bandwidth/high-latency links. Cap the reads per
// pass and honor the receive-flood back-pressure so one peer can neither exhaust
// memory nor starve other peers within this pass.
int nDrainReads = 0;
const int MAX_DRAIN_READS = 16; // up to ~1 MiB per peer per pass (fairness across peers)
// Pre-read back-pressure: gate on the flood ceiling BEFORE each read so the per-peer
// recv buffer high-water stays at ReceiveFloodSize()+one read (matching the select()
// FD_SET gate), and track bytes locally to avoid the O(n) GetTotalRecvSize() per pass.
const int64_t nRecvBase = (int64_t)pnode->GetTotalRecvSize();
int64_t nPassBytes = 0;
bool fKeepReading = true;
while (fKeepReading) {
int nSSLPending = 0;
if (nRecvBase + nPassBytes > (int64_t)ReceiveFloodSize())
break;
{
LOCK(pnode->cs_hSocket);
{
LOCK(pnode->cs_hSocket);
if (pnode->hSocket == INVALID_SOCKET) {
LogPrint("tls", "Receive: connection with %s is already closed\n", pnode->addr.ToString());
return -1;
}
if (pnode->hSocket == INVALID_SOCKET) {
LogPrint("tls", "Receive: connection with %s is already closed\n", pnode->addr.ToString());
return -1;
bIsSSL = (pnode->ssl != NULL);
if (bIsSSL) {
wolfSSL_ERR_clear_error(); // clear the error queue, otherwise we may be reading an old error that occurred previously in the current thread
nBytes = wolfSSL_read(pnode->ssl, pchBuf, sizeof(pchBuf));
nRet = wolfSSL_get_error(pnode->ssl, nBytes);
// Capture TLS buffered-byte count while still under cs_hSocket; the drain-continuation
// check below runs unlocked, so touching pnode->ssl there would race with
// SocketSendData / CloseSocketDisconnect (which free ssl) -> data race / use-after-free.
nSSLPending = wolfSSL_pending(pnode->ssl);
} else {
nBytes = recv(pnode->hSocket, pchBuf, sizeof(pchBuf), MSG_DONTWAIT);
nRet = WSAGetLastError();
}
}
bIsSSL = (pnode->ssl != NULL);
if (bIsSSL) {
wolfSSL_ERR_clear_error(); // clear the error queue, otherwise we may be reading an old error that occurred previously in the current thread
nBytes = wolfSSL_read(pnode->ssl, pchBuf, sizeof(pchBuf));
nRet = wolfSSL_get_error(pnode->ssl, nBytes);
} else {
nBytes = recv(pnode->hSocket, pchBuf, sizeof(pchBuf), MSG_DONTWAIT);
nRet = WSAGetLastError();
}
}
if (nBytes > 0) {
if (!pnode->ReceiveMsgBytes(pchBuf, nBytes))
pnode->CloseSocketDisconnect();
pnode->nLastRecv = GetTime();
pnode->nRecvBytes += nBytes;
pnode->RecordBytesRecv(nBytes);
} else if (nBytes == 0) {
if (bIsSSL) {
unsigned long error = ERR_get_error();
const char* error_str = ERR_error_string(error, NULL);
LogPrint("tls", "TLS: WARNING: %s: %s():%d - SSL_read err: %s\n",
__FILE__, __func__, __LINE__, error_str);
}
// socket closed gracefully (peer disconnected)
if (!pnode->fDisconnect)
LogPrint("tls", "socket closed (%s)\n", pnode->addr.ToString());
pnode->CloseSocketDisconnect();
} else if (nBytes < 0) {
// error
if (bIsSSL) {
if (nRet != WOLFSSL_ERROR_WANT_READ && nRet != WOLFSSL_ERROR_WANT_WRITE)
{
if (!pnode->fDisconnect)
LogPrintf("TLS: ERROR: SSL_read %s\n", ERR_error_string(nRet, NULL));
if (nBytes > 0) {
if (!pnode->ReceiveMsgBytes(pchBuf, nBytes)) {
pnode->CloseSocketDisconnect();
fKeepReading = false;
}
pnode->nLastRecv = GetTime();
pnode->nRecvBytes += nBytes;
pnode->RecordBytesRecv(nBytes);
nPassBytes += nBytes;
// Keep draining only while the socket likely has more data (we filled the
// buffer, or TLS has buffered decrypted bytes) and within the per-pass cap.
// The flood ceiling is enforced pre-read at the top of the loop.
if (fKeepReading) {
bool fMore = (nBytes == (int)sizeof(pchBuf)) || (bIsSSL && nSSLPending > 0);
if (!fMore || ++nDrainReads >= MAX_DRAIN_READS)
fKeepReading = false;
}
} else if (nBytes == 0) {
if (bIsSSL) {
unsigned long error = ERR_get_error();
const char* error_str = ERR_error_string(error, NULL);
LogPrint("tls", "TLS: WARNING: %s: %s():%d - SSL_read - code[0x%x], err: %s\n",
__FILE__, __func__, __LINE__, nRet, error_str);
LogPrint("tls", "TLS: WARNING: %s: %s():%d - SSL_read err: %s\n",
__FILE__, __func__, __LINE__, error_str);
}
// socket closed gracefully (peer disconnected)
if (!pnode->fDisconnect)
LogPrint("tls", "socket closed (%s)\n", pnode->addr.ToString());
pnode->CloseSocketDisconnect();
fKeepReading = false;
} else if (nBytes < 0) {
// error
if (bIsSSL) {
if (nRet != WOLFSSL_ERROR_WANT_READ && nRet != WOLFSSL_ERROR_WANT_WRITE)
{
if (!pnode->fDisconnect)
LogPrintf("TLS: ERROR: SSL_read %s\n", ERR_error_string(nRet, NULL));
pnode->CloseSocketDisconnect();
unsigned long error = ERR_get_error();
const char* error_str = ERR_error_string(error, NULL);
LogPrint("tls", "TLS: WARNING: %s: %s():%d - SSL_read - code[0x%x], err: %s\n",
__FILE__, __func__, __LINE__, nRet, error_str);
} else {
// preventive measure from exhausting CPU usage
MilliSleep(1); // 1 msec
}
} else {
// preventive measure from exhausting CPU usage
MilliSleep(1); // 1 msec
}
} else {
if (nRet != WSAEWOULDBLOCK && nRet != WSAEMSGSIZE && nRet != WSAEINTR && nRet != WSAEINPROGRESS) {
if (!pnode->fDisconnect)
LogPrintf("TLS: ERROR: socket recv %s\n", NetworkErrorString(nRet));
pnode->CloseSocketDisconnect();
if (nRet != WSAEWOULDBLOCK && nRet != WSAEMSGSIZE && nRet != WSAEINTR && nRet != WSAEINPROGRESS) {
if (!pnode->fDisconnect)
LogPrintf("TLS: ERROR: socket recv %s\n", NetworkErrorString(nRet));
pnode->CloseSocketDisconnect();
}
}
fKeepReading = false;
}
}
}

34
src/hush_nSPV_fullnode.h
View File

@@ -324,7 +324,7 @@ int32_t NSPV_mempoolfuncs(bits256 *satoshisp,int32_t *vindexp,std::vector<uint25
CScript scriptPubKey = tx.vout[tx.vout.size()-1].scriptPubKey;
if ( GetOpReturnData(scriptPubKey,vopret) != 0 )
{
if ( vopret[0] == evalcode && vopret[1] == func )
if ( vopret.size() >= 2 && vopret[0] == evalcode && vopret[1] == func )
{
txids.push_back(hash);
num++;
@@ -417,7 +417,9 @@ int32_t NSPV_remoterpc(struct NSPV_remoterpcresp *ptr,char *json,int n)
{
request.read(json,n);
jreq.parse(request);
strcpy(ptr->method,jreq.strMethod.c_str());
// SECURITY (stack overflow): strMethod is attacker-controlled; bound the copy to the fixed buffer.
strncpy(ptr->method,jreq.strMethod.c_str(),sizeof(ptr->method)-1);
ptr->method[sizeof(ptr->method)-1] = '\0';
len+=sizeof(ptr->method);
std::map<std::string, bool>::iterator it = nspv_remote_commands.find(jreq.strMethod);
if (it==nspv_remote_commands.end())
@@ -438,8 +440,10 @@ int32_t NSPV_remoterpc(struct NSPV_remoterpcresp *ptr,char *json,int n)
{
rpc_result = JSONRPCReplyObj(result, NullUniValue, jreq.id);
response=rpc_result.write();
memcpy(ptr->json,response.c_str(),response.size());
len+=response.size();
// SECURITY (stack overflow): clamp to the fixed json buffer.
size_t rlen = response.size(); if ( rlen > sizeof(ptr->json) ) rlen = sizeof(ptr->json);
memcpy(ptr->json,response.c_str(),rlen);
len+=rlen;
return (len);
}
else throw JSONRPCError(RPC_MISC_ERROR, "Error in executing RPC on remote node");
@@ -459,8 +463,10 @@ int32_t NSPV_remoterpc(struct NSPV_remoterpcresp *ptr,char *json,int n)
rpc_result = JSONRPCReplyObj(NullUniValue,JSONRPCError(RPC_PARSE_ERROR, e.what()), jreq.id);
response=rpc_result.write();
}
memcpy(ptr->json,response.c_str(),response.size());
len+=response.size();
// SECURITY (stack overflow): the error path echoes attacker-controlled jreq.id; clamp to the buffer.
size_t rlen = response.size(); if ( rlen > sizeof(ptr->json) ) rlen = sizeof(ptr->json);
memcpy(ptr->json,response.c_str(),rlen);
len+=rlen;
return (len);
}
@@ -651,10 +657,10 @@ void hush_nSPVreq(CNode *pfrom,std::vector<uint8_t> request) // received a reque
if ( timestamp > pfrom->prevtimes[ind] )
{
struct NSPV_utxosresp U;
if ( len < 64+5 && (request[1] == len-3 || request[1] == len-7 || request[1] == len-11) )
if ( len >= 2 && len < 64+5 && request[1] < 64 && (request[1] == len-3 || request[1] == len-7 || request[1] == len-11) )
{
int32_t skipcount = 0; char coinaddr[64]; uint8_t filter; uint8_t isCC = 0;
memcpy(coinaddr,&request[2],request[1]);
memcpy(coinaddr,&request[2],request[1]); // request[1] < 64 bounds the copy + the terminator write
coinaddr[request[1]] = 0;
if ( request[1] == len-3 )
isCC = (request[len-1] != 0);
@@ -691,10 +697,10 @@ void hush_nSPVreq(CNode *pfrom,std::vector<uint8_t> request) // received a reque
if ( timestamp > pfrom->prevtimes[ind] )
{
struct NSPV_txidsresp T;
if ( len < 64+5 && (request[1] == len-3 || request[1] == len-7 || request[1] == len-11) )
if ( len >= 2 && len < 64+5 && request[1] < 64 && (request[1] == len-3 || request[1] == len-7 || request[1] == len-11) )
{
int32_t skipcount = 0; char coinaddr[64]; uint32_t filter; uint8_t isCC = 0;
memcpy(coinaddr,&request[2],request[1]);
memcpy(coinaddr,&request[2],request[1]); // request[1] < 64 bounds the copy + the terminator write
coinaddr[request[1]] = 0;
if ( request[1] == len-3 )
isCC = (request[len-1] != 0);
@@ -724,7 +730,7 @@ void hush_nSPVreq(CNode *pfrom,std::vector<uint8_t> request) // received a reque
}
NSPV_txidsresp_purge(&T);
}
} else fprintf(stderr,"len.%d req1.%d\n",len,request[1]);
} else fprintf(stderr,"len.%d\n",len);
}
}
else if ( request[0] == NSPV_MEMPOOL )
@@ -732,7 +738,7 @@ void hush_nSPVreq(CNode *pfrom,std::vector<uint8_t> request) // received a reque
if ( timestamp > pfrom->prevtimes[ind] )
{
struct NSPV_mempoolresp M; char coinaddr[64];
if ( len < sizeof(M)+64 )
if ( len >= 40 && len < sizeof(M)+64 ) // SECURITY: lower bound guards the fixed-offset reads request[1..39]
{
int32_t vout; uint256 txid; uint8_t funcid,isCC = 0;
n = 1;
@@ -741,7 +747,7 @@ void hush_nSPVreq(CNode *pfrom,std::vector<uint8_t> request) // received a reque
n += dragon_rwnum(0,&request[n],sizeof(vout),&vout);
n += dragon_rwbignum(0,&request[n],sizeof(txid),(uint8_t *)&txid);
slen = request[n++];
if ( slen < 63 )
if ( slen < 63 && n + slen <= len ) // SECURITY: bound the memcpy source read within request
{
memcpy(coinaddr,&request[n],slen), n += slen;
coinaddr[slen] = 0;
@@ -761,7 +767,7 @@ void hush_nSPVreq(CNode *pfrom,std::vector<uint8_t> request) // received a reque
NSPV_mempoolresp_purge(&M);
}
}
} else fprintf(stderr,"len.%d req1.%d\n",len,request[1]);
} else fprintf(stderr,"len.%d\n",len);
}
}
else if ( request[0] == NSPV_NTZS )

Some files were not shown because too many files have changed in this diff Show More