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

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

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

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

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

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

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

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
DanS
2026-07-21 13:59:06 -05:00
parent bf3c33c53a
commit 46693a355a
76 changed files with 829 additions and 1416 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!

237
README.md
View File

@@ -1,31 +1,51 @@
<p align="center">
<img src="doc/hush/hush0.png">
<img src="doc/dragonx/logo_dragonx_128.png" alt="DragonX" width="128">
</p>
<h1 align="center">DragonX</h1>
<p align="center"><b>A fully-private, RandomX CPU-mineable cryptocurrency.</b></p>
<h3>
<h3 align="center">
| Introduction | Install | Compile | FAQ | Documentation |
| :---: | :---: | :---: | :---: | :---: |
| [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).
**DragonX is experimental software.** Use at your own risk, just like Bitcoin.
# Key facts
| | |
| --- | --- |
| Ticker | **DRAGONX** |
| Proof-of-Work | **RandomX** (CPU-mineable) |
| Privacy | fully private from genesis (`ac_private=1`, Sapling active at height 1) |
| Block time | 36 seconds |
| Block reward | 3 DRAGONX, halving every 3,500,000 blocks |
| Max block size | 4 MB |
| RPC port | 21769 |
| P2P port | 18030 |
| Data directory | `~/.hush/DRAGONX` (Linux) |
| Config file | `DRAGONX.conf` |
| Binaries | `dragonxd`, `dragonx-cli`, `dragonx-tx` |
# Fastest way to sync (bootstrap)
@@ -42,86 +62,42 @@ checksums and (once a release key is published) its cryptographic signature, the
you near the chain tip. If you prefer to sync from the network instead, a larger
`-dbcache` (e.g. `-dbcache=2048`) noticeably speeds up the initial block download.
# Banned by GitHub
# Build from source
In working on this release, Duke Leto was suspended from Github, which gave Hush developers
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.
Building uses 3 build processes by default; you need ~2GB of RAM for each.
**Hush is unfinished and highly experimental.** Use at your own risk! Just like Bitcoin.
# Build on Debian or Ubuntu
### 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
@@ -131,10 +107,8 @@ brew install gcc autoconf automake pkgconf libtool cmake curl
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
# clone git repo
git clone https://git.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
@@ -147,77 +121,92 @@ export PATH="$HOME/.cargo/bin:/usr/local/opt/libtool/libexec/gnubin:$PATH"
./build.sh --mac-release -j$(sysctl -n hw.ncpu)
```
# Installing Hush binaries
### Windows (cross-compiled on Linux)
1. [Download the release](https://git.hush.is/hush/hush3/releases) with a .deb file extension.
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

74
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) ###
### [MacDeploy](/contrib/macdeploy)
Scripts and notes for Mac builds.
## 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

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

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.

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:

11
contrib/verifysfbinaries/README.md
View File

@@ -1,5 +1,14 @@
### 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.

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

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.

59
doc/release-process.md
View File

@@ -1,4 +1,4 @@
# Hush Release Process
# DragonX Release Process
## High-Level Philosophy
@@ -6,34 +6,34 @@ Beware of making high-risk changes (such as consensus changes, p2p layer changes
It is best to keep doc/relnotes/README.md up to date as changes and bug fixes are made. It's more work to summarize all changes and bugfixes just before the release.
## Check for changes on master that should be on dev
## Branch model
Often there are trivial changes made directly on master, such as documentation changes. In theory, no code changes should happen on master without being on dev first, but it's better to be safe than sorry. We want the dev branch which undergoes testing to be as close as possible to what the master branch will become, so we don't want to merge dev into master and just assume everything works. So it's best to merge the master branch into dev just before merging the dev branch into master.
Development happens on the `dev` branch. Releases are cut on the default branch, `dragonx`. There is no `master` branch. Code changes should land on `dev` first and undergo testing before being merged into `dragonx`.
To check if the master branch has any changes that the dev branch does not:
## Check for changes on dragonx that should be on dev
Occasionally trivial changes are made directly on the `dragonx` branch, such as documentation changes. In theory, no code changes should happen on `dragonx` without being on `dev` first, but it's better to be safe than sorry. We want the `dev` branch which undergoes testing to be as close as possible to what the `dragonx` branch will become, so we don't want to merge `dev` into `dragonx` and just assume everything works. So it's best to merge the `dragonx` branch into `dev` just before merging the `dev` branch into `dragonx`.
To check if the `dragonx` branch has any changes that the `dev` branch does not:
```
# this assumes you are working with https://git.hush.is/hush/hush3 as your remote
# this assumes you are working with https://git.dragonx.is/DragonX/dragonx as your remote
git checkout dev
git pull # make sure dev is up to date
git checkout master
git pull # make sure master is up to date
git diff dev...master # look at the set of changes which exist in master but not dev
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 master into 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 master
git merge --no-ff dev # using the default commit message is fine
git tag vX.Y.Z # this creates a tag vX.Y.Z on current master, or you can let gitea do it later
git push --tags origin master
git checkout dev
git merge master
git 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
@@ -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

46
doc/shield-coinbase.md
View File

@@ -2,47 +2,61 @@
**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
@@ -50,7 +64,7 @@ The `z_shieldcoinbase` RPC call is an asynchronous call, so you can queue up mul
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!

40
util/README.md
View File

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

4
util/afl/afl-get.sh
View File

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

4
util/afl/afl-getbuildrun.sh
View File

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

2
util/afl/afl-run.sh
View File

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

22
util/build-arm-xcompile.sh
View File

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

49
util/build-debian-package.sh
View File

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

6
util/checkpoints.pl
View File

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

19
util/docker-entrypoint.sh
View File

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

2
util/docker-hush-cli.sh
View File

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

29
util/gen-manpages.sh
View File

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

8
util/gen_scriptpubs.pl
View File

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

4
util/test_randomx
View File

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