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

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