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

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