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

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.