80 Commits

Author SHA1 Message Date
d0657d38b4 Merge dev into dragonx: DragonX rebrand + security/consensus hardening + IBD speedups
# Conflicts:
#	contrib/init/dragonxd.conf
#	contrib/init/dragonxd.init
#	contrib/init/dragonxd.openrc
#	contrib/init/dragonxd.openrcconf
#	contrib/init/dragonxd.service
2026-07-21 18:58:33 -05:00
8976e020e9 packaging: don't fail the .deb build when optional lintian is absent
build-debian-package.sh warns at startup that lintian is optional, but then
called `lintian -i ...` unconditionally at the end. Under `set -e` that aborted
with exit 127 on hosts without lintian — after the .deb had already been built.
Guard the call with `command -v lintian` so the build exits 0.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-21 16:04:08 -05:00
9c715f68eb depends: fix libsodium build breaking on git.savannah.gnu.org 502
libsodium's autogen.sh fetches config.sub/config.guess from git.savannah.gnu.org
gitweb, which is frequently down (currently returns 502). curl saved the HTML
error page over config.sub, so libsodium's configure died with
"cannot run /bin/bash ./build-aux/config.sub" and the whole build failed.

autoreconf -ivf (run earlier in autogen.sh) already installs valid config.sub/
config.guess from the build host, so set DO_NOT_UPDATE_CONFIG_SCRIPTS=1 (the
script's own opt-out) to skip the fragile download. Validated: the full build
now completes and produces working dragonxd/dragonx-cli/dragonx-tx.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-21 16:02:04 -05:00
e3247d946e cleanup: rebrand residual user-facing "HUSH" strings to DragonX
Sweeps the leftover coin-name strings in RPC help text, RPC output, and log
messages that the currency-unit change didn't cover:

- RPC help: "mining reward amount in HUSH" -> DRAGONX (mining.cpp x2);
  "at least minbal HUSH" -> DRAGONX (rpcwallet.cpp); "the HUSH address" /
  "(string) HUSH address" -> DragonX (rawtransaction.cpp)
- RPC output: the SMART_CHAIN_SYMBOL[0]==0 ? "HUSH" : SYMBOL coin-name fallback
  (crosschain/misc/mining/blockchain) -> "DRAGONX"; the notarizations JSON key
  make_pair("HUSH", ...) -> "DRAGONX"
- Logs: "HUSH blocktime changing", "stopping HUSH HTTP/REST/RPC",
  "HUSH raw magic=" -> DragonX

Left untouched (verified): the 82 "HUSH3"/ishush3 chain-symbol consensus checks;
hush_globals.h CURRENCIES[] price-oracle basket (internal lookup, dead feature
on DragonX); hush.h notarization debug printf; a commented-out cout in main.cpp.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-21 15:37:57 -05:00
ffb753057a cleanup: rebrand currency unit, depends mirrors, seeds; drop Hush-history files
Follow-up to the doc rebrand, addressing the previously out-of-scope legacy:

- Currency unit: strCurrencyUnits (chainparams.cpp) and CURRENCY_UNIT
  (amount.cpp) "HUSH" -> "DRAGONX". Both are display-only (RPC help + metrics);
  no logic comparisons, verified.
- depends mirrors: libsodium/boost/utfcpp fetched from git.hush.is/attachments;
  repointed to canonical upstream (GitHub release / archives.boost.io / GitHub
  tag) with the existing sha256 hashes verified to match those sources.
- Seeds: nodes_main.txt now lists the five node[1-5].dragonx.is IPs (DNS-resolved)
  instead of Hush nodes; regenerated src/chainparamsseeds.h (was compiling Hush
  seed IPs as the fixed fallback); generate-seeds.py header now says DragonX;
  hush_seed_nodes.txt updated to DragonX seeds.
- Deleted Hush-history / wrong-for-DragonX files: contrib/snapshot/ (block-500000
  Hush airdrop, ~10MB), notary_seeds.txt (Hush notaries; DragonX isn't notarized),
  and the Hush emission scripts hush_supply, hush_supply_old, hush_halvings,
  hush_block_subsidy_per_halving (hardcode Hush's 340000/12.5 economics).

Kept: hush_scanner (engine invoked by dragonx_scanner) and the "The Hush
developers" copyright headers (lineage credit).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-21 14:13:31 -05:00
46693a355a docs: rebrand documentation, packaging, and helper scripts to DragonX
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>
2026-07-21 13:59:06 -05:00
bf3c33c53a revert(net): remove header-accept RandomX check; keep nMinimumChainWork + #8
An adversarial re-review found the header-accept RandomX check (b9fdc7981 +
7e9b2c661 header-PoW + d2124a303 defer) to be a persistent source of
consensus-liveness bugs: it derives the RandomX key from the ACTIVE chain
(hush_chainactive), the wrong branch for reorg/side-branch/catch-up headers, so
it repeatedly false-rejected validly-mined headers and DoS(100)-hard-banned
honest peers (IBD-tail catch-up and deep-reorg cases); the defer fix and an
extend-tip fix each addressed one case while leaving/creating others (an
extend-tip variant re-opened an unbounded post-IBD side-branch flood). It only
mitigated a low-harm resource DoS -- forged headers bloat mapBlockIndex memory/
disk but are never SELECTED (nMinimumChainWork) and the full RandomX + target
check still runs at block-connect. Revert to fCheckPOW=0 at header-accept
(original behavior). A comment in AcceptBlockHeader records that any re-attempt
must derive the key from the header's OWN ancestry (pindexPrev->GetAncestor),
never the active chain.

Also hardens two issues the same review found:
- #8 IBD header cap now bounds against the VALIDATED chainActive.Height()
  (attacker-hard) instead of pindexBestHeader, which a forward-extending flood
  advanced in lockstep, defeating the cap.
- opreturn_burn only emits a change output above the dust threshold; a sub-dust
  change made the returned tx non-standard/unrelayable.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 20:24:45 -05:00
5951ee118a fix(net): cap per-peer headers during IBD (header-flood DoS)
Audit #8. The HEADERS handler accepted unbounded headers per peer with no
cumulative cap; during IBD (fCheckPOW=0) a peer could flood cost-free PoW-less
headers into mapBlockIndex/leveldb (never selected -- nMinimumChainWork gates
that -- but still memory/disk growth). Add a per-peer nHeadersProcessed counter
in CNodeState; while IsInitialBlockDownload(), if one peer exceeds
2*max(pindexBestHeader height, checkpoint height) + 200000 headers,
Misbehaving(100) and drop it. The cap is ~2x the chain length, so honest sync
never approaches it; inert post-IBD (the RandomX header check handles forged
headers there).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 18:54:35 -05:00
d2124a3038 fix(pow): defer RandomX header check when key block not yet connected
Follow-on to the post-IBD header-PoW verification (b9fdc7981 + 7e9b2c661).
CheckRandomXSolution derives the RandomX key from the block at
keyHeight = ((height-lag)/interval)*interval, looked up on the ACTIVE chain
(hush_chainactive), so that block must be CONNECTED. When a post-IBD node's
block tip lags the header tip by more than ~one RandomX interval -- the normal
IBD tail, or any node catching up -- the key block is not connected yet, so
GetRandomXKey returns empty. The old code returned an error, making
CheckBlockHeader DoS(100)-ban the honest peer that sent a perfectly valid tip
header we simply could not verify yet.

Observed live: a node finishing a mainnet reindex banned the pool box + seeds
and stalled ~2000 blocks short of the tip. Fix: on an empty key, DEFER (return
true) instead of error -- the header is fully RandomX-verified at block-connect,
where the key block is always connected (blocks connect in order,
keyHeight <= height-lag < the connected tip). Flood protection is preserved for
synced nodes (key present -> real check) and bounded during catch-up by the
per-peer IBD header cap + nMinimumChainWork.

Validated on the live 3.14M-block chain: the affected node caught up the full
~2135-block gap to the tip with zero peer bans (was stalled + banned before).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 18:54:35 -05:00
b5050d06c0 fix(wallet): opreturn_burn return change + widen txfee to CAmount
#10 (HIGH) opreturn_burn selected UTXOs for nAmount+txfee but pushed only the
burn vout and returned - so the entire selected-input surplus was silently paid
as miner fee (e.g. a 500-coin UTXO burning 10 lost ~490). Push a change output
for (inputs - nAmount - txfee). Also widen the int32_t txfee (which truncated
large CAmount fees) to CAmount and MoneyRange-validate.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 11:21:28 -05:00
a520441e3a fix(rpc): guard z_validateaddress against null pwalletMain under -disablewallet
#11 (HIGH) z_validateaddress locked LOCK2(cs_main, pwalletMain->cs_wallet) with
no availability guard; under -disablewallet pwalletMain is NULL, so the member
deref SIGSEGVs the daemon (execute() only catches std::exception). Use the
null-safe LOCK2 idiom already used by sibling RPCs so validation still works
without a wallet.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 11:21:28 -05:00
11704e6023 fix(nspv): add missing length lower-bounds before request/vopret reads
nSPV handlers (gated behind non-default -nspv_msg) read request[1]/vopret[1]
before confirming the peer sent >=2 bytes:

#6 (MEDIUM) NSPV_UTXOS/NSPV_TXIDS evaluated request[1] whenever len<69 (incl
len==1); the 4351d5b73 value-clamp left this lower bound open. The TXIDS/MEMPOOL
else-branch debug prints also read request[1] unconditionally. Add len>=2 guards
/ drop request[1] from the prints.

#7 (LOW) NSPV_MEMPOOL_CCEVALCODE read vopret[1] on a possibly-1-byte vector.
Guard with vopret.size()>=2.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 11:21:28 -05:00
7e9b2c6615 fix(net): verify RandomX at correct height in AcceptBlockHeader + cap locator
header-pow: AcceptBlockHeader passed the caller's reused *ppindex (and a height
derived from it, ==0 for a new header) to CheckBlockHeader instead of the
header's own local pindex + real height. Post-IBD this made
RandomXValidationRequired(0) false, so CheckRandomXSolution returned true WITHOUT
verifying (and the fRandomXVerified short-circuit could fire on an unverified
header) - silently defeating the header-flood PoW gate from b9fdc7981. Resolve
pindexPrev up-front, pass real height (parent+1) and the local (NULL) pindex so
the post-IBD RandomX check actually runs; IBD stays fast (fCheckPOW=0).
Stability-tested: 303 valid headers accepted across a 4-node RandomX net,
0 false rejects / bans.

#9 (MEDIUM) GETBLOCKS/GETHEADERS deserialized an unbounded CBlockLocator.vHave
(~130k hashes) and scanned it linearly under cs_main with no ban - a
message-thread liveness DoS. Add MAX_LOCATOR_SZ=101 + Misbehaving, matching the
adjacent vInv/headers caps.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 11:21:28 -05:00
fc06a43dd7 fix(consensus): bound OP_RETURN opretlen + clamp notary pubkeys array
Defensive-audit findings (adversarially verified + fleet stability-tested):

#4 (CRITICAL) hush_voutupdate trusted an attacker-decoded OP_RETURN length
(opretlen, up to 65535 via OP_PUSHDATA2) with no check against the real script
length, driving up to ~64KB out-of-bounds reads through hush_stateupdate ->
hush_eventadd_opreturn -> hush_kvupdate (persisted to disk, leaked via kvsearch
RPC, reliable crash on block connect). Reject any opret claiming more bytes than
remain in the script, at the single taint source.

#5 (HIGH) notary-ratification loop did memcpy(pubkeys[numvalid++],..) into a
fixed uint8_t[64][33] with no bound; >64 crafted vouts smashed the stack. Clamp
numvalid < 64.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 11:21:28 -05:00
7e99311210 fix(net): enforce nMinimumChainWork in IBD (eclipse / low-work fake-chain protection)
nMinimumChainWork was defined in chainparams but never checked, and IsInitialBlockDownload
decided "synced" from tip timestamp/height alone -- so an eclipsed or bootstrapping node
could be fed a cheap low-work fake chain with recent timestamps and trust it. Reset the
stale mainnet floor (0x281b32ff3198a1 was ABOVE the live chain, would have bricked mainnet)
to the real chainwork at height ~3,100,000, and hold a node in IBD until its tip reaches the
floor. Gated to the DRAGONX symbol so ephemeral assetchains from the same binary are not
trapped in IBD; the check can only keep a node in IBD, never force it out (no false-sync risk).
Complements the header-flood fix (b9fdc7981): that stops invalid-PoW headers off the real tip;
this stops valid-but-cheap fake chains from a fake genesis.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 17:21:12 -05:00
14e3fb6708 fix(wallet): reserve miner fee during z_sendmany note selection
The Sapling note-selection loop stopped once total_value >= nTotalOut, ignoring
the miner fee, so a wallet with notes covering the amount but not amount+fee
selected too few notes and failed later with a spurious "insufficient funds".
Reserve the fee (default or user-supplied) in the selection target.

Leto eb4fc52273.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 16:06:39 -05:00
b9fdc79818 fix(net): verify PoW at header-accept once synced (header-flood DoS)
AcceptBlockHeader called CheckBlockHeader with fCheckPOW=0, so a synced node
stored any well-formed PoW-less header off the tip into mapBlockIndex without
bound (memory/disk DoS). nMinimumChainWork is defined but unenforced and would
not stop tip-siblings anyway (they inherit the tip's chain work). Verify PoW at
header-accept time when not in IBD: forged headers now fail RandomX and the peer
is DoS-banned. IBD keeps fCheckPOW=0 for fast header sync; the full-block
RandomX/target check at connect is unchanged, so no valid header is rejected
(not a consensus-rule change).

fCheckPOW=0 call site is Leto (6a30b40415).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 16:06:39 -05:00
4351d5b733 fix(nspv/wallet): bound nSPV request buffers + fix uninitialized fee / null-deref
hush_nSPV_fullnode.h: bound the REMOTERPC method strcpy and json memcpy to their
fixed buffers (method[64], json[11000]); add lower-length and memcpy-source bounds
to the UTXOS/TXIDS coinaddr[64] copies and the MEMPOOL handler. These paths
deserialize attacker-controlled request bytes -> stack overflow / OOB read. The
nSPV server is opt-in via -nspv_msg (off by default; DragonX uses lightwalletd).

rpc/blockchain.cpp: getchaintxstats null-checks pwalletMain (crash under -disablewallet).
wallet/rpcwallet.cpp: z_sendmany initializes nFee to the default miners fee (was read
uninitialized when no fee param supplied).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 15:56:09 -05:00
4a0a334649 fix(consensus): guard NULL pindex deref in hush_validate_chain (crash DoS)
hush_validate_chain() enters its body when hush_getblockindex(srchash) returns
NULL (via || short-circuit) -- srchash comes from an attacker-controlled
notarization OP_RETURN -- then a debug fprintf dereferenced the NULL pindex.
A block carrying one crafted OP_RETURN tx crashed every synced node on connect,
and crash-looped on restart. Guard the deref: pindex ? GetHeight() : -1.

Introduced by Leto commit 4988ce6f2 ("much debug such wow", 2022).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 15:56:09 -05:00
d52550a6fc fix(consensus): reject Sprout JoinSplits (unverified proof + vpub_new inflation vector)
Sprout JoinSplit proofs/sigs/nullifiers/anchors are never verified (the verifier
arg to CheckTransaction is unused), yet vpub_new is counted as transparent
value-in -- a forged all-zero JoinSplit mints arbitrary value from nothing.
Reproduced on an isolated ac_private=1 chain: 500,000 minted into a z-addr,
accepted + mined + verifychain=true.

Reject any non-coinbase tx carrying a JoinSplit in ContextualCheckTransaction
(covers both mempool acceptance and ConnectBlock). DragonX is Sapling-only from
genesis with zero JoinSplits in its history (mainnet supply audit), so this is
inert on all legitimate traffic and never invalidates a historical block.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 08:10:14 -05:00
d159e72086 feat: chain-level Sapling turnstile (reject blocks that would drive the pool negative)
Belt-and-suspenders inflation/counterfeiting guard on top of the per-tx Sapling
binding signature: ConnectBlock rejects any block whose cumulative Sapling value
pool would go negative (bad-sapling-value-pool-negative) -- a block can never
deshield more value than was ever shielded.

Enforced ONLY when the pool is reliably tracked from genesis (pprev's
nChainSaplingValue is engaged), so it can never false-reject a valid block or
split the chain on nodes that don't track the pool -- those stay dormant.

To make "not reliably tracked" propagate safely, nSaplingValue becomes a
boost::optional<CAmount> (was a plain CAmount). A version-gated dual-read in
CDiskBlockIndex reads records written before SAPLING_VALUE_OPTIONAL_VERSION
(1000350 = v1.0.3) as the legacy raw 8-byte CAmount but DISCARDS the value
(reads boost::none). Records written at >= 1000350 use the optional format and
persist, so from-genesis and reindexed v1.0.3 nodes are durably active across
restarts.

Tested on a 5-node RandomX fleet: old-format DB loads dormant (0 corruption);
from-genesis stays active with correct pool accumulation and 0 false-rejects
across shield/deshield cycles; dormant/active/reindexed nodes converge; a crafted
counterfeit block is rejected (guard fires, no crash); active state persists
across restart (verified at CLIENT_VERSION 1000351 with gate 1000350).

*** MANDATORY UPGRADE STEP (v1.0.3 dev/test nodes) ***
CLIENT_VERSION stays 1000350, and pre-turnstile v1.0.3 builds ALSO stamped
records at 1000350 but in the old plain-8-byte format. Those records now route to
the OPTIONAL read branch and MISPARSE: LoadBlockIndexDB throws and the node
ABORTS on startup (looks like block-DB corruption). Therefore any node that ran an
earlier v1.0.3 (1000350) build MUST have its block data wiped or be -reindexed
before running this build -- do NOT upgrade a 1000350 datadir in place.
Production mainnet (v1.0.2 = CLIENT_VERSION 1000250) is UNAFFECTED: those records
take the legacy branch and read correctly (dormant until reindex). v1.0.3 is
unreleased, so only dev/test datadirs are affected.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-10 01:14:46 +02:00
adf2bacdbd feat: fee-ordered mempool eviction (TrimToSize/Expire) + displacement on admission
This fork never ported Bitcoin's mempool size-limiting: CTxMemPool had no TrimToSize/
Expire and LimitMempoolSize was commented out. An earlier commit added a blunt
DynamicMemoryUsage admission cap that bounded memory but bluntly REJECTED new txs when
full -- so a high-fee tx could not push out a low-fee one. This implements proper
fee-ordered eviction using the per-tx feerate index that already exists (mapTx index 1,
CompareTxMemPoolEntryByFee), with no new index and no descendant-tracking port.

- CTxMemPool::TrimToSize(sizelimit, pvNoSpendsRemaining): while DynamicMemoryUsage() is
  over the limit, evict the lowest-feerate tx (the tail of the feerate index) and its
  in-mempool descendants (recursive remove), re-deriving the tail each iteration.
  Terminates (pool strictly shrinks) and cleans every secondary index via remove().
- CTxMemPool::Expire(time): age-based sweep (entry time older than `time`), for
  LimitMempoolSize's -mempoolexpiry.
- LimitMempoolSize re-enabled (Expire + TrimToSize) and called from ConnectTip on every
  block connect. (No pcoinsTip->Uncache -- CCoinsViewCache has none in this fork; it is
  only a UTXO-cache perf hint.)
- AcceptToMemoryPool now ADDS the tx then TrimToSizes: a higher-fee tx displaces
  lower-fee ones; if this tx was itself the lowest-feerate (evicted), it is rejected
  ("mempool full"). Replaces the blunt reject-when-full cap.
- DEFAULT_MEMPOOL_EXPIRY 1 -> 72 hours (age-Expire is now live; 1h was too aggressive).

Known simplification (documented in code): per-tx feerate, not descendant-aggregate
(CPFP) scoring, and no rollingMinimumFeeRate anti-thrash. Adversarially reviewed
(termination, iterator safety, recursive-lock safety, index cleanup all confirmed) and
runtime-tested on the fleet: pool stays bounded under a 1600-tx flood, verifychain ok,
no hang/crash.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 09:01:06 +02:00
1ec3dbfee3 docs: note BIP39 cross-wallet restore parity is mainnet-only in -mnemonic help
The 24-word seed restores the same wallet in SilentDragonXLite only on mainnet;
testnet/regtest derive a different HD coin_type (per BIP44), so a phrase does not
round-trip across wallets there. Document that in the -mnemonic help so it is not
mistaken for a bug.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 08:10:35 +02:00
ddf6a35680 Rebrand cleanups: getpeerinfo help example + 1.0.3 debian changelog entry
net.cpp: getpeerinfo help address example 18030->21768 and 'Hush server'->'DragonX server'. debian/changelog: prepend 1.0.3 release entry summarizing IBD speedups, witness fix, bulk streaming, seed phrases, assumeutxo removal. NOTE net.cpp change needs a daemon rebuild to surface in runtime RPC help. Staged on 176; not pushed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 08:07:23 +02:00
9cb6424799 Fix dragonx-cli -rpcport help default: 18030 (hush) -> 21769 (DragonX)
The -rpcport help string in bitcoin-cli.cpp hardcoded hush's 18030; the actual default (BaseParams().RPCPort()) is DragonX's 21769, so this was misleading help text only (the CLI already connects to 21769). Set to 21769 and regenerated doc/man/dragonx-cli.1 from the rebuilt binary. NOTE: a separate hush 18030 leftover remains in src/rpc/net.cpp:357 (getpeerinfo help example address) - daemon RPC help, out of scope here. Staged on 176; not pushed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 08:07:23 +02:00
1c6f64b87e Harvest DragonX packaging + legal artifacts from compliant-rebrand
Legal: correct GPLv3 LICENSE (fixes garbled 'GENERAL GENERAL'), AUTHORS DragonX attribution, COPYING. Packaging: man pages REGENERATED from the 1.0.3 binaries via help2man (dragonxd/dragonx-cli/dragonx-tx.1 -> v1.0.3, correct dates), wired into doc/man/Makefile.am (dist_man1_MANS), orphaned hush*.1 removed. Init/openrc/systemd scripts, Debian packaging (control/changelog/copyright rebranded hush->dragonx + install stubs), example confs taken from origin/compliant-rebrand (c05134e77). REMAINING follow-ups: (1) debian/changelog still tops at 1.0.0 - add a 1.0.3 entry; (2) dragonx-cli --help hardcodes rpcport default 18030 (hush) - fix the HelpMessage string in source then regen. Staged on 176 for review; not pushed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 08:07:23 +02:00
a568ab628e tune: raise adaptive dbcache ceiling to 64 GiB on 64-bit hosts
nMaxDbCache capped the adaptive UTXO/db cache (and a manual -dbcache) at 16 GiB, so the
help's "uses most of free RAM" was false above ~20 GB of RAM. Raise the 64-bit ceiling to
64 GiB. The adaptive controller + its RAM reserve still bound actual usage and shrink under
memory pressure, and small hosts are unaffected -- the ceiling only binds once RAM-minus-
reserve exceeds it. The coins cache grows lazily to the target, so nothing is pre-allocated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 06:59:25 +02:00
693d2290e0 fix: release RandomX pre-verify cache at shutdown; tune verify-threads help + -maxblocksintransit ceiling
Three small cleanups to the parallel RandomX pre-verify + P2P-window features:

- Call RandomXValidatorShutdown() in Shutdown() to release the ~256MB shared RandomX
  verify cache. It was allocated on first use but never freed, leaking at every exit.
  Safe here: threadGroup.interrupt_all() (earlier in Shutdown) stops the pre-verify
  worker, and the release takes g_rxvMutex so it can't race a mid-flight verify.
- Clarify the -randomxverifythreads help: the pool only helps NETWORK sync, not reindex
  (reindex runs with a window of 1, so the pool does nothing there).
- Clamp -maxblocksintransit to the real BLOCK_DOWNLOAD_WINDOW (1024) ceiling instead of a
  misleading 4096. Values above the window are a silent no-op (FindNextBlocksToDownload
  never fetches beyond pindexLastCommonBlock + BLOCK_DOWNLOAD_WINDOW); log when clamping.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 06:59:25 +02:00
389c8c7383 fix: cap mempool memory usage (-maxmempool) to bound an OOM DoS
This fork never ported Bitcoin's fee-ordered mempool eviction: CTxMemPool has no
TrimToSize/Expire, and LimitMempoolSize's body + call site are both commented out and
reference an undefined DEFAULT_MAX_MEMPOOL_SIZE. So the mempool had no total-size
ceiling. Together with the just-restored removeExpired() and near-free tx admission, a
peer could flood transactions to exhaust every node's memory (incl. pool/payout nodes).

Add a simple admission cap in AcceptToMemoryPool: once the pool exceeds -maxmempool it
refuses new admissions with DoS(0) (no ban -- a full pool isn't the peer's fault). This
is not fee-ordered eviction (that needs the absent TrimToSize machinery) but it bounds
the footprint; removeExpired() already evicts unmineable expired txs on each block
connect. New DEFAULT_MAX_MEMPOOL_SIZE=300 (MB, Bitcoin's default) is far above DragonX's
normal mempool, so normal operation is unaffected. Reviewed: bytes-vs-bytes comparison,
read under LOCK(pool.cs) on a recursive mutex (no deadlock); only the reorg re-add path
and new sends route through it, and only at 300MB.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 04:58:39 +02:00
4e3c0f8f6f fix: apply real DoS score for invalid headers (Misbehaving nDoS/nDoS was always 1)
In the HEADERS handler, an invalid header scored Misbehaving(id, nDoS/nDoS). Because
the call is guarded by `if (nDoS > 0 ...)`, nDoS/nDoS is always exactly 1, so every
invalid header cost a fixed 1 misbehavior point regardless of severity -- it took
~banscore (default 101) invalid headers to ban a peer instead of 1, effectively
disarming the ban backstop against header spam. The two sibling call sites in the
same handler (tx-accept, block-accept) already pass nDoS directly.

Pass the real nDoS so a genuinely-invalid header (e.g. bad-diffbits, DoS 100) bans in
one message. Cannot over-ban honest peers: every DoS>0 header path is genuinely
invalid consensus, and benign/racy headers (unconnectable prevblock, future block,
clock-skew) either score DoS 0 or never reach Misbehaving (double-guarded by
IsInvalid + nDoS>0 + futureblock==0).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 04:29:54 +02:00
2e54d9fb4d fix: restore removeExpired() mempool scan (was a no-op -> unbounded mempool DoS)
CTxMemPool::removeExpired() declared `transactionsToRemove` and looped over it
without ever populating it -- the mapTx scan that collects expired txs had been
dropped, so it evicted nothing. Expired txs (past nExpiryHeight) can never be mined
yet were never removed, so a peer could wedge them into every node's mempool
permanently at ~zero cost (never mined -> never pay a fee), growing the mempool
without bound: a memory-exhaustion DoS against every node (incl. pool/payout nodes).

Restore the upstream Zcash/Komodo scan: iterate mapTx, collect txs failing
IsExpiredTx(tx, tipHeight) into a separate list, then remove() them (collect-then-
remove avoids iterator invalidation; recursive=true also evicts the now-unmineable
descendants). Also drops an unused CBlockIndex* local.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 04:29:54 +02:00
4238da9bea fix: cap indexed-node block-tree dbcache so adaptive dbcache feeds the UTXO set
With -addressindex/-spentindex, nBlockTreeDBCache was set to 3/4 of nTotalCache. That
rule was sized for the old fixed 512 MiB dbcache default (~384 MiB), but adaptive
dbcache now makes nTotalCache multi-GB, so on indexed pool/explorer nodes ~3/4 of
several GB was diverted to the block-index LevelDB read cache -- far more than it can
use -- while starving the in-memory UTXO set that actually speeds IBD, and that chunk
is not shrinkable by the memory-pressure controller.

Measured on an 8 GiB box with -addressindex: 4420 MiB block-index cache + 1097 MiB
UTXO set, vs 3859 MiB UTXO on a plain node. Cap the index cache at 1 GiB (ample for
the index read cache; tunable) so the adaptive budget flows to the coins cache.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 01:26:30 +02:00
4e67e687d7 perf: verify each block's RandomX solution once, not twice, during sync
RandomX PoW verification is ~84% of block-connect wall time during network IBD, and
CheckBlock was recomputing it TWICE per block: once in CheckBlockHeader and again in
hush_checkPOW (which has no CBlockIndex, so it cannot use the fRandomXVerified dedup
the parallel pre-verify pool relies on). Skip the redundant recompute inside
hush_checkPOW: CheckBlockHeader runs first in CheckBlock and rejects an invalid
solution before hush_checkPOW is reached, so the block is already verified once.
Equihash, PoW-target and notary checks in hush_checkPOW still run.

A scoped guard (ScopedRandomXSkip) SAVES and RESTORES the thread-local
fSkipRandomXValidation, so it neither clobbers the miner's own skip
(TestBlockValidity -> ConnectBlock re-entry, which would otherwise force the ~256MB
inline RandomX alloc the miner deliberately avoids) nor leaks the flag on an exception.

Measured on an isolated RandomX test chain: RandomX verifies per block 2.0 -> 1.03
(~40% faster network sync). The 2x behavior pre-exists in v1.0.2. Consensus-neutral:
RandomXPreVerify.ConsensusEquivalence gtest passes; each block is still verified
exactly once by CheckBlockHeader.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 01:26:30 +02:00
762e25294f fix: guard BuildWitnessCache against an off-active-chain pindex (heap overflow)
BuildWitnessCache sizes its blockCms buffer from pindex->GetHeight() but the
Phase-1 loop walks the active chain (chainActive.Next), terminating only on
pbi==pindex. If a reorg moved pindex off the active chain while the notify
thread lagged (cs_main is released between per-block ChainTip calls) and the new
active tip is taller, the loop never reaches pindex and, once past pindex's
height, writes blockCms[h-startHeight] out of bounds -- a heap overflow.
Rebuilding witnesses for an abandoned block is meaningless anyway, so bail early
when pindex is not on the active chain; cs_main is held for the whole function,
so the check cannot race the loop.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 05:48:39 +02:00
3bb4eb3a5a fix: harden ThreadNotifyWallets IBD read-retry (crash + abandoned disconnects)
Two defects in the IBD ReadBlockFromDisk retry path of ThreadNotifyWallets:

- The connect-loop rebuild indexed recentlyConflicted.first.at(pindex), which
  throws std::out_of_range for a block whose conflict entry was drained in an
  earlier retry cycle. Uncaught under cs_main in the notify boost thread, that
  aborts the node and crash-loops. Use operator[] (empty-list default), i.e.
  best-effort conflict notifications, instead of throwing.

- The disconnect-loop IBD break fell through into the connect loop, which
  advanced pindexLastTip to the new tip and permanently abandoned the pending
  disconnect notifications (leaving wallet witness/anchor state desynced from
  the chain). Add a flag so the break skips the connect loop this cycle and
  truly retries the disconnect on the next one.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 05:48:39 +02:00
7914fca0f2 fix: gate the RandomX PoW-verification skip on the in-index checkpoint
RandomXValidationRequired skipped RandomX verification for blocks below the
static top checkpoint (GetTotalBlocksEstimate), while the fork-rejection guard
uses the in-index checkpoint (GetLastCheckpoint). Once the checkpoint list
extends above the RandomX activation height, that asymmetry opens a gap during
IBD/eclipse in which a peer with no RandomX hashpower can get SHA256-grinded,
RandomX-forged blocks accepted (CheckProofOfWork hashes the header including the
attacker-controlled nSolution). Gate the skip on GetLastCheckpoint()->GetHeight()
so a block is PoW-exempt only when provably below a checkpoint the node has
locked into its index -- the same boundary the fork guard uses. Currently inert
(top checkpoint 2838000 < activation 2838976) but becomes live at the next
checkpoint refresh; the check runs under cs_main and only ever adds verification.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 05:48:39 +02:00
810bd6712f fix: make nCoinCacheUsage std::atomic to close an adaptive-dbcache data race
The scheduled AdjustCoinCacheForMemoryPressure task writes nCoinCacheUsage from
the scheduler thread holding no lock, while cs_main-holding threads
(FlushStateToDisk, VerifyDB) read it -- an unsynchronized read/write of a
non-atomic size_t (C++ UB). Make it std::atomic<size_t>; correct the comment
that incorrectly described the access as lock-free/race-free.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 05:48:39 +02:00
bf5b066a8d fix: evaluate wolfSSL_pending() under cs_hSocket in the recv-drain loop
The bulk-streaming recv-drain loop called wolfSSL_pending(pnode->ssl) after
releasing cs_hSocket, racing with SocketSendData (wolfSSL_write) and
CloseSocketDisconnect (wolfSSL_free) on the same TLS session -- a data race and
potential use-after-free on any TLS peer. Capture the pending-byte count inside
the cs_hSocket-locked block and use the captured value for the drain decision.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 05:48:39 +02:00
19e1ce6f00 fix: self-heal a corrupt/torn notarizations DB instead of aborting startup
A torn or corrupt notarizations (dPoW) leveldb -- a 0-byte log left by a torn
snapshot, or a corrupt MANIFEST -- threw at open and was caught by the block-DB
load try/catch, aborting startup with a misleading Error-opening-block-database
message and forcing a full resync. The notarizations DB is non-essential and
node-regenerable, so on open failure move it aside (notarizations.corrupt,
preserving the data in case the error was transient) and regenerate a fresh one;
if the fresh recreate also fails it still propagates as fatal.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 05:48:39 +02:00
dc45e7d904 Harden ProcessGetData: log+disconnect instead of asserting on block-read failure
The legacy getdata block-serving path asserted whenever ReadBlockFromDisk failed for a block we had advertised (BLOCK_HAVE_DATA). A single transient I/O error or on-disk corruption, triggerable by any peer getdata, crashed the whole node (observed once during bulk-serve load testing on 176). Now log the failure and disconnect that peer so it can re-fetch from another node, matching the bulk GETBLOCKSTREAM serve path which already fails gracefully. Build-verified.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-07 08:08:34 +02:00
1ed468e040 Merge remote-tracking branch 'origin/ibd-wallet-notify-fix' into dev 2026-07-07 07:43:58 +02:00
53b1fe332b Rebrand cleanups: getpeerinfo help example + 1.0.3 debian changelog entry
net.cpp: getpeerinfo help address example 18030->21768 and 'Hush server'->'DragonX server'. debian/changelog: prepend 1.0.3 release entry summarizing IBD speedups, witness fix, bulk streaming, seed phrases, assumeutxo removal. NOTE net.cpp change needs a daemon rebuild to surface in runtime RPC help. Staged on 176; not pushed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-07 06:35:46 +02:00
9c6ccbb726 Fix dragonx-cli -rpcport help default: 18030 (hush) -> 21769 (DragonX)
The -rpcport help string in bitcoin-cli.cpp hardcoded hush's 18030; the actual default (BaseParams().RPCPort()) is DragonX's 21769, so this was misleading help text only (the CLI already connects to 21769). Set to 21769 and regenerated doc/man/dragonx-cli.1 from the rebuilt binary. NOTE: a separate hush 18030 leftover remains in src/rpc/net.cpp:357 (getpeerinfo help example address) - daemon RPC help, out of scope here. Staged on 176; not pushed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-07 06:35:46 +02:00
34432e5848 Harvest DragonX packaging + legal artifacts from compliant-rebrand
Legal: correct GPLv3 LICENSE (fixes garbled 'GENERAL GENERAL'), AUTHORS DragonX attribution, COPYING. Packaging: man pages REGENERATED from the 1.0.3 binaries via help2man (dragonxd/dragonx-cli/dragonx-tx.1 -> v1.0.3, correct dates), wired into doc/man/Makefile.am (dist_man1_MANS), orphaned hush*.1 removed. Init/openrc/systemd scripts, Debian packaging (control/changelog/copyright rebranded hush->dragonx + install stubs), example confs taken from origin/compliant-rebrand (c05134e77). REMAINING follow-ups: (1) debian/changelog still tops at 1.0.0 - add a 1.0.3 entry; (2) dragonx-cli --help hardcodes rpcport default 18030 (hush) - fix the HelpMessage string in source then regen. Staged on 176 for review; not pushed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-07 06:35:46 +02:00
4caf2fc68f Add BIP39 seed phrases (SilentDragonXLite-compatible) and HD transparent keys
Derive transparent (t-addr) keys from the HD seed and add BIP39 mnemonic seed
phrases that are byte-for-byte compatible with SilentDragonXLite, so the same
24 words recover the same shielded and transparent addresses in either wallet.

HD transparent keys:
- Derive t-keys from the seed at m/44'/coin'/0'/0/i (were random CKeys).
- CHDChain gains a version-gated transparent counter; existing wallets load
  unchanged. GenerateNewKey routes through DeriveNewChildKey when enabled
  (-hdtransparent, default on).
- Restore from a seed hex via -hdseed with gap-limit pre-derivation; birthday
  pinned to genesis so the rescan is not clipped.

BIP39 seed phrases:
- Wire the vendored trezor BIP39 lib (src/crypto/bip39) into the build, fix its
  BIP39_WORDS guard, and disable the insecure mnemonic cache.
- Match SDXLite exactly: English wordlist, empty passphrase, PBKDF2 64-byte
  seed, coin type 141, ZIP-32 m/32'/141'/i' and BIP44 m/44'/141'/0'/0/i. Store
  the 32-byte entropy and expand to the 64-byte seed on demand.
- Restore via -mnemonic, create via -usemnemonic, reveal via z_exportmnemonic.

Verified by gtests including a known-answer BIP39 seed vector and z/t address
derivation checks (src/gtest/test_hdtransparent.cpp, test_mnemonic_compat.cpp).
Docs in doc/hd-transparent-keys.md and doc/seed-phrase.md.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-06 01:57:18 -05:00
84aefb5475 Remove assumeutxo / UTXO-snapshot feature
Removes the dumptxoutset RPC, -loadutxosnapshot / -loadutxosnapshotunsafe,
the CCoinsViewDB Dump/LoadSnapshot machinery + CUTXOSnapshotHeader, the
AssumeutxoData chainparams anchor, the LoadSnapshotChainstate activation +
reorg-below-H guard, the persisted assumeutxo-height flag, and the gtest.

Rationale: it duplicated the existing bootstrap (same skip-the-genesis-grind
fast-sync, no speed advantage), its only real edge was a trust model we don't
need for this chain, and it was inert anyway (no published snapshot hash in
chainparams). The -loadutxosnapshot load path adopted an external UTXO set and
bypassed genesis validation, so removing it also drops that attack surface.
Builds clean (no dangling references); the kept IBD speedups (RandomX
pre-verify, adaptive dbcache, tlsmanager) are untouched.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-30 16:42:37 -05:00
1f2b109d95 Add opt-in bulk block streaming (-bulkblocksync)
A single getblockstrm request makes a peer stream a contiguous range of old
blocks back-to-back as ordinary BLOCK messages, amortizing the per-block
round-trip over the whole range instead of the MAX_BLOCKS_IN_TRANSIT_PER_PEER
window. This targets the bandwidth-delay-product ceiling that dominates IBD
from few/high-latency peers below the checkpoint.

Design (off by default; negotiated via a NODE_BULKBLOCKS service bit; the
default getdata IBD path is untouched when disabled):
- protocol: NODE_BULKBLOCKS service bit + getblockstrm/blockstream messages.
- requester: in SendMessages, after FindNextBlocksToDownload, when the first
  needed block is >= BULK_TIP_MARGIN (5000) below the network tip and the peer
  advertises the bit and we are in IBD, request a contiguous range (<=128
  blocks) instead of per-block getdata; mark the range in-flight.
- server: stream the range (caps 128 blocks / 8 MiB; reads outside cs_main;
  per-peer flood throttle), then a trailing blockstream header with the actual
  count sent. Self-suppresses while the server itself is in IBD.
- received blocks ride the existing BLOCK -> ProcessNewBlock path (fully
  validated; checkpoints below 2.84M still apply); the trailing header
  reconciles partial deliveries and the range is freed on a 90s timeout, so a
  partial/withheld/refused batch falls back to the normal path (no leak, no
  permanent gap, no disconnect). In-flight tracking is by literal hash, so a
  reorg cannot orphan range entries.

Hardened against the issues found in two adversarial review passes (drain vs
timeout, partial reconciliation, ownership-guarded frees, one-shot header,
reorg-proof helpers, cs_main hold). Validated end-to-end between two local
v1.0.3 nodes (128/128 and partial serves; height advanced; no errors).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-29 21:22:54 -05:00
78ea2aac5b Add -maxblocksintransit: tunable per-peer block-download window
The per-peer in-flight block window (MAX_BLOCKS_IN_TRANSIT_PER_PEER) was a
hardcoded 16. On a single, high-latency peer during IBD the transfer is
bandwidth-delay-product bound (window / RTT), so with tiny sub-checkpoint
blocks the window, not bandwidth, is the ceiling — measured ~4x throughput
going 16 -> 64 on a 350ms-RTT peer. Make it a runtime flag (default 16,
clamped 1..4096), logged at startup. No behavior change at the default.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-29 21:22:32 -05:00
2419ed7bf7 Fix flaky build: make version-probe pipes SIGPIPE-safe
util/build.sh runs with `set -eu -o pipefail`. `eval "$MAKE" --version | head -n2`
(and the analogous `as --version | head`) can race: head closes the pipe after N
lines, make/as catch SIGPIPE and exit non-zero, pipefail propagates the failure,
and errexit aborts the build before any compilation. Append `|| true` so these
purely-informational version prints can never fail the build.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-29 21:21:29 -05:00
a9b1b4085f Fix automake -lcurl portability lint in Makefile
LIBBITCOIN_SERVER was fed into both EXTRA_LIBRARIES (a list of buildable
library files) and several _LDADD link lines. Embedding the -lcurl linker
flag inside it made automake reject it in the EXTRA_LIBRARIES context
("'-lcurl' is not a standard library name"). Make LIBBITCOIN_SERVER a pure
file and route -lcurl through its own LIBCURL variable, added to the
dragonxd, hush-gtest, and test_bitcoin link lines after libbitcoin_server.a
(whose objects reference curl symbols) so static link order stays correct.

Verified with a clean Windows cross-build (-DCURL_STATICLIB) and a native
Linux build: both link cleanly and the automake lint is gone.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-28 16:58:31 -05:00
f763e3f1e7 Merge ibd-sync-speedups into dev
Parallel RandomX PoW pre-verify, adaptive dbcache, UTXO snapshot, P2P/TLS sync fixes.
2026-06-28 16:11:38 -05:00
f8f13f9027 Merge sapling-witness-rebuild-fix into dev
Sapling witness desync fix + parallel witness-cache rebuild + version bump to 1.0.3.
2026-06-28 16:11:38 -05:00
bf1b4cffe0 Bump version to 1.0.3
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-28 16:04:51 -05:00
82d77344d2 Fix Sapling witness desync and parallelize witness cache rebuild
Wallets upgraded across the 1.0.1->1.0.2 network transition could end up
with note witnesses stuck at a stale height, causing z_sendmany /
z_mergetoaddress to fail to build a valid spend. Root cause was a trio of
issues that let a desynced witnessHeight perpetuate instead of self-healing:

- DecrementNoteWitnesses left witnessRootValidated and the witness deque in
  an asymmetric state on the size<=1 path.
- VerifyAndSetInitialWitness blindly trusted witnessHeight instead of
  validating the cached root against the chain, so a bad height survived.
- UpdatedNoteData copied witnessHeight even when no witnesses were present.
- witnessRootValidated was uninitialized and never serialized, so a garbage
  true value could short-circuit the self-heal.

Fixes:
- Default witnessRootValidated to false (in-memory only; never serialized).
- VerifyAndSetInitialWitness now validates the cached witness root against
  the block's hashFinalSaplingRoot and reseeds on mismatch.
- Symmetric reset of witness state in DecrementNoteWitnesses.
- Guard the witnessHeight copy in UpdatedNoteData behind a non-empty
  witnesses check.
- Defensive majority-root guard in GetSaplingNoteWitnesses.

Also rewrites BuildWitnessCache to rebuild the witness cache in parallel
(per-block commitment extraction + worker pool), cutting a full repair from
~28 min to ~2 min. Tunable via -witnessbuildthreads and -witnessfastrebuild;
output verified byte-identical to the serial path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-28 16:03:23 -05:00
1673cfb6dc IBD/sync speedups: parallel RandomX pre-verify, adaptive dbcache, P2P download fixes
- Parallel RandomX PoW pre-verification pool (CCheckQueue) run ahead of the serial
  connect; consensus-neutral (inline CheckRandomXSolution fallback still verifies
  anything not pre-verified). New -randomxverifythreads (default = -par).
- Adaptive dbcache: default sizes the UTXO/coins cache to most of RAM and shrinks
  under memory pressure, always leaving a reserve free; -dbcache pins a fixed value.
- P2P block download: bounded socket recv-drain loop (tlsmanager); frontier-block
  reassignment to break head-of-line stalls (-blockreassigntimeout); ProcessGetData
  serves a bounded batch of blocks per pass instead of one (fixes the serve-side
  one-block-per-tick throttle that caps download network-wide).
- assumeutxo: dumptxoutset RPC + LoadSnapshot machinery + AssumeutxoData chainparams.
- Signed bootstrap verification (util/bootstrap-dragonx.sh, util/sign-bootstrap.md).
- gtest: RandomX pre-verify consensus-equivalence test + UTXO-snapshot round-trip;
  revived the gtest harness (Makefile.am include fix, Makefile.gtest.include).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-19 12:30:10 -05:00
2f3f320d28 Handle ReadBlockFromDisk failure during IBD gracefully
During Initial Block Download, block data may not be flushed to disk
when the wallet notification thread tries to read it. Instead of
crashing with a fatal error, log a message and retry on the next cycle.
2026-03-27 14:01:50 -05:00
2b011d6ee2 fix windows build 2026-03-19 10:09:18 -05:00
M
d77088c1f2 Fix macOS Sequoia build with GCC 15 and update README
- Update compiler references from gcc-8 to gcc-15 across build system
  (build-mac.sh, darwin.mk, Makefile_custom)
- Use system Rust (rustup) instead of bundled Rust 1.32.0 for librustzcash
  to fix rlib linker incompatibility on macOS Sequoia
- Replace deprecated std::random_shuffle with std::shuffle (net.cpp,
  transaction_builder.cpp, wallet.cpp)
- Fix -std=gnu17 -> -std=gnu++17 for C++ targets (libzcash, libhush)
- Fix nodiscard warning in glibcxx_sanity.cpp
- Replace deprecated OSMemoryBarrier with std::atomic_thread_fence in LevelDB
- Add -Wno-error=deprecated-declarations to CXXFLAGS for third-party headers
- Fix REMAINING_ARGS unbound variable in build.sh
- Add --disable-tests handling to build-mac.sh
- Update README with correct macOS build dependencies and instructions
2026-03-19 09:30:50 -05:00
faa3e925cd fix windows bootstrap script, add mirror fallback 2026-03-17 18:37:40 -05:00
ddd851dc11 Bump version to 1.0.2 2026-03-17 04:11:32 -05:00
752590348b Fix sapling pool persistence and add subsidy/fees to getblock RPC
Lower SPROUT_VALUE_VERSION and SAPLING_VALUE_VERSION constants in
chain.h from upstream Zcash values (1001400/1010100) to 1000000.
When DragonX was rebranded from HUSH3, CLIENT_VERSION was reset from
3.10.5 to 1.0.0, falling below these thresholds. This caused
nSaplingValue to silently skip serialization, so the sapling pool
total reset to 0 on every node restart. Explorer nodes should reindex
once after upgrading.

Add subsidy and fees fields to the getblock RPC response so explorers
can display the correct 3 DRGX block reward separately from fees,
instead of showing the combined coinbase output as the reward.
2026-03-15 16:07:16 -05:00
f0cb958cac Fix fresh sync failure at diff reset height 2838976
Fresh-syncing nodes rejected the on-chain min-diff block at the
RANDOMX_VALIDATION activation height (2838976) because GetNextWorkRequired
computed the expected nBits from the preceding normal-difficulty blocks,
producing 469847994 instead of the on-chain 0x200f0f0f (HUSH_MINDIFF_NBITS).
This caused all seed nodes to be banned with "Incorrect diffbits" and the
node could never sync past that height.

Two changes:

1. GetNextWorkRequired (pow.cpp): Return nProofOfWorkLimit at the exact
   RANDOMX_VALIDATION activation height, matching the on-chain diff reset.

2. ContextualCheckBlockHeader (main.cpp): Raise DragonX daaForkHeight to
   RANDOMX_VALIDATION + 62000, covering the window where nBits was never
   validated (diff reset at 2838976 through the attack at ~2879907).

Tested by invalidating block 2838975 and reconsidering — node re-validated
through the diff reset and attack window, syncing back to tip with zero
bad-diffbits rejections.

Bump version to 1.0.1.
2026-03-12 01:25:21 -05:00
6d56ad8541 Add --linux-compat build option for Ubuntu 20.04 binaries
Build release binaries inside an Ubuntu 20.04 Docker container
to produce executables with lower GLIBC requirements, compatible
with older Linux distributions.

- Add Dockerfile.compat (Ubuntu 20.04 base, full depends rebuild)
- Add .dockerignore to exclude host build artifacts from context
- Add --linux-compat flag to build.sh with Docker build/extract/package
- Strip binaries inside container to avoid root ownership issues
2026-03-10 19:39:55 -05:00
449a00434e test scripts 2026-03-10 17:07:16 -05:00
5cda31b505 update checkpoints 2026-03-09 16:39:00 -05:00
ec517f86e6 update checkpoints again 2026-03-09 16:29:55 -05:00
33e5f646a7 update checkpoints 2026-03-06 18:10:31 -06:00
c1408871cc Fix Windows cross-compilation linker error and gitignore .exe artifacts 2026-03-05 05:22:44 -06:00
0a01ad8bba Fix nBits validation bypass and restore CheckProofOfWork rejection for HACs
Two critical vulnerabilities allowed an attacker to flood the DragonX chain
with minimum-difficulty blocks starting at height 2879907:

1. ContextualCheckBlockHeader only validated nBits for HUSH3 mainnet
   (gated behind `if (ishush3)`), never for HAC/smart chains. An attacker
   could submit blocks claiming any difficulty and the node accepted them.
   Add nBits validation for all non-HUSH3 smart chains, gated above
   daaForkHeight (default 450000) to maintain consensus with early chain
   history that was mined by a different binary.

2. The rebrand commit (85c8d7f7d) commented out the `return false` block
   in CheckProofOfWork that rejects blocks whose hash does not meet the
   claimed target. This made PoW validation a no-op — any hash passed.
   Restore the rejection block and add RANDOMX_VALIDATION height-gated
   logic so blocks after the activation height are always validated even
   during initial block loading.

Vulnerability #1 was inherited from the upstream hush3 codebase.
Vulnerability #2 was introduced by the DragonX rebrand.
2026-03-05 03:09:38 -06:00
85c8d7f7dd Rebrand hush3 to DragonX and share RandomX dataset across mining threads
Minimal rebrand (see compliant-rebrand branch for full rebrand):
- Rename binaries: hushd/hush-cli/hush-tx → dragonxd/dragonx-cli/dragonx-tx
- Default to DRAGONX chain params without -ac_* flags (randomx, blocktime=36, private=1)
- Update configure.ac: AC_INIT([DragonX],[1.0.0])
- Update client version string and user-agent to /DragonX:1.0.0/
- Add chainparams.cpp with DRAGONX network parameters
- Update build.sh, miner.cpp, pow.cpp for DragonX
- Add bootstrap-dragonx.sh utility script
- Update .gitignore for release directory

Share single RandomX dataset across all mining threads:
- Add RandomXDatasetManager with readers-writer lock, reducing RAM from
  ~2GB per thread to ~2GB total plus ~2MB per thread for the VM scratchpad
- Add LogProcessMemory() diagnostic helper for Linux and Windows
2026-03-04 18:42:42 -06:00
d6ba1aed4e Fix RandomX validation exploit: verify nSolution contains valid RandomX hash
- Add CheckRandomXSolution() to validate RandomX PoW in nSolution field
- Add ASSETCHAINS_RANDOMX_VALIDATION activation height per chain
  (DRAGONX: 2838976, TUMIN: 1200, others: height 1)
- Add CRandomXInput serializer for deterministic RandomX hash input
- Fix CheckProofOfWork() to properly reject invalid PoW (was missing
  SMART_CHAIN_SYMBOL check, allowing bypass)
- Call CheckRandomXSolution() in hush_checkPOW and CheckBlockHeader

Without this fix, attackers could submit blocks with invalid RandomX
hashes that passed validation, as CheckProofOfWork returned early
during block loading and the nSolution field was never verified.
2026-03-03 17:28:49 -06:00
Duke
7e1b5701a6 Merge branch 'dev' 2026-03-02 12:10:02 -05:00
Duke
4cbad44688 Update debian changelog 2026-03-02 12:08:19 -05:00
Duke
876c32ed1f Add ac_clearnet to relnotes 2026-03-02 12:00:35 -05:00
Duke
f889ded55e Update release process doc 2026-03-02 11:51:48 -05:00
Duke
07738d75ab Update man pages for 3.10.5 2026-03-02 11:49:27 -05:00
Duke
04916cdf57 update release process doc 2026-03-02 11:43:31 -05:00
Duke
0d139e0bdc Update relnotes and release process doc 2026-03-02 11:41:19 -05:00
Duke
4c86d11b13 Update relnotes 2026-02-28 12:18:38 -05:00
Duke
978d4d739b Ignore configure backups 2026-02-28 12:13:06 -05:00
196 changed files with 9376 additions and 311670 deletions

27
.dockerignore Normal file
View File

@@ -0,0 +1,27 @@
.git
release
depends/built
depends/work
depends/x86_64-unknown-linux-gnu
depends/x86_64-w64-mingw32
src/RandomX/build
src/*.o
src/*.a
src/*.la
src/*.lo
src/.libs
src/.deps
src/univalue/.libs
src/univalue/.deps
src/cc/*.o
src/cc/*.a
src/dragonxd
src/dragonx-cli
src/dragonx-tx
src/dragonxd.exe
src/dragonx-cli.exe
src/dragonx-tx.exe
sapling-output.params
sapling-spend.params
config.status
config.log

10
.gitignore vendored
View File

@@ -28,6 +28,7 @@ build-aux/test-driver
config.log config.log
config.status config.status
configure configure
configure~
libtool libtool
src/config/bitcoin-config.h src/config/bitcoin-config.h
src/config/bitcoin-config.h.in src/config/bitcoin-config.h.in
@@ -166,3 +167,12 @@ REGTEST_7776
src/cc/librogue.so src/cc/librogue.so
src/cc/games/prices src/cc/games/prices
src/cc/games/tetris src/cc/games/tetris
release-linux/
release/
src/dragonxd
src/dragonx-cli
src/dragonx-tx
src/dragonxd.exe
src/dragonx-cli.exe
src/dragonx-tx.exe
doc/relnotes/

View File

@@ -1,3 +1,7 @@
# The DragonX Developers
Dan S https://git.dragonx.is/dan
# The Hush Developers # The Hush Developers
Duke Leto https://git.hush.is/duke https://github.com/leto Duke Leto https://git.hush.is/duke https://github.com/leto

View File

@@ -1,3 +1,4 @@
Copyright (c) 2024-2026 The DragonX developers
Copyright (c) 2018-2025 The Hush developers Copyright (c) 2018-2025 The Hush developers
Copyright (c) 2009-2017 The Bitcoin Core developers Copyright (c) 2009-2017 The Bitcoin Core developers
Copyright (c) 2009-2018 Bitcoin Developers Copyright (c) 2009-2018 Bitcoin Developers

31
Dockerfile.compat Normal file
View File

@@ -0,0 +1,31 @@
FROM ubuntu:20.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y \
build-essential pkg-config libc6-dev m4 g++-multilib autoconf libtool \
ncurses-dev unzip python3 zlib1g-dev wget bsdmainutils automake cmake \
libcurl4-openssl-dev curl git binutils \
&& apt-get clean && rm -rf /var/lib/apt/lists/*
WORKDIR /build
COPY . /build/
# Clean host-built depends and src artifacts to force full rebuild inside container
RUN rm -rf /build/depends/built /build/depends/work \
/build/depends/x86_64-unknown-linux-gnu \
/build/depends/x86_64-w64-mingw32 \
/build/src/RandomX/build \
&& find /build/src -name '*.o' -o -name '*.a' -o -name '*.la' -o -name '*.lo' \
-o -name '*.lai' | xargs rm -f \
&& rm -rf /build/src/univalue/.libs /build/src/univalue/.deps \
&& rm -rf /build/src/.libs /build/src/.deps \
&& rm -rf /build/src/cc/*.o /build/src/cc/*.a \
&& rm -f /build/config.status /build/config.log
RUN cd /build && ./util/build.sh --disable-tests -j$(nproc)
# Strip binaries inside the container so extracted files are already small
RUN strip /build/src/dragonxd /build/src/dragonx-cli /build/src/dragonx-tx
CMD ["/bin/bash"]

View File

@@ -1,8 +1,8 @@
<!--- Remove text and sections that do not apply --> <!--- 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 ### 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) 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: ### Machine specs:
- OS name + version: - OS name + version:
@@ -38,7 +38,7 @@ Run `hushd --version` to find out
### Any extra information that might be useful in the debugging process. ### 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. 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! Beware that usernames and IP addresses and other metadata is definitely in this log file!

26
LICENSE
View File

@@ -1,4 +1,4 @@
GENERAL GENERAL PUBLIC LICENSE GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007 Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
@@ -7,15 +7,15 @@
Preamble Preamble
The GENERAL General Public License is a free, copyleft license for The GNU General Public License is a free, copyleft license for
software and other kinds of works. software and other kinds of works.
The licenses for most software and other practical works are designed The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast, to take away your freedom to share and change the works. By contrast,
the GENERAL General Public License is intended to guarantee your freedom to the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free share and change all versions of a program--to make sure it remains free
software for all its users. We, the Free Software Foundation, use the software for all its users. We, the Free Software Foundation, use the
GENERAL General Public License for most of our software; it applies also to GNU General Public License for most of our software; it applies also to
any other work released this way by its authors. You can apply it to any other work released this way by its authors. You can apply it to
your programs, too. your programs, too.
@@ -37,7 +37,7 @@ freedoms that you received. You must make sure that they, too, receive
or can get the source code. And you must show them these terms so they or can get the source code. And you must show them these terms so they
know their rights. know their rights.
Developers that use the GENERAL GPL protect your rights with two steps: Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License (1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it. giving you legal permission to copy, distribute and/or modify it.
@@ -72,7 +72,7 @@ modification follow.
0. Definitions. 0. Definitions.
"This License" refers to version 3 of the GENERAL General Public License. "This License" refers to version 3 of the GNU General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of "Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks. works, such as semiconductor masks.
@@ -549,35 +549,35 @@ to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program. License would be to refrain entirely from conveying the Program.
13. Use with the GENERAL Affero General Public License. 13. Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed permission to link or combine any covered work with a work licensed
under version 3 of the GENERAL Affero General Public License into a single under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work, License will continue to apply to the part which is the covered work,
but the special requirements of the GENERAL Affero General Public License, but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the section 13, concerning interaction through a network will apply to the
combination as such. combination as such.
14. Revised Versions of this License. 14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of The Free Software Foundation may publish revised and/or new versions of
the GENERAL General Public License from time to time. Such new versions will the GNU General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to be similar in spirit to the present version, but may differ in detail to
address new problems or concerns. address new problems or concerns.
Each version is given a distinguishing version number. If the Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GENERAL General Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the Foundation. If the Program does not specify a version number of the
GENERAL General Public License, you may choose any version ever published GNU General Public License, you may choose any version ever published
by the Free Software Foundation. by the Free Software Foundation.
If the Program specifies that a proxy can decide which future If the Program specifies that a proxy can decide which future
versions of the GENERAL General Public License can be used, that proxy's versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you public statement of acceptance of a version permanently authorizes you
to choose that version for the Program. to choose that version for the Program.

265
README.md
View File

@@ -1,195 +1,212 @@
<p align="center"> <p align="center">
<img src="doc/hush/hush0.png"> <img src="doc/dragonx/logo_dragonx_128.png" alt="DragonX" width="128">
</p> </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 | | Introduction | Build | Run | Mine |
| :---: | :---: | :---: | :---: | :---: | | :---: | :---: | :---: | :---: |
| [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) | [What is DragonX?](#what-is-dragonx) | [Build from source](#build-from-source) | [Run a node](#running-a-node) | [CPU mining](#cpu-mining-randomx) |
| [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) | [Key facts](#key-facts) | [Install a release](#installing-dragonx-binaries) | [Fastest sync](#fastest-way-to-sync-bootstrap) | [Wallets](#wallets) |
| [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)
</h3> </h3>
# What is Hush? # What is DragonX?
Hush implements Extreme Privacy via blockchain tech. We have our own DragonX implements extreme privacy via blockchain technology. It is **private from
genesis block. We are not a chain fork (copy) of another coin. We are based on genesis**: every ordinary transaction is shielded (`z2z`), so your transaction metadata
Bitcoin code, with sophisticated zero-knowledge mathematics added for privacy. stays private. DragonX is based on Bitcoin code with Zcash's zero-knowledge Sapling
This keeps your transaction metadata private! 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 This software is the DragonX full node and command-line client. It downloads and stores the
the entire history of Hush transactions; depending on the speed of your entire history of DragonX transactions; depending on your computer and network connection
computer and network connection, it will likely take a few hours at least, but this can take a while, so most users start from the [bootstrap snapshot](#fastest-way-to-sync-bootstrap).
some people report full nodes syncing in less than 1.5 hours.
# Banned by GitHub **DragonX is experimental software.** Use at your own risk, just like Bitcoin.
In working on this release, Duke Leto was suspended from Github, which gave Hush developers # Key facts
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.
**Hush is unfinished and highly experimental.** Use at your own risk! Just like Bitcoin. | | |
| --- | --- |
| Ticker | **DRAGONX** |
| Proof-of-Work | **RandomX** (CPU-mineable) |
| Privacy | fully private from genesis (`ac_private=1`, Sapling active at height 1) |
| Block time | 36 seconds |
| Block reward | 3 DRAGONX, halving every 3,500,000 blocks |
| Max block size | 4 MB |
| RPC port | 21769 |
| P2P port | 18030 |
| Data directory | `~/.hush/DRAGONX` (Linux) |
| Config file | `DRAGONX.conf` |
| Binaries | `dragonxd`, `dragonx-cli`, `dragonx-tx` |
# Build on Debian or Ubuntu # Fastest way to sync (bootstrap)
The quickest way to get a fully-synced node is the signed bootstrap snapshot, which
installs a pre-built blockchain so you skip re-validating the whole chain from genesis:
```sh
# Stop dragonxd first if it is running, then:
./util/bootstrap-dragonx.sh
```
The script preserves your `wallet.dat` and `DRAGONX.conf`, verifies the download's
checksums and (once a release key is published) its cryptographic signature, then starts
you near the chain tip. If you prefer to sync from the network instead, a larger
`-dbcache` (e.g. `-dbcache=2048`) noticeably speeds up the initial block download.
# Build from source
Building uses 3 build processes by default; you need ~2GB of RAM for each.
### Debian or Ubuntu
```sh ```sh
# install build dependencies
sudo apt-get install build-essential pkg-config libc6-dev m4 g++-multilib \ sudo apt-get install build-essential pkg-config libc6-dev m4 g++-multilib \
autoconf libtool ncurses-dev unzip git zlib1g-dev wget \ autoconf libtool ncurses-dev unzip git zlib1g-dev wget \
bsdmainutils automake curl unzip nano libsodium-dev cmake bsdmainutils automake curl unzip nano libsodium-dev cmake
# clone git repo git clone https://git.dragonx.is/DragonX/dragonx
git clone https://git.hush.is/hush/hush3 cd dragonx
cd hush3
# Build
# This uses 3 build processes, you need 2GB of RAM for each.
./build.sh -j3 ./build.sh -j3
``` ```
Video Tutorial: https://videos.hush.is/videos/how-to-install-on-linux
# Build on Arch ### Arch
```sh ```sh
# install build dependencies
sudo pacman -S gcc libsodium lib32-zlib unzip wget git python rust curl autoconf cmake sudo pacman -S gcc libsodium lib32-zlib unzip wget git python rust curl autoconf cmake
# clone git repo git clone https://git.dragonx.is/DragonX/dragonx
git clone https://git.hush.is/hush/hush3 cd dragonx
cd hush3
# Build
# This uses 3 build processes, you need 2GB of RAM for each.
./build.sh -j3 ./build.sh -j3
``` ```
# Build on Fedora ### Fedora
```sh ```sh
# install build dependencies
sudo dnf install make automake gcc gcc-c++ kernel-devel cmake libtool ncurses-devel patch -y sudo dnf install make automake gcc gcc-c++ kernel-devel cmake libtool ncurses-devel patch -y
# clone git repo git clone https://git.dragonx.is/DragonX/dragonx
git clone https://git.hush.is/hush/hush3 cd dragonx
cd hush3
# Build
# This uses 3 build processes, you need 2GB of RAM for each.
./build.sh -j3 ./build.sh -j3
``` ```
# Install on Windows 10 ### macOS
Video Tutorial: https://videos.hush.is/videos/how-to-install-on-windows Install Xcode Command Line Tools and [Homebrew](https://brew.sh/), then:
# Install on ARM Architecture ```sh
xcode-select --install
brew install gcc autoconf automake pkgconf libtool cmake curl
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. # Install Rust (needed for librustzcash on macOS Sequoia+)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
1. [Download the latest Debian package with the AARCH64 designation from the releases page](https://git.hush.is/hush/hush3/releases). git clone https://git.dragonx.is/DragonX/dragonx
1. Install the Debian package, substituting "VERSION-NUMBER" for the version you have downloaded: `sudo dpkg -i hush-VERSION-NUMBER-aarch64.deb`. cd dragonx
1. Run with: `hushd`. # Make sure libtool gnubin and cargo are on PATH
export PATH="$HOME/.cargo/bin:/usr/local/opt/libtool/libexec/gnubin:$PATH"
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
```
sudo port update
sudo port upgrade outdated
sudo port install qt5
# 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.
./build.sh -j3 ./build.sh -j3
``` ```
# Installing Hush binaries For a release build:
1. [Download the release](https://git.hush.is/hush/hush3/releases) with a .deb file extension. ```sh
1. Install the Debian package, substituting "VERSION-NUMBER" for the version you have downloaded: `sudo dpkg -i hush-VERSION-NUMBER-amd64.deb`. export PATH="$HOME/.cargo/bin:/usr/local/opt/libtool/libexec/gnubin:$PATH"
1. Run with: `hushd`. ./build.sh --mac-release -j$(sysctl -n hw.ncpu)
```
# Windows (cross-compiled on Linux) ### Windows (cross-compiled on Linux)
Get dependencies:
```ssh ```sh
sudo apt-get install \ sudo apt-get install \
build-essential pkg-config libc6-dev m4 g++-multilib libdb++-dev \ build-essential pkg-config libc6-dev m4 g++-multilib libdb++-dev \
autoconf libtool ncurses-dev unzip git zip \ autoconf libtool ncurses-dev unzip git zip \
zlib1g-dev wget bsdmainutils automake mingw-w64 cmake libsodium-dev 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 ```sh
# pull ./src/dragonxd
git clone https://git.hush.is/hush/hush3
cd hush3
# Build
./util/build-win.sh -j$(nproc)
# Run a HUSH node
./src/hushd
``` ```
# 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: ```sh
* [explorer.hush.is](https://explorer.hush.is) ./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> # CPU mining (RandomX)
* [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.
# 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 # Wallets
1. https://tradeogre.com/exchange/BTC-HUSH
# 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`: DragonX light and mobile wallets use BIP39 seed phrases that are compatible with the full
- https://git.hush.is/hush/hush3/issues node — see [doc/seed-phrase.md](doc/seed-phrase.md).
- https://git.hush.is/hush/SilentDragon/issues
- https://git.hush.is/hush/SilentDragonLite/issues
![Logo](doc/hush/earnhush.png "Hush Bounty") # Support and links
# Support and Socials * Website: https://dragonx.is
* Source code: https://git.dragonx.is/DragonX
* Telegram: [https://hush.is/tg](https://hush.is/tg) * Block explorer: https://explorer.dragonx.is
* Matrix: [https://hush.is/matrix](https://hush.is/matrix) * Issues / bounties: https://git.dragonx.is/DragonX/dragonx/issues
* Twitter: [https://hush.is/twitter](https://hush.is/twitter) * Telegram: https://dragonx.is/tg
* PeerTube [https://hush.is/peertube](https://hush.is/peertube) * Matrix: https://dragonx.is/matrix
* Twitter / X: https://twitter.com/DragonXchain
# License # License

204
build.sh
View File

@@ -1,19 +1,211 @@
#!/usr/bin/env bash #!/usr/bin/env bash
# Copyright (c) 2016-2024 The Hush developers # Copyright (c) 2016-2024 The Hush developers
# Copyright (c) 2024-2026 The DragonX developers
# Distributed under the GPLv3 software license, see the accompanying # Distributed under the GPLv3 software license, see the accompanying
# file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
set -eu -o pipefail set -eu -o pipefail
# run correct build script for detected OS VERSION="1.0.3"
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
RELEASE_DIR="$SCRIPT_DIR/release"
# Parse release flags
BUILD_LINUX_RELEASE=0
BUILD_WIN_RELEASE=0
BUILD_MAC_RELEASE=0
BUILD_LINUX_COMPAT=0
REMAINING_ARGS=()
for arg in "$@"; do
case "$arg" in
--linux-release)
BUILD_LINUX_RELEASE=1
;;
--linux-compat)
BUILD_LINUX_COMPAT=1
;;
--win-release)
BUILD_WIN_RELEASE=1
;;
--mac-release)
BUILD_MAC_RELEASE=1
;;
--all-release)
BUILD_LINUX_RELEASE=1
BUILD_WIN_RELEASE=1
BUILD_MAC_RELEASE=1
;;
*)
REMAINING_ARGS+=("$arg")
;;
esac
done
# Clean artifacts that may conflict between platform builds
clean_for_platform() {
local platform="$1"
echo "Cleaning build artifacts for $platform build..."
# Use make clean if Makefile exists (safer than manual deletion)
if [ -f src/Makefile ]; then
make -C src clean 2>/dev/null || true
fi
# Remove final binaries
if [ -d src ]; then
rm -f src/dragonxd src/dragonx-cli src/dragonx-tx 2>/dev/null || true
rm -f src/dragonxd.exe src/dragonx-cli.exe src/dragonx-tx.exe 2>/dev/null || true
rm -f src/hushd src/hush-cli src/hush-tx 2>/dev/null || true
rm -f src/hushd.exe src/hush-cli.exe src/hush-tx.exe 2>/dev/null || true
fi
# Clean RandomX build for cross-platform compatibility
rm -rf src/RandomX/build 2>/dev/null || true
# Clean cryptoconditions
rm -rf src/cc/*.o src/cc/*.a 2>/dev/null || true
# Clean config cache (forces reconfigure for cross-platform)
rm -f config.status config.log 2>/dev/null || true
echo "Clean complete for $platform"
}
# Package release for a platform
package_release() {
local platform="$1"
local release_subdir="$RELEASE_DIR/dragonx-$VERSION-$platform"
echo "Packaging release for $platform..."
mkdir -p "$release_subdir"
# Copy bootstrap script (platform-appropriate)
if [ "$platform" = "win64" ]; then
cp "$SCRIPT_DIR/util/bootstrap-dragonx.bat" "$release_subdir/"
else
cp "$SCRIPT_DIR/util/bootstrap-dragonx.sh" "$release_subdir/"
fi
# Copy common files
cp "$SCRIPT_DIR/contrib/asmap/asmap.dat" "$release_subdir/" 2>/dev/null || true
cp "$SCRIPT_DIR/sapling-output.params" "$release_subdir/" 2>/dev/null || true
cp "$SCRIPT_DIR/sapling-spend.params" "$release_subdir/" 2>/dev/null || true
case "$platform" in
linux-amd64)
cp "$SCRIPT_DIR/src/dragonxd" "$release_subdir/"
cp "$SCRIPT_DIR/src/dragonx-cli" "$release_subdir/"
cp "$SCRIPT_DIR/src/dragonx-tx" "$release_subdir/"
strip "$release_subdir/dragonxd" "$release_subdir/dragonx-cli" "$release_subdir/dragonx-tx"
;;
win64)
cp "$SCRIPT_DIR/src/dragonxd.exe" "$release_subdir/"
cp "$SCRIPT_DIR/src/dragonx-cli.exe" "$release_subdir/"
cp "$SCRIPT_DIR/src/dragonx-tx.exe" "$release_subdir/"
x86_64-w64-mingw32-strip "$release_subdir/"*.exe 2>/dev/null || strip "$release_subdir/"*.exe 2>/dev/null || true
;;
macos)
cp "$SCRIPT_DIR/src/dragonxd" "$release_subdir/"
cp "$SCRIPT_DIR/src/dragonx-cli" "$release_subdir/"
cp "$SCRIPT_DIR/src/dragonx-tx" "$release_subdir/"
strip "$release_subdir/dragonxd" "$release_subdir/dragonx-cli" "$release_subdir/dragonx-tx" 2>/dev/null || true
;;
esac
echo "Release packaged: $release_subdir"
ls -la "$release_subdir"
}
# Handle release builds
if [ $BUILD_LINUX_COMPAT -eq 1 ] || [ $BUILD_LINUX_RELEASE -eq 1 ] || [ $BUILD_WIN_RELEASE -eq 1 ] || [ $BUILD_MAC_RELEASE -eq 1 ]; then
mkdir -p "$RELEASE_DIR"
if [ $BUILD_LINUX_COMPAT -eq 1 ]; then
echo "=== Building Linux compat release (Ubuntu 20.04 via Docker) ==="
if ! command -v docker &>/dev/null; then
echo "Error: docker is required for --linux-compat builds"
exit 1
fi
# Use sudo for docker if the user isn't in the docker group
DOCKER_CMD="docker"
if ! docker info &>/dev/null 2>&1; then
echo "Note: Using sudo for docker (add yourself to the docker group to avoid this)"
DOCKER_CMD="sudo docker"
fi
DOCKER_IMAGE="dragonx-compat-builder"
COMPAT_PLATFORM="linux-amd64-ubuntu2004"
COMPAT_RELEASE_DIR="$RELEASE_DIR/dragonx-$VERSION-$COMPAT_PLATFORM"
echo "Building Docker image (Ubuntu 20.04 base)..."
$DOCKER_CMD build -f Dockerfile.compat -t "$DOCKER_IMAGE" .
echo "Extracting binaries from Docker image..."
CONTAINER_ID=$($DOCKER_CMD create "$DOCKER_IMAGE")
mkdir -p "$COMPAT_RELEASE_DIR"
for bin in dragonxd dragonx-cli dragonx-tx; do
$DOCKER_CMD cp "$CONTAINER_ID:/build/src/$bin" "$COMPAT_RELEASE_DIR/$bin"
done
$DOCKER_CMD rm "$CONTAINER_ID" >/dev/null
# Fix ownership (docker cp creates root-owned files)
# Binaries are already stripped inside the Docker container
if [ "$(stat -c '%U' "$COMPAT_RELEASE_DIR/dragonxd")" = "root" ]; then
sudo chown "$(id -u):$(id -g)" "$COMPAT_RELEASE_DIR"/dragonx*
fi
# Copy common files
cp "$SCRIPT_DIR/util/bootstrap-dragonx.sh" "$COMPAT_RELEASE_DIR/"
cp "$SCRIPT_DIR/contrib/asmap/asmap.dat" "$COMPAT_RELEASE_DIR/" 2>/dev/null || true
cp "$SCRIPT_DIR/sapling-output.params" "$COMPAT_RELEASE_DIR/" 2>/dev/null || true
cp "$SCRIPT_DIR/sapling-spend.params" "$COMPAT_RELEASE_DIR/" 2>/dev/null || true
echo "Compat release packaged: $COMPAT_RELEASE_DIR"
ls -la "$COMPAT_RELEASE_DIR"
# Show glibc version requirement
echo ""
echo "Binary compatibility info:"
objdump -T "$COMPAT_RELEASE_DIR/dragonxd" | grep -oP 'GLIBC_\d+\.\d+' | sort -uV | tail -1 && echo "(max GLIBC version required)"
fi
if [ $BUILD_LINUX_RELEASE -eq 1 ]; then
echo "=== Building Linux release ==="
clean_for_platform linux
./util/build.sh --disable-tests ${REMAINING_ARGS[@]+"${REMAINING_ARGS[@]}"}
package_release linux-amd64
fi
if [ $BUILD_WIN_RELEASE -eq 1 ]; then
echo "=== Building Windows release ==="
clean_for_platform windows
./util/build-win.sh --disable-tests ${REMAINING_ARGS[@]+"${REMAINING_ARGS[@]}"}
package_release win64
fi
if [ $BUILD_MAC_RELEASE -eq 1 ]; then
echo "=== Building macOS release ==="
clean_for_platform macos
./util/build-mac.sh --disable-tests ${REMAINING_ARGS[@]+"${REMAINING_ARGS[@]}"}
package_release macos
fi
echo ""
echo "=== Release builds complete ==="
ls -la "$RELEASE_DIR"/
exit 0
fi
# Standard build (auto-detect OS)
if [[ "$OSTYPE" == "linux-gnu"* ]]; then if [[ "$OSTYPE" == "linux-gnu"* ]]; then
./util/build.sh --disable-tests $@ ./util/build.sh --disable-tests ${REMAINING_ARGS[@]+"${REMAINING_ARGS[@]}"}
elif [[ "$OSTYPE" == "darwin"* ]]; then elif [[ "$OSTYPE" == "darwin"* ]]; then
./util/build-mac.sh --disable-tests $@ ./util/build-mac.sh --disable-tests ${REMAINING_ARGS[@]+"${REMAINING_ARGS[@]}"}
elif [[ "$OSTYPE" == "msys"* ]]; then elif [[ "$OSTYPE" == "msys"* ]]; then
./util/build-win.sh --disable-tests $@ ./util/build-win.sh --disable-tests ${REMAINING_ARGS[@]+"${REMAINING_ARGS[@]}"}
#elif [[ "$OSTYPE" == "freebsd"* ]]; then
# placeholder
else else
echo "Unable to detect your OS. What are you using?" echo "Unable to detect your OS. What are you using?"
fi fi

View File

@@ -1,23 +1,23 @@
dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N) dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N)
AC_PREREQ([2.60]) AC_PREREQ([2.60])
define(_CLIENT_VERSION_MAJOR, 3) define(_CLIENT_VERSION_MAJOR, 1)
dnl Must be kept in sync with src/clientversion.h , ugh! dnl Must be kept in sync with src/clientversion.h , ugh!
define(_CLIENT_VERSION_MINOR, 10) define(_CLIENT_VERSION_MINOR, 0)
define(_CLIENT_VERSION_REVISION, 5) define(_CLIENT_VERSION_REVISION, 3)
define(_CLIENT_VERSION_BUILD, 50) define(_CLIENT_VERSION_BUILD, 50)
define(_ZC_BUILD_VAL, m4_if(m4_eval(_CLIENT_VERSION_BUILD < 25), 1, m4_incr(_CLIENT_VERSION_BUILD), m4_eval(_CLIENT_VERSION_BUILD < 50), 1, m4_eval(_CLIENT_VERSION_BUILD - 24), m4_eval(_CLIENT_VERSION_BUILD == 50), 1, , m4_eval(_CLIENT_VERSION_BUILD - 50))) define(_ZC_BUILD_VAL, m4_if(m4_eval(_CLIENT_VERSION_BUILD < 25), 1, m4_incr(_CLIENT_VERSION_BUILD), m4_eval(_CLIENT_VERSION_BUILD < 50), 1, m4_eval(_CLIENT_VERSION_BUILD - 24), m4_eval(_CLIENT_VERSION_BUILD == 50), 1, , m4_eval(_CLIENT_VERSION_BUILD - 50)))
define(_CLIENT_VERSION_SUFFIX, m4_if(m4_eval(_CLIENT_VERSION_BUILD < 25), 1, _CLIENT_VERSION_REVISION-beta$1, m4_eval(_CLIENT_VERSION_BUILD < 50), 1, _CLIENT_VERSION_REVISION-rc$1, m4_eval(_CLIENT_VERSION_BUILD == 50), 1, _CLIENT_VERSION_REVISION, _CLIENT_VERSION_REVISION-$1))) define(_CLIENT_VERSION_SUFFIX, m4_if(m4_eval(_CLIENT_VERSION_BUILD < 25), 1, _CLIENT_VERSION_REVISION-beta$1, m4_eval(_CLIENT_VERSION_BUILD < 50), 1, _CLIENT_VERSION_REVISION-rc$1, m4_eval(_CLIENT_VERSION_BUILD == 50), 1, _CLIENT_VERSION_REVISION, _CLIENT_VERSION_REVISION-$1)))
define(_CLIENT_VERSION_IS_RELEASE, true) define(_CLIENT_VERSION_IS_RELEASE, true)
define(_COPYRIGHT_YEAR, 2026) define(_COPYRIGHT_YEAR, 2026)
AC_INIT([Hush],[_CLIENT_VERSION_MAJOR._CLIENT_VERSION_MINOR._CLIENT_VERSION_SUFFIX(_ZC_BUILD_VAL)],[https://git.hush.is/hush/hush3],[hush]) AC_INIT([DragonX],[_CLIENT_VERSION_MAJOR._CLIENT_VERSION_MINOR._CLIENT_VERSION_SUFFIX(_ZC_BUILD_VAL)],[https://git.dragonx.is/DragonX/dragonx],[dragonx])
AC_CONFIG_SRCDIR([src/main.cpp]) AC_CONFIG_SRCDIR([src/main.cpp])
AC_CONFIG_HEADERS([src/config/bitcoin-config.h]) AC_CONFIG_HEADERS([src/config/bitcoin-config.h])
AC_CONFIG_AUX_DIR([build-aux]) AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_MACRO_DIR([build-aux/m4]) AC_CONFIG_MACRO_DIR([build-aux/m4])
BITCOIN_DAEMON_NAME=hushd BITCOIN_DAEMON_NAME=dragonxd
BITCOIN_CLI_NAME=hush-cli BITCOIN_CLI_NAME=dragonx-cli
BITCOIN_TX_NAME=hush-tx BITCOIN_TX_NAME=dragonx-tx
dnl Unless the user specified ARFLAGS, force it to be cr dnl Unless the user specified ARFLAGS, force it to be cr
AC_ARG_VAR(ARFLAGS, [Flags for the archiver, defaults to <cr> if not set]) AC_ARG_VAR(ARFLAGS, [Flags for the archiver, defaults to <cr> if not set])

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! # DragonX Tools
Please fix bugs and report things you find.
# Hush Tools
## block\_time.pl ## block\_time.pl
Estimate when a Hush block will happen. Estimate when a DragonX block will happen.
Example: Example:
@@ -19,65 +17,49 @@ Example:
## gen-zaddrs.pl ## gen-zaddrs.pl
Generate zaddrs in bulk, by default 50 at a time. Prints out a zaddr one per line. 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: Example:
./contrib/gen-zaddrs.pl # generate 50 zaddrs ./contrib/gen-zaddrs.pl # generate 50 zaddrs
./contrib/gen-zaddrs.pl 500 # generate 500 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 ## Repository Tools
### [Developer tools](/contrib/devtools) ### ### [Verify-Commits](/contrib/verify-commits)
Specific tools for developers working on this repository. Tool to verify that merge commits were signed by a developer.
Contains the script `github-merge.sh` for merging github pull requests securely and signing them using GPG.
### [Verify-Commits](/contrib/verify-commits) ### ### [Linearize](/contrib/linearize)
Tool to verify that every merge commit was signed by a developer using the above `github-merge.sh` script.
### [Linearize](/contrib/linearize) ###
Construct a linear, no-fork, best version of the blockchain. 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 seed node array that is compiled into the client.
### [Seeds](/contrib/seeds) ###
Utility to generate the pnSeed[] array that is compiled into the client.
## Build Tools and Keys ## Build Tools and Keys
### [Debian](/contrib/debian) ### ### [Debian](/contrib/debian)
Contains files used to package bitcoind/bitcoin-qt Contains files used to package dragonxd for Debian-based Linux systems.
for Debian-based Linux systems. If you compile bitcoind/bitcoin-qt yourself, there are some useful files here.
### [Gitian-descriptors](/contrib/gitian-descriptors) ### ### [Gitian-descriptors](/contrib/gitian-descriptors)
Gavin's notes on getting gitian builds up and running using KVM. 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) ### [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. Scripts and notes for Mac builds.
## Test and Verify Tools ## Test and Verify Tools
### [TestGen](/contrib/testgen) ### ### [TestGen](/contrib/testgen)
Utilities to generate test vectors for the data-driven Bitcoin tests. Utilities to generate test vectors for the data-driven base58 tests.
### [Test Patches](/contrib/test-patches) ### ### [Verify SF Binaries](/contrib/verifysfbinaries)
These patches are applied when the automated pull-tester Legacy SourceForge-era signature verification script (unused for DragonX).
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.

View File

@@ -5,7 +5,7 @@
use warnings; use warnings;
use strict; use strict;
my $cli = "./src/hush-cli"; my $cli = "./src/dragonx-cli";
my $coin = shift || ''; my $coin = shift || '';
unless (-e $cli) { unless (-e $cli) {
die "$cli does not exist, aborting"; die "$cli does not exist, aborting";

View File

@@ -8,17 +8,17 @@ use strict;
# Given a block height, estimate when it will happen # Given a block height, estimate when it will happen
my $block = shift || die "Usage: $0 123"; my $block = shift || die "Usage: $0 123";
my $coin = shift || ''; my $coin = shift || '';
my $hush = "./src/hush-cli"; my $cli = "./src/dragonx-cli";
unless (-e $hush) { unless (-e $cli) {
die "$hush does not exist, aborting"; die "$cli does not exist, aborting";
} }
if ($coin) { if ($coin) {
$hush .= " -ac_name=$coin"; $cli .= " -ac_name=$coin";
} }
my $blockcount = qx{$hush getblockcount}; my $blockcount = qx{$cli getblockcount};
unless ($blockcount = int($blockcount)) { unless ($blockcount = int($blockcount)) {
print "Invalid response from $hush\n"; print "Invalid response from $cli\n";
exit 1; exit 1;
} }
@@ -28,7 +28,7 @@ if ($block <= $blockcount) {
my $diff = $block - $blockcount; my $diff = $block - $blockcount;
# TODO: support custom blocktimes # TODO: support custom blocktimes
# assumes HACs use default blocktime of 60s # 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 $minutes = $diff*$minpb;
my $seconds = $minutes*60; my $seconds = $minutes*60;
my $now = time; my $now = time;
@@ -38,7 +38,7 @@ if ($block <= $blockcount) {
if ($coin) { if ($coin) {
print "$coin Block $block will happen at roughly:\n"; print "$coin Block $block will happen at roughly:\n";
} else { } 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 "$ldate Eastern # $then\n";
print "$gmdate GMT # $then\n"; print "$gmdate GMT # $then\n";

View File

@@ -11,7 +11,7 @@ from hashlib import sha256
# based on https://github.com/KMDLabs/pos64staker/blob/master/stakerlib.py#L89 # based on https://github.com/KMDLabs/pos64staker/blob/master/stakerlib.py#L89
def addr_convert(prefix, address, prefix_bytes): def addr_convert(prefix, address, prefix_bytes):
rmd160_dict = {} 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 # NOTE: any changes to this code should be verified against https://dexstats.info/addressconverter.php
ripemd = b58decode_check(address).hex()[2*prefix_bytes:] ripemd = b58decode_check(address).hex()[2*prefix_bytes:]
net_byte = prefix + ripemd net_byte = prefix + ripemd
@@ -23,7 +23,7 @@ def addr_convert(prefix, address, prefix_bytes):
return(final.decode()) return(final.decode())
if len(sys.argv) < 2: 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] address = sys.argv[1]
# convert given address to a KMD address # convert given address to a KMD address

View File

@@ -1,3 +1,50 @@
dragonx (1.0.3) stable; urgency=medium
* IBD/sync speedups: parallel RandomX pre-verification, adaptive -dbcache, P2P download fixes
* Fix Sapling witness desync and parallelize witness cache rebuild
* Opt-in bulk block streaming (-bulkblocksync) for faster initial sync
* BIP39 seed phrases (SilentDragonXLite-compatible) and HD transparent keys
* Remove assumeutxo / UTXO-snapshot feature
-- DragonX <dan-s-dev@proton.me> Tue, 07 Jul 2026 05:49:59 +0200
dragonx (1.0.0) stable; urgency=medium
* Initial release of DragonX, forked from Hush Full Node
* Full legal-compliant rebrand: binaries, config, documentation
* RandomX proof-of-work, 36-second block time, fully shielded transactions
* New binary names: dragonxd, dragonx-cli, dragonx-tx
-- DragonX <dan-s-dev@proton.me> Mon, 03 Mar 2026 00:00:00 +0000
hush (3.10.5) stable; urgency=medium
* DragonX is no longer supported by this codebase
* DragonX devs have forked our code and we wish them the best
* Find the latest place to download a DragonX full node via dragonx.is
* Concurrent `z_sendmany` now works
* A longstanding bug relating to run multiple `z_sendmany` operations at
once has been fixed. You can now queue up many `z_sendmany` operations
and they will succeed because they now understand how to avoid spending
coins that another `z_sendmany` process is trying to spend.
* Updated Autonomous System Map (asmap)
* New RPC `z_listlockunspent`
* Lists shielded notes (coins inside a zaddr) which are temporarily unspendable because an RPC process is currently trying to spend them.
* If that operation succeeds, they will become spent. If it fails they will be unlocked and become spendable again.
* New option to `z_shieldcoinbase` allows privately donating a percentage of coinbase funds during shielding
* This new option defaults to OFF and allows CLI users to opt-in to donating between 0% and 10% of coinbase funds to developers
* No GUI currently utilizes this but that feature is planned for SD
* The donation has extremely good privacy:
* It cannot be determined from public blockchain data if a donation is being made, as it takes the place of a Sietch output
* It cannot be determined from public blockchain data the amount of the donation
* Donations do not create new transactions, do not use additional blockspace and cannot be detected by anyone but the sender or reciever
* New HAC option `ac_clearnet` can be used to disable clearnet networking for an entire blockchain instead of just a single node
* Updated test framework and tests which allowed the fixing of the `z_sendmany` bug above
* Faster compiling of RandomX internals
* GMP dependency removed, as it is no longer needed
* Hush is now compatible with GCC15 and now correctly supports customizing the compiler for a build via the CC env var
* New HTML man pages are now available at doc/man/hushd.html and doc/man/hush-cli.html
hush (3.10.4) stable; urgency=medium hush (3.10.4) stable; urgency=medium
* Updated seed node list * Updated seed node list

View File

@@ -1,18 +1,18 @@
Source: hush Source: dragonx
Section: utils Section: utils
Priority: optional Priority: optional
Maintainer: Hush <myhushteam@gmail.com> Maintainer: DragonX <dan-s-dev@proton.me>
Homepage: https://hush.is Homepage: https://dragonx.is
Build-Depends: autoconf, automake, bsdmainutils, build-essential, Build-Depends: autoconf, automake, bsdmainutils, build-essential,
cmake, curl, git, g++-multilib, libc6-dev, libsodium-dev, cmake, curl, git, g++-multilib, libc6-dev, libsodium-dev,
libtool, m4, ncurses-dev, pkg-config, python, libtool, m4, ncurses-dev, pkg-config, python,
unzip, wget, zlib1g-dev unzip, wget, zlib1g-dev
Vcs-Git: https://git.hush.is/hush/hush3.git Vcs-Git: https://git.dragonx.is/DragonX/dragonx.git
Vcs-Browser: https://git.hush.is/hush/hush3 Vcs-Browser: https://git.dragonx.is/DragonX/dragonx
Package: hush Package: dragonx
Architecture: amd64 arm64 Architecture: amd64 arm64
Depends: ${shlibs:Depends} Depends: ${shlibs:Depends}
Description: Cryptocoin full node for Hush Description: Privacy-focused cryptocurrency full node for DragonX
Speak And Transact Freely with Hush, which inherits from Bitcoin Protocol and DragonX is a privacy-focused cryptocurrency using RandomX proof-of-work.
Zcash Protocol and is focused on private communications. All transactions are shielded by default. Fork of the Hush Full Node.

View File

@@ -1,8 +1,9 @@
Files: * Files: *
Copyright: 2016-2026, The Hush developers Copyright: 2024-2026, The DragonX developers
2016-2026, The Hush developers
2009-2016, Bitcoin Core developers 2009-2016, Bitcoin Core developers
License: GPLv3 License: GPLv3
Comment: https://hush.is Comment: https://dragonx.is
Files: depends/sources/libsodium-*.tar.gz Files: depends/sources/libsodium-*.tar.gz
Copyright: 2013-2016 Frank Denis Copyright: 2013-2016 Frank Denis

View File

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

View File

@@ -0,0 +1,3 @@
usr/bin/dragonxd
usr/bin/dragonx-cli
usr/bin/dragonx-tx

View File

@@ -0,0 +1,3 @@
DEBIAN/manpages/dragonx-cli.1
DEBIAN/manpages/dragonx-tx.1
DEBIAN/manpages/dragonxd.1

View File

@@ -1,4 +1,4 @@
## HUSH3.conf configuration file. Lines beginning with # are comments. ## DRAGONX.conf configuration file. Lines beginning with # are comments.
# Network-related settings: # Network-related settings:
@@ -72,7 +72,7 @@
#maxconnections= #maxconnections=
# #
# JSON-RPC options (for controlling a running hushd process) # JSON-RPC options (for controlling a running dragonxd process)
# #
# server=1 tells node to accept JSON-RPC commands (set as default if not specified) # server=1 tells node to accept JSON-RPC commands (set as default if not specified)
@@ -97,7 +97,7 @@
# NOTE: opening up the RPC port to hosts outside your local trusted network is NOT RECOMMENDED, # 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 # 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 # that can authenticate on the RPC port can steal your keys + take over the account running dragonxd
#rpcallowip=10.1.1.34/255.255.255.0 #rpcallowip=10.1.1.34/255.255.255.0
#rpcallowip=1.2.3.4/24 #rpcallowip=1.2.3.4/24
@@ -106,7 +106,7 @@
# Listen for RPC connections on this TCP port: # Listen for RPC connections on this TCP port:
#rpcport=1234 #rpcport=1234
# You can use hushd to send commands to hushd # You can use dragonxd to send commands to dragonxd
# running on another host using this option: # running on another host using this option:
#rpcconnect=127.0.0.1 #rpcconnect=127.0.0.1

View File

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

View File

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

View File

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

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) 2012-2016 The Bitcoin Core developers
# Copyright (c) 2018-2020 The Hush developers # Copyright (c) 2018-2020 The Hush developers
# Distributed under the GPLv3 software license, see the accompanying # Distributed under the GPLv3 software license, see the accompanying
# file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
# call $hush-cli for RPC # call $dragonx-cli for RPC
_hush_rpc() { _dragonx_rpc() {
# determine already specified args necessary for RPC # determine already specified args necessary for RPC
local rpcargs=() local rpcargs=()
for i in ${COMP_LINE}; do for i in ${COMP_LINE}; do
@@ -15,25 +15,25 @@ _hush_rpc() {
;; ;;
esac esac
done done
$hush_cli "${rpcargs[@]}" "$@" $dragonx_cli "${rpcargs[@]}" "$@"
} }
# Add wallet accounts to COMPREPLY # Add wallet accounts to COMPREPLY
_hush_accounts() { _dragonx_accounts() {
local accounts local accounts
# Accounts are deprecated in hush # Accounts are deprecated in dragonx
#accounts=$(_hush_rpc listaccounts | awk -F '"' '{ print $2 }') #accounts=$(_dragonx_rpc listaccounts | awk -F '"' '{ print $2 }')
accounts="\\\"\\\"" accounts="\\\"\\\""
COMPREPLY=( "${COMPREPLY[@]}" $( compgen -W "$accounts" -- "$cur" ) ) COMPREPLY=( "${COMPREPLY[@]}" $( compgen -W "$accounts" -- "$cur" ) )
} }
_hush_cli() { _dragonx_cli() {
local cur prev words=() cword 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 # save and use original argument to invoke dragonx-cli for -help, help and RPC
# as hush-cli might not be in $PATH # as dragonx-cli might not be in $PATH
hush_cli="$1" dragonx_cli="$1"
COMPREPLY=() COMPREPLY=()
_get_comp_words_by_ref -n = cur prev words cword _get_comp_words_by_ref -n = cur prev words cword
@@ -63,7 +63,7 @@ _hush_cli() {
if ((cword > 3)); then if ((cword > 3)); then
case ${words[cword-3]} in case ${words[cword-3]} in
addmultisigaddress) addmultisigaddress)
_hush_accounts _dragonx_accounts
return 0 return 0
;; ;;
getbalance|gettxout|importaddress|importpubkey|importprivkey|listreceivedbyaccount|listreceivedbyaddress|listsinceblock) getbalance|gettxout|importaddress|importpubkey|importprivkey|listreceivedbyaccount|listreceivedbyaddress|listsinceblock)
@@ -92,7 +92,7 @@ _hush_cli() {
return 0 return 0
;; ;;
move|setaccount) move|setaccount)
_hush_accounts _dragonx_accounts
return 0 return 0
;; ;;
esac esac
@@ -108,7 +108,7 @@ _hush_cli() {
return 0 return 0
;; ;;
getaccountaddress|getaddressesbyaccount|getbalance|getnewaddress|getreceivedbyaccount|listtransactions|move|sendfrom|sendmany) getaccountaddress|getaddressesbyaccount|getbalance|getnewaddress|getreceivedbyaccount|listtransactions|move|sendfrom|sendmany)
_hush_accounts _dragonx_accounts
return 0 return 0
;; ;;
esac esac
@@ -132,12 +132,12 @@ _hush_cli() {
# only parse -help if senseful # only parse -help if senseful
if [[ -z "$cur" || "$cur" =~ ^- ]]; then 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 fi
# only parse help if senseful # only parse help if senseful
if [[ -z "$cur" || "$cur" =~ ^[a-z] ]]; then 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 fi
COMPREPLY=( $( compgen -W "$helpopts $commands" -- "$cur" ) ) COMPREPLY=( $( compgen -W "$helpopts $commands" -- "$cur" ) )
@@ -150,7 +150,7 @@ _hush_cli() {
;; ;;
esac esac
} && } &&
complete -F _hush_cli hush-cli complete -F _dragonx_cli dragonx-cli
# Local variables: # Local variables:
# mode: shell-script # mode: shell-script

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 # Copyright (c) 2016 The Bitcoin Core developers
# Distributed under the GPLv3 software license, see the accompanying # Distributed under the GPLv3 software license, see the accompanying
# file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
_hush_tx() { _dragonx_tx() {
local cur prev words=() cword 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 # it might not be in $PATH
hush_tx="$1" dragonx_tx="$1"
COMPREPLY=() COMPREPLY=()
_get_comp_words_by_ref -n =: cur prev words cword _get_comp_words_by_ref -n =: cur prev words cword
@@ -27,15 +27,15 @@ _hush_tx() {
if [[ "$cword" == 1 || ( "$prev" != "-create" && "$prev" == -* ) ]]; then if [[ "$cword" == 1 || ( "$prev" != "-create" && "$prev" == -* ) ]]; then
# only options (or an uncompletable hex-string) allowed # only options (or an uncompletable hex-string) allowed
# parse hush-tx -help for options # parse dragonx-tx -help for options
local helpopts 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" ) ) COMPREPLY=( $( compgen -W "$helpopts" -- "$cur" ) )
else else
# only commands are allowed # only commands are allowed
# parse -help for commands # parse -help for commands
local helpcmds 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" ) ) COMPREPLY=( $( compgen -W "$helpcmds" -- "$cur" ) )
fi fi
@@ -46,7 +46,7 @@ _hush_tx() {
return 0 return 0
} && } &&
complete -F _hush_tx hush-tx complete -F _dragonx_tx dragonx-tx
# Local variables: # Local variables:
# mode: shell-script # mode: shell-script

View File

@@ -8,8 +8,8 @@ Exit
:RegExport :RegExport
Set RegFile="%Temp%\~etsaclu.tmp" Set RegFile="%Temp%\~etsaclu.tmp"
Set "hush=%~dp0" Set "dragonx=%~dp0"
set "hush=%hush:\=\\%" set "dragonx=%dragonx:\=\\%"
If Exist %RegFile% ( If Exist %RegFile% (
Attrib -R -S -H %RegFile% & Del /F /Q %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 Windows Registry Editor Version 5.00
>> %RegFile% Echo. >> %RegFile% Echo.
>> %RegFile% Echo [HKEY_CLASSES_ROOT\hush] >> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx]
>> %RegFile% Echo @="URL:hush protocol" >> %RegFile% Echo @="URL:dragonx protocol"
>> %RegFile% Echo "URL Protocol"="" >> %RegFile% Echo "URL Protocol"=""
>> %RegFile% Echo. >> %RegFile% Echo.
>> %RegFile% Echo [HKEY_CLASSES_ROOT\hush\DefaultIcon] >> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx\DefaultIcon]
>> %RegFile% Echo @="silentdragon.exe" >> %RegFile% Echo @="silentdragon.exe"
>> %RegFile% Echo. >> %RegFile% Echo.
>> %RegFile% Echo [HKEY_CLASSES_ROOT\hush\Shell] >> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx\Shell]
>> %RegFile% Echo. >> %RegFile% Echo.
>> %RegFile% Echo [HKEY_CLASSES_ROOT\hush\Shell\Open] >> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx\Shell\Open]
>> %RegFile% Echo. >> %RegFile% Echo.
>> %RegFile% Echo [HKEY_CLASSES_ROOT\hush\Shell\Open\Command] >> %RegFile% Echo [HKEY_CLASSES_ROOT\dragonx\Shell\Open\Command]
>> %RegFile% Echo @="%hush%silentdragon.exe \"%%1\"" >> %RegFile% Echo @="%dragonx%silentdragon.exe \"%%1\""
Start /Wait %systemroot%\Regedit.exe /S %RegFile% Start /Wait %systemroot%\Regedit.exe /S %RegFile%
Del %RegFile% Del %RegFile%

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) 2012-2017 The Bitcoin Core developers
# Copyright (c) 2016-2017 The Zcash developers # Copyright (c) 2016-2017 The Zcash developers
# Copyright (c) 2018 The Hush developers # Copyright (c) 2018 The Hush developers
# Distributed under the GPLv3 software license, see the accompanying # Distributed under the GPLv3 software license, see the accompanying
# file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html # file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html
_hushd() { _dragonxd() {
local cur prev words=() cword 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 # it might not be in $PATH
hushd="$1" dragonxd="$1"
COMPREPLY=() COMPREPLY=()
_get_comp_words_by_ref -n = cur prev words cword _get_comp_words_by_ref -n = cur prev words cword
@@ -35,7 +35,7 @@ _hushd() {
# only parse -help if senseful # only parse -help if senseful
if [[ -z "$cur" || "$cur" =~ ^- ]]; then if [[ -z "$cur" || "$cur" =~ ^- ]]; then
local helpopts 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" ) ) COMPREPLY=( $( compgen -W "$helpopts" -- "$cur" ) )
fi fi
@@ -47,7 +47,7 @@ _hushd() {
;; ;;
esac esac
} && } &&
complete -F _hushd hushd complete -F _dragonxd dragonxd
# Local variables: # Local variables:
# mode: shell-script # mode: shell-script

View File

@@ -11,19 +11,19 @@
BRANCH=$1 BRANCH=$1
git clone https://git.hush.is/hush/hush3 git clone https://git.dragonx.is/DragonX/dragonx
cd hush3 cd dragonx
git checkout $BRANCH git checkout $BRANCH
# You need 2GB of RAM per core, don't use too many # 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 # `nproc` tells you how many cores you have
JOBS=$2 JOBS=$2
JOBZ=$(nproc) # if build.sh fails, we can use many more jobs with make 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 # Sometimes the parrallel build fails because of a race condition, so
# we do it a few times to Make Really Sure # we do it a few times to Make Really Sure
./build.sh -j$JOBS;make -j$JOBZ;make -j$JOBZ;make -j$JOBZ ./build.sh -j$JOBS;make -j$JOBZ;make -j$JOBZ;make -j$JOBZ
./src/hushd &> hush.log & ./src/dragonxd &> dragonx.log &
# You can give the entire or parts of this file to Hush developers for debugging, # 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 # 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

View File

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

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: These instructions distilled from:
[ https://help.ubuntu.com/community/KVM/Installation]( https://help.ubuntu.com/community/KVM/Installation) [ 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: 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 git clone git://github.com/devrandom/gitian-builder.git
mkdir gitian-builder/inputs mkdir gitian-builder/inputs
cd 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: 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 export USE_LXC=1
git clone git://github.com/bitcoin/bitcoin.git git clone https://git.dragonx.is/DragonX/dragonx.git
... etc ... etc

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@@ -1,16 +1,16 @@
description "Hush Daemon" description "DragonX Daemon"
start on runlevel [2345] start on runlevel [2345]
stop on starting rc RUNLEVEL=[016] stop on starting rc RUNLEVEL=[016]
env HUSHD_BIN="/usr/bin/hushd" env HUSHD_BIN="/usr/bin/dragonxd"
env HUSHD_USER="hush" env HUSHD_USER="hush"
env HUSHD_GROUP="hush" env HUSHD_GROUP="hush"
env HUSHD_PIDDIR="/var/run/hushd" env HUSHD_PIDDIR="/var/run/dragonxd"
# upstart can't handle variables constructed with other variables # upstart can't handle variables constructed with other variables
env HUSHD_PIDFILE="/var/run/hushd/hushd.pid" 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/hushd" env HUSHD_DATADIR="/var/lib/dragonxd"
expect fork expect fork
@@ -20,12 +20,12 @@ kill timeout 60
pre-start script pre-start script
# this will catch non-existent config files # this will catch non-existent config files
# hushd will check and exit with this very warning, but it can do so # dragonxd will check and exit with this very warning, but it can do so
# long after forking, leaving upstart to think everything started fine. # long after forking, leaving upstart to think everything started fine.
# since this is a commonly encountered case on install, just check and # since this is a commonly encountered case on install, just check and
# warn here. # warn here.
if ! grep -qs '^rpcpassword=' "$HUSHD_CONFIGFILE" ; then if ! grep -qs '^rpcpassword=' "$HUSHD_CONFIGFILE" ; then
echo "ERROR: You must set a secure rpcpassword to run hushd." echo "ERROR: You must set a secure rpcpassword to run dragonxd."
echo "The setting must appear in $HUSHD_CONFIGFILE" echo "The setting must appear in $HUSHD_CONFIGFILE"
echo echo
echo "This password is security critical to securing wallets " echo "This password is security critical to securing wallets "

View File

@@ -1,36 +1,36 @@
#!/usr/bin/env bash #!/usr/bin/env bash
# #
# hushd The hush core server. # dragonxd The DragonX core server.
# #
# #
# chkconfig: 345 80 20 # chkconfig: 345 80 20
# description: hushd # description: dragonxd
# processname: hushd # processname: dragonxd
# #
# Source function library. # Source function library.
. /etc/init.d/functions . /etc/init.d/functions
# you can override defaults in /etc/sysconfig/hushd, see below # you can override defaults in /etc/sysconfig/dragonxd, see below
if [ -f /etc/sysconfig/hushd ]; then if [ -f /etc/sysconfig/dragonxd ]; then
. /etc/sysconfig/hushd . /etc/sysconfig/dragonxd
fi fi
RETVAL=0 RETVAL=0
prog=hushd prog=dragonxd
# you can override the lockfile via HUSHD_LOCKFILE in /etc/sysconfig/hushd # you can override the lockfile via HUSHD_LOCKFILE in /etc/sysconfig/dragonxd
lockfile=${HUSHD_LOCKFILE-/var/lock/subsys/hushd} lockfile=${HUSHD_LOCKFILE-/var/lock/subsys/dragonxd}
# hushd defaults to /usr/bin/hushd, override with HUSHD_BIN # dragonxd defaults to /usr/bin/dragonxd, override with HUSHD_BIN
hushd=${HUSHD_BIN-/usr/bin/hushd} dragonxd=${HUSHD_BIN-/usr/bin/dragonxd}
# hushd opts default to -disablewallet, override with HUSHD_OPTS # dragonxd opts default to -disablewallet, override with HUSHD_OPTS
hushd_opts=${HUSHD_OPTS--disablewallet} dragonxd_opts=${HUSHD_OPTS--disablewallet}
start() { start() {
echo -n $"Starting $prog: " echo -n $"Starting $prog: "
daemon $DAEMONOPTS $hushd $hushd_opts daemon $DAEMONOPTS $dragonxd $dragonxd_opts
RETVAL=$? RETVAL=$?
echo echo
[ $RETVAL -eq 0 ] && touch $lockfile [ $RETVAL -eq 0 ] && touch $lockfile

View File

@@ -5,23 +5,23 @@
if [ -d "/var/lib/hush/.hush" ]; then if [ -d "/var/lib/hush/.hush" ]; then
HUSHD_DEFAULT_DATADIR="/var/lib/hush/.hush" HUSHD_DEFAULT_DATADIR="/var/lib/hush/.hush"
else else
HUSHD_DEFAULT_DATADIR="/var/lib/hushd" HUSHD_DEFAULT_DATADIR="/var/lib/dragonxd"
fi fi
HUSHD_CONFIGFILE=${HUSHD_CONFIGFILE:-/etc/hush/hush.conf} HUSHD_CONFIGFILE=${HUSHD_CONFIGFILE:-/etc/dragonx/DRAGONX.conf}
HUSHD_PIDDIR=${HUSHD_PIDDIR:-/var/run/hushd} HUSHD_PIDDIR=${HUSHD_PIDDIR:-/var/run/dragonxd}
HUSHD_PIDFILE=${HUSHD_PIDFILE:-${HUSHD_PIDDIR}/hushd.pid} HUSHD_PIDFILE=${HUSHD_PIDFILE:-${HUSHD_PIDDIR}/dragonxd.pid}
HUSHD_DATADIR=${HUSHD_DATADIR:-${HUSHD_DEFAULT_DATADIR}} HUSHD_DATADIR=${HUSHD_DATADIR:-${HUSHD_DEFAULT_DATADIR}}
HUSHD_USER=${HUSHD_USER:-${HUSH_USER:-hush}} HUSHD_USER=${HUSHD_USER:-${HUSH_USER:-hush}}
HUSHD_GROUP=${HUSHD_GROUP:-hush} HUSHD_GROUP=${HUSHD_GROUP:-hush}
HUSHD_BIN=${HUSHD_BIN:-/usr/bin/hushd} HUSHD_BIN=${HUSHD_BIN:-/usr/bin/dragonxd}
HUSHD_NICE=${HUSHD_NICE:-${NICELEVEL:-0}} HUSHD_NICE=${HUSHD_NICE:-${NICELEVEL:-0}}
HUSHD_OPTS="${HUSHD_OPTS:-${HUSH_OPTS}}" HUSHD_OPTS="${HUSHD_OPTS:-${HUSH_OPTS}}"
name="Hush Full Node Daemon" name="DragonX Full Node Daemon"
description="Hush cryptocurrency P2P network daemon" description="DragonX cryptocurrency P2P network daemon"
command="/usr/bin/hushd" command="/usr/bin/dragonxd"
command_args="-pid=\"${HUSHD_PIDFILE}\" \ command_args="-pid=\"${HUSHD_PIDFILE}\" \
-conf=\"${HUSHD_CONFIGFILE}\" \ -conf=\"${HUSHD_CONFIGFILE}\" \
-datadir=\"${HUSHD_DATADIR}\" \ -datadir=\"${HUSHD_DATADIR}\" \
@@ -71,7 +71,7 @@ checkconfig()
{ {
if ! grep -qs '^rpcpassword=' "${HUSHD_CONFIGFILE}" ; then if ! grep -qs '^rpcpassword=' "${HUSHD_CONFIGFILE}" ; then
eerror "" eerror ""
eerror "ERROR: You must set a secure rpcpassword to run hushd." eerror "ERROR: You must set a secure rpcpassword to run dragonxd."
eerror "The setting must appear in ${HUSHD_CONFIGFILE}" eerror "The setting must appear in ${HUSHD_CONFIGFILE}"
eerror "" eerror ""
eerror "This password is security critical to securing wallets " eerror "This password is security critical to securing wallets "

View File

@@ -1,31 +1,31 @@
# /etc/conf.d/hushd: config file for /etc/init.d/hushd # /etc/conf.d/dragonxd: config file for /etc/init.d/dragonxd
# Config file location # 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) # What directory to write pidfile to? (created and owned by $HUSHD_USER)
#HUSHD_PIDDIR="/var/run/hushd" #HUSHD_PIDDIR="/var/run/dragonxd"
# What filename to give the pidfile # What filename to give the pidfile
#HUSHD_PIDFILE="${HUSHD_PIDDIR}/hushd.pid" #HUSHD_PIDFILE="${HUSHD_PIDDIR}/dragonxd.pid"
# Where to write hushd data (be mindful that the blockchain is large) # Where to write dragonxd data (be mindful that the blockchain is large)
#HUSHD_DATADIR="/var/lib/hushd" #HUSHD_DATADIR="/var/lib/dragonxd"
# User and group to own hushd process # User and group to own dragonxd process
#HUSHD_USER="hush" #HUSHD_USER="hush"
#HUSHD_GROUP="hush" #HUSHD_GROUP="hush"
# Path to hushd executable # Path to dragonxd executable
#HUSHD_BIN="/usr/bin/hushd" #HUSHD_BIN="/usr/bin/dragonxd"
# Nice value to run hushd under # Nice value to run dragonxd under
#HUSHD_NICE=0 #HUSHD_NICE=0
# Additional options (avoid -conf and -datadir, use flags above) # Additional options (avoid -conf and -datadir, use flags above)
HUSHD_OPTS="-disablewallet" HUSHD_OPTS="-disablewallet"
# The timeout in seconds OpenRC will wait for hushd to terminate # The timeout in seconds OpenRC will wait for dragonxd to terminate
# after a SIGTERM has been raised. # after a SIGTERM has been raised.
# Note that this will be mapped as argument to start-stop-daemon's # Note that this will be mapped as argument to start-stop-daemon's
# '--retry' option, which means you can specify a retry schedule # '--retry' option, which means you can specify a retry schedule

View File

@@ -0,0 +1,24 @@
[Unit]
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/dragonx/DRAGONX.conf -datadir=/var/lib/dragonxd -disablewallet
Restart=always
PrivateTmp=true
TimeoutStopSec=60s
TimeoutStartSec=2s
StartLimitInterval=120s
StartLimitBurst=5
[Install]
WantedBy=multi-user.target

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

View File

@@ -1,9 +1,5 @@
### MacDeploy ### ### 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: This script should not be run manually, instead, after building as usual:
make deploy 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 During the process, the disk image window will pop up briefly where the fancy
settings are applied. This is normal, please do not interfere. 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`.

View File

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

View File

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

View File

@@ -3,22 +3,23 @@
# Distributed under the GPLv3 software license, see the accompanying # Distributed under the GPLv3 software license, see the accompanying
# file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html # 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 # This script is used to generate the checkpoint data used by the SilentDragonX Android SDK
# https://git.hush.is/fekt/hush-android-wallet-sdk/src/branch/main/sdk-lib/src/main/assets/co.electriccoin.zcash/checkpoint/mainnet # https://git.dragonx.is/DragonX/SilentDragonXAndroid
# (checkpoint format follows the upstream co.electriccoin.zcash/checkpoint/mainnet layout)
use warnings; use warnings;
use strict; use strict;
my $hush = "./src/hush-cli"; my $cli = "./src/dragonx-cli";
my $getblock= "$hush getblock"; my $getblock= "$cli getblock";
my $gethash = "$hush getblockhash"; my $gethash = "$cli getblockhash";
my $gettree = "$hush getblockmerkletree"; my $gettree = "$cli getblockmerkletree";
my $start = shift || 1390000; my $start = shift || 1390000;
my $end = shift || 1422000; my $end = shift || 1422000;
my $stride = shift || 10000; my $stride = shift || 10000;
my $blocks = qx{$hush getblockcount}; my $blocks = qx{$cli getblockcount};
if($?) { if($?) {
print "ERROR, is hushd running? exiting...\n"; print "ERROR, is dragonxd running? exiting...\n";
exit 1; exit 1;
} }

View File

@@ -3,7 +3,8 @@
# Distributed under the GPLv3 software license, see the accompanying # Distributed under the GPLv3 software license, see the accompanying
# file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html # 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 # https://git.hush.is/hush/silentdragonlite-cli/src/branch/master/lib/src/lightclient/checkpoints.rs#L24
use warnings; use warnings;
@@ -12,16 +13,16 @@ use strict;
# call this script like this to generate checkpoints for another chain: # call this script like this to generate checkpoints for another chain:
# CLI=./src/hac-cli ./contrib/sdl_checkpoints.pl ... # CLI=./src/hac-cli ./contrib/sdl_checkpoints.pl ...
my $hush = $ENV{CLI} || "./src/hush-cli"; my $cli = $ENV{CLI} || "./src/dragonx-cli";
my $gethash = "$hush getblockhash"; my $gethash = "$cli getblockhash";
my $gettree = "$hush getblockmerkletree"; my $gettree = "$cli getblockmerkletree";
my $start = shift || 300000; my $start = shift || 300000;
my $end = shift || 840000; my $end = shift || 840000;
my $stride = shift || 10000; my $stride = shift || 10000;
my $blocks = qx{$hush getblockcount}; my $blocks = qx{$cli getblockcount};
if($?) { if($?) {
print "ERROR, is hushd running? exiting...\n"; print "ERROR, is dragonxd running? exiting...\n";
exit 1; exit 1;
} }

View File

@@ -1,10 +1,8 @@
# Seeds # Seeds
Utility to generate the seeds.txt list that is compiled into the client 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 ## 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.

View File

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

View File

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

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -1,6 +1,6 @@
### TestGen ### ### TestGen ###
Utilities to generate test vectors for the data-driven Hush tests. Utilities to generate test vectors for the data-driven DragonX tests.
Usage: Usage:

View File

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

View File

@@ -1,5 +1,5 @@
build_darwin_CC = gcc-8 build_darwin_CC = gcc-15
build_darwin_CXX = g++-8 build_darwin_CXX = g++-15
build_darwin_AR: = $(shell xcrun -f ar) build_darwin_AR: = $(shell xcrun -f ar)
build_darwin_RANLIB: = $(shell xcrun -f ranlib) build_darwin_RANLIB: = $(shell xcrun -f ranlib)
build_darwin_STRIP: = $(shell xcrun -f strip) build_darwin_STRIP: = $(shell xcrun -f strip)
@@ -10,8 +10,8 @@ build_darwin_SHA256SUM = shasum -a 256
build_darwin_DOWNLOAD = curl --connect-timeout $(DOWNLOAD_CONNECT_TIMEOUT) --retry $(DOWNLOAD_RETRIES) -L -f -o build_darwin_DOWNLOAD = curl --connect-timeout $(DOWNLOAD_CONNECT_TIMEOUT) --retry $(DOWNLOAD_RETRIES) -L -f -o
#darwin host on darwin builder. overrides darwin host preferences. #darwin host on darwin builder. overrides darwin host preferences.
darwin_CC= gcc-8 darwin_CC= gcc-15
darwin_CXX= g++-8 darwin_CXX= g++-15
darwin_AR:=$(shell xcrun -f ar) darwin_AR:=$(shell xcrun -f ar)
darwin_RANLIB:=$(shell xcrun -f ranlib) darwin_RANLIB:=$(shell xcrun -f ranlib)
darwin_STRIP:=$(shell xcrun -f strip) darwin_STRIP:=$(shell xcrun -f strip)

View File

@@ -2,8 +2,8 @@ OSX_MIN_VERSION=10.12
OSX_SDK_VERSION=10.12 OSX_SDK_VERSION=10.12
OSX_SDK=$(SDK_PATH)/MacOSX$(OSX_SDK_VERSION).sdk OSX_SDK=$(SDK_PATH)/MacOSX$(OSX_SDK_VERSION).sdk
LD64_VERSION=253.9 LD64_VERSION=253.9
darwin_CC=gcc-8 -target $(host) -mmacosx-version-min=$(OSX_MIN_VERSION) --sysroot $(OSX_SDK) -mlinker-version=$(LD64_VERSION) darwin_CC=gcc-15 -target $(host) -mmacosx-version-min=$(OSX_MIN_VERSION) --sysroot $(OSX_SDK) -mlinker-version=$(LD64_VERSION)
darwin_CXX=g++-8 -target $(host) -mmacosx-version-min=$(OSX_MIN_VERSION) --sysroot $(OSX_SDK) -mlinker-version=$(LD64_VERSION) darwin_CXX=g++-15 -target $(host) -mmacosx-version-min=$(OSX_MIN_VERSION) --sysroot $(OSX_SDK) -mlinker-version=$(LD64_VERSION)
darwin_CFLAGS=-pipe darwin_CFLAGS=-pipe
darwin_CXXFLAGS=$(darwin_CFLAGS) darwin_CXXFLAGS=$(darwin_CFLAGS)

View File

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

View File

@@ -40,9 +40,15 @@ define $(package)_preprocess_cmds
cat $($(package)_patch_dir)/cargo.config | sed 's|CRATE_REGISTRY|$(host_prefix)/$(CRATE_REGISTRY)|' > .cargo/config cat $($(package)_patch_dir)/cargo.config | sed 's|CRATE_REGISTRY|$(host_prefix)/$(CRATE_REGISTRY)|' > .cargo/config
endef endef
ifeq ($(build_os),darwin)
define $(package)_build_cmds
CARGO=$(HOME)/.cargo/bin/cargo RUSTC=$(HOME)/.cargo/bin/rustc $(HOME)/.cargo/bin/cargo build --package librustzcash $($(package)_build_opts)
endef
else
define $(package)_build_cmds define $(package)_build_cmds
$(host_prefix)/native/bin/cargo build --package librustzcash $($(package)_build_opts) $(host_prefix)/native/bin/cargo build --package librustzcash $($(package)_build_opts)
endef endef
endif
define $(package)_stage_cmds define $(package)_stage_cmds
mkdir $($(package)_staging_dir)$(host_prefix)/lib/ && \ mkdir $($(package)_staging_dir)$(host_prefix)/lib/ && \

View File

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

View File

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

8
depends/strip-rlib-metadata.sh Executable file
View File

@@ -0,0 +1,8 @@
#!/bin/sh
# Strip rust.metadata.bin from .rlib archives for macOS linker compatibility
RLIB_DIR="$1"
if [ -d "$RLIB_DIR" ]; then
for rlib in "$RLIB_DIR"/*.rlib; do
[ -f "$rlib" ] && ar d "$rlib" rust.metadata.bin 2>/dev/null || true
done
fi

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 ## 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) 0. [Community](#community)
## Types of contributions we're looking for ## 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 * Find and fix bugs
* Improve suboptimal code * Improve suboptimal code
* Extend our software * Extend our software
* Perform a secure code review of Hush Full Node and other Hush-related software * Perform a secure code review of DragonX Full Node and other DragonX-related software
We have a curated list of projects with details about difficulty level and languages involved: https://git.hush.is/hush/projects
Interested in making a contribution? Read on! 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): 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. * 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. * 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. * 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 ## 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 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. * **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 ## 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 ## Contribution review process

View File

@@ -1,6 +1,6 @@
# Being a Hush Developer # Being a DragonX Developer
## Compiling Hush ## Compiling DragonX
Normal compiling is as simple as: 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 ## Dealing with dependency changes
Let's say you change a dependency and want the compile to notice. If your 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 `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 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 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
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. 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 Additionally, it's a good idea to run `make clean` before you switch
between branches. between branches.
## Partial compiles ## 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 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 work correctly in all circustances. Sometimes partial compiles break weird
build system dependencies, and you must do a `make clean` first, or even 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 ## 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 : to generate new unix man pages for that version :
./util/gen-manpages.sh ./util/gen-manpages.sh
## Generating new debian packages ## 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 ./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 two HACs will eventually chain fork due to their different consensus rules and
ban each other, wasting time, bandwidth and sanity. ban each other, wasting time, bandwidth and sanity.
An example of doing this can be seen in the commit An example of this pattern in the Git history is the commit which added the
https://git.hush.is/hush/hush3/commit/d39503c13b7419620d138050899705ced557eef9 `-ac_burn` consensus changing option; search the log for `ac_burn` to find it.
which added the `-ac_burn` consensus changing option.
The chain magic value is the CRC32 checksum of every non-default consensus The chain magic value is the CRC32 checksum of every non-default consensus
option the HAC uses. 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! 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

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.

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 uses public-key cryptography for address allocation and a distributed hash table
for routing. for routing.
@@ -9,7 +9,7 @@ for routing.
CJDNS is like a distributed, shared VPN with multiple entry points where every CJDNS is like a distributed, shared VPN with multiple entry points where every
participant can reach any other participant. All participants use addresses from participant can reach any other participant. All participants use addresses from
the `fc00::/8` network (reserved IPv6 range). Installation and configuration is 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 the network router). See https://github.com/cjdelisle/cjdns#readme and
https://github.com/hyperboria/docs#hyperboriadocs for more information. 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. from traffic analysis and filtering.
Used with Tor and I2P, CJDNS is a complementary option that can enhance network 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 Each network has different characteristics. For instance, Tor is widely used but
somewhat centralized. I2P connections have a source address and I2P is slow. 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. https://github.com/cjdelisle/cjdns#how-to-install-cjdns.
You need to initiate an outbound connection to a peer on the CJDNS network 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 ["2. Find a friend"](https://github.com/cjdelisle/cjdns#2-find-a-friend) and
["3. Connect your node to your friend's ["3. Connect your node to your friend's
node"](https://github.com/cjdelisle/cjdns#3-connect-your-node-to-your-friends-node) 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 The network connection can be checked by running `./tools/peerStats` from the
CJDNS directory. 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: configuration option makes CJDNS peers automatically reachable:
``` ```
-cjdnsreachable -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 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) 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 - Your node can consider incoming `fc00::/8` connections to be from the CJDNS
network rather than from an IPv6 private one. network rather than from an IPv6 private one.
- If one of your node's local addresses is `fc00::/8`, then it can choose to - 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 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. 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 There may be fewer CJDNS peers than Tor or IP ones. You can use
CJDNS peers than Tor or IP ones. You can use `hush-cli -addrinfo` to see the `dragonx-cli -addrinfo` to see the number of CJDNS addresses known to your node.
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 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 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 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 [doc/tor.md](tor.md) for details.
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` - 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. RPC.

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 # 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 ## Common Options
@@ -15,20 +15,20 @@ Tells your node to connect to another node, by IP address or hostname.
## consolidation=1 ## 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 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 ON for GUI wallets that use an embedded hushd. 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 ## 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. 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 ## txindex=1
@@ -56,7 +56,7 @@ Defaults to: bind to all interfaces. This option Binds to given address to liste
## stratumport=<port> ## 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> ## stratumallowip=<ip>
@@ -68,12 +68,12 @@ These options are not commonly used and likely on for advanced users and/or deve
## addressindex=1 ## 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 ## 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 ## 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

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: First you will want to clone the code locally:
``` ```
git clone https://git.hush.is/hush/hush3 git clone https://git.dragonx.is/DragonX/dragonx
cd hush3 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: 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 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 details on installing dependencies. If you are using a recent-ish Ubuntu or Debian Linux
distro, this is probably what you need: 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: One way to do a fresh sync is:
``` ```
cd ~/.hush/HUSH3 cd ~/.hush/DRAGONX
rm blocks chainstate database notarizations hushstate 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 If you are using `zindex=1` then you need to also delete zindex.dat
``` ```
cd ~/.hush/HUSH3 cd ~/.hush/DRAGONX
rm zindex.dat blocks chainstate database notarizations hushstate 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 # 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: 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` NOTE: `src/blahd` is just a shell script that calls `src/dragonxd`; you always want to
is just a shell script that calls `src/hushd` and you always want to give an actual executable give an actual executable file as the first argument to `gdb`, not a bash script.
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 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` : 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 The above command will only show spendable UTXOs. The jq language is very powerful and is very
useful for devops and developer scripts. 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/ 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. 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 # TODO: this should probably become a script in ./contrib
git clone https://git.hush.is/hush/hush3 hush3-testing git clone https://git.dragonx.is/DragonX/dragonx dragonx-testing
cd hush3-testing cd dragonx-testing
git checkout zindexdb git checkout zindexdb
# you need 2GB RAM free per -jN # you need 2GB RAM free per -jN
./build.sh -j2; make; make; make # this deals with build-system race condition bugs ./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 # we want to test a fresh sync, so backup current data
TIME=`perl -e "print time"` TIME=`perl -e "print time"`
mv ~/.hush/{HUSH3,HUSH3-backup-$TIME} mv ~/.hush/{DRAGONX,DRAGONX-backup-$TIME}
mkdir ~/.hush/HUSH3 mkdir ~/.hush/DRAGONX
# Use your previous config as a base # 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 # 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 # 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 # This log file is helpful for debugging more and will contain a history of the
# size of the anonset at every block height # size of the anonset at every block height
./src/hushd &> hushd.log & ./src/dragonxd &> dragonxd.log &
# to look at the 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: 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: 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: 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. * 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 ? * Is `zindex.dat` 149 bytes ?
# Adding a PoW algorithm # Adding a PoW algorithm
We will describe here the high-level ideas on how to add a new PoW algorithm to 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` the codebase. Adding a new PoW algo means adding a new option to the `-ac_algo`
CLI param for HSC's. 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` * 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` * 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 * 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 * 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** **test coins**
The main way to test new things is directly on mainnet or you can also make a 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` 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. 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** **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 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 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. 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 - 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. - 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. - 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. - Shutdown : Does an orderly shutdown of everything.

View File

@@ -1,11 +1,11 @@
# Expectations for DNS Seed operators # 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. 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 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 seeds and may be more exposed. In light of this exposure, this
document establishes some basic expectations for operating DNS seeds. 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. contracted by the operator are equally expected to uphold these expectations.
1. The DNS seed results must consist exclusively of fairly selected and 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. operator's understanding and capability.
2. For the avoidance of doubt, the results may be randomized but must not 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. 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 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 network and must not be retained longer than necessary nor disclosed
to any third party. to any third party.
@@ -41,13 +41,8 @@ details of their operating practices.
related to the DNS seed operation. related to the DNS seed operation.
If these expectations cannot be satisfied the operator should discontinue If these expectations cannot be satisfied the operator should discontinue
providing services and contact the active Hush development team as well as providing services and contact the active DragonX development team as well as
creating an issue in the [Hush Git repository](https://git.hush.is./hush/hush3). creating an issue in the [DragonX Git repository](https://git.dragonx.is/DragonX/dragonx).
Behavior outside of these expectations may be reasonable in some Behavior outside of these expectations may be reasonable in some
situations but should be discussed in public in advance. 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.

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>

After

Width:  |  Height:  |  Size: 1.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.9 KiB

29
doc/dragonxd-systemd.md Normal file
View File

@@ -0,0 +1,29 @@
# Systemd script for the DragonX daemon
## Set it up
First set it up as follows:
* Copy dragonxd.service to the systemd user directory, which is /usr/lib/systemd/user directory
## Basic Usage
How to start the script:
`systemctl start --user dragonxd.service`
How to stop the script:
`systemctl stop --user dragonxd.service`
How to restart the script:
`systemctl restart --user dragonxd.service`
## How to watch it as it starts
Use the following on most Linux distros:
`watch systemctl status --user dragonxd.service`
Or watch the log directly:
`tail -f ~/.hush/DRAGONX/debug.log`
## Troubleshooting
* Don't run it with sudo or root, or it won't work with the wallet.

View File

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

View File

@@ -1,17 +1,17 @@
# Hush Files # DragonX Files
* HUSH3.conf: contains configuration settings for hushd * DRAGONX.conf: contains configuration settings for dragonxd
* hushd.pid: stores the process id of hushd while running * dragonxd.pid: stores the process id of dragonxd while running
* blocks/blk000??.dat: block data (custom, 128 MiB per file) * blocks/blk000??.dat: block data (custom, 128 MiB per file)
* blocks/rev000??.dat; block undo data (custom) * blocks/rev000??.dat; block undo data (custom)
* blocks/index/*; block index (LevelDB) * blocks/index/*; block index (LevelDB)
* chainstate/*; block chain state database (LevelDB) * chainstate/*; block chain state database (LevelDB)
* database/*: BDB database environment * database/*: BDB database environment
* db.log: wallet database log file * 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 * fee_estimates.dat: stores statistics used to estimate minimum transaction fees and priorities required for confirmation
* peers.dat: peer IP address database (custom format) * peers.dat: peer IP address database (custom format)
* wallet.dat: personal wallet (BDB) with keys and transactions * 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 * .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 * onion_private_key: cached Tor hidden service private key for `-listenonion`: since 0.12.0

View File

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

View File

@@ -17,10 +17,9 @@ where this data lives on your computer and then move some files around, then res
### On Linux ### On Linux
If you are on Linux, your wallet lives at `~/.hush/HUSH3/wallet.dat` or if you have a really old If you are on Linux, your wallet lives at `~/.hush/DRAGONX/wallet.dat`.
legacy wallet it could be at `~/.komodo/HUSH3/wallet.dat` . We will assume the first location.
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 then copy the wallet from there into a new directory. This is a non-destructive process that creates
a new backup of your wallet. 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! # Make sure your node is not running before doing any of this!
# Doing this while your node is running could corrupt your wallet.dat # Doing this while your node is running could corrupt your wallet.dat
cd ~/.hush cd ~/.hush
mv HUSH3 HUSH3-backup # backup all data mv DRAGONX DRAGONX-backup # backup all data
mkdir HUSH3 # make a new dir mkdir DRAGONX # make a new dir
cp HUSH3-backup/wallet.dat HUSH3/wallet.dat # copy old wallet to 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 At this point restart your node (`dragonxd`) and it will perform a fresh sync using your
and it should perform a fresh sync with your wallet. This will likely take at least wallet. This will likely take at least a few hours or much longer depending on your
a few hours or much longer depending on your internet connection. internet connection.
### On Windows ### 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. 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 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` * 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\HUSH3` * Create a new directory called `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX`
* Copy the file `C:\Users\Admin\AppData\Roaming\Hush\HUSH3-backup\wallet.dat` to `C:\Users\Admin\AppData\Roaming\Hush\HUSH3` * Copy the file `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX-backup\wallet.dat` to `C:\Users\Admin\AppData\Roaming\Hush\DRAGONX`
* Now start the SilentDragon GUI wallet * Now start your DragonX node again

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

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

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) [I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P)
service and connect to such services. service and connect to such services.
@@ -42,13 +42,13 @@ configuration options:
In a typical situation, this suffices: 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 `-i2pacceptincoming=1`, then it will automatically generate a persistent I2P
address and its corresponding private key. The private key will be saved in a 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 I2P address is used for accepting incoming connections and for making outgoing
connections if `-i2pacceptincoming=1`. If `-i2pacceptincoming=0` then only connections if `-i2pacceptincoming=1`. If `-i2pacceptincoming=0` then only
outbound I2P connections are made and a different transient I2P address is used 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 connections are not affected by this option. It can be specified multiple times
to allow multiple networks, e.g. onlynet=onion, onlynet=i2p. 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 There may be fewer I2P peers than Tor or IP ones. Therefore, using I2P alone
peers than Tor or IP ones. Therefore, using I2P alone without other networks may without other networks may
make a node more susceptible to [Sybil make a node more susceptible to [Sybil
attacks](https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack). 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 not know who is connecting to them and can't tell if two connections are from
the same peer or not. 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 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 to make it harder to discriminate, fingerprint or analyze it based on its I2P
address. 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 debug log (grep for `AddLocal`; the I2P address ends in `.b32.i2p`)
- in the i2p/i2pd web console under "SAM Sessions" - 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. RPC.
## Compatibility ## 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. 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, 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 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 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 SAM or other protocols that support ports, a SAM v3.1 peer is connecting to them
on port 0, from source port 0. 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 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 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 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 ## Bandwidth
By default, your node shares bandwidth and transit tunnels with the I2P network 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 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. 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. as much to the I2P network as they consume.
It is possible, though strongly discouraged, to change your I2P router 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. 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 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.

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 dragonxd
Sample init scripts and service configuration for bitcoind
========================================================== ==========================================================
Sample scripts and configuration files for systemd, Upstart and OpenRC Sample scripts and configuration files for systemd, Upstart and OpenRC
can be found in the contrib/init folder. can be found in the contrib/init folder.
contrib/init/bitcoind.service: systemd service unit configuration contrib/init/dragonxd.service: systemd service unit configuration
contrib/init/bitcoind.openrc: OpenRC compatible SysV style init script contrib/init/dragonxd.openrc: OpenRC compatible SysV style init script
contrib/init/bitcoind.openrcconf: OpenRC conf.d file contrib/init/dragonxd.openrcconf: OpenRC conf.d file
contrib/init/bitcoind.conf: Upstart service configuration file contrib/init/dragonxd.conf: Upstart service configuration file
contrib/init/bitcoind.init: CentOS compatible SysV style init script 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 1. Service User
--------------------------------- ---------------------------------
All three startup configurations assume the existence of a "bitcoin" user All startup configurations assume the existence of a "hush" user
and group. They must be created before attempting to use these scripts. 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 2. Configuration
--------------------------------- ---------------------------------
At a bare minimum, bitcoind requires that the rpcpassword setting be set 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 when running as a daemon. If the configuration file does not exist or this
setting is not set, bitcoind will shutdown promptly after startup. 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 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 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 as this password is security critical to securing the wallet should the
wallet be enabled. wallet be enabled.
If bitcoind is run with "-daemon" flag, and no rpcpassword is set, it will 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 print a randomly generated suitable password to stderr. You can also
generate one from the shell yourself like this: generate one from the shell yourself like this:
bash -c 'tr -dc a-zA-Z0-9 < /dev/urandom | head -c32 && echo' bash -c 'tr -dc a-zA-Z0-9 < /dev/urandom | head -c32 && echo'
For an example configuration file that describes the configuration settings, For an example configuration file that describes the configuration settings,
see contrib/debian/examples/bitcoin.conf. see contrib/debian/examples/DRAGONX.conf.
3. Paths 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 Binary: /usr/bin/dragonxd
Configuration file: /etc/bitcoin/bitcoin.conf Configuration file: /etc/dragonx/DRAGONX.conf
Data directory: /var/lib/bitcoind Data directory: /var/lib/dragonxd
PID file: /var/run/bitcoind/bitcoind.pid (OpenRC and Upstart) PID file: /var/run/dragonxd/dragonxd.pid (OpenRC and Upstart)
/var/lib/bitcoind/bitcoind.pid (systemd) /var/lib/dragonxd/dragonxd.pid (systemd)
Lock file: /var/lock/subsys/bitcoind (CentOS) Lock file: /var/lock/subsys/dragonxd (CentOS)
The configuration file, PID directory (if applicable) and data directory 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 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. can then be controlled by group membership.
4. Installing Service Configuration 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 /usr/lib/systemd/system directory, followed by the command
"systemctl daemon-reload" in order to update running systemd configuration. "systemctl daemon-reload" in order to update running systemd configuration.
To test, run "systemctl start bitcoind" and to enable for system startup run To test, run "systemctl start dragonxd" and to enable for system startup run
"systemctl enable bitcoind" "systemctl enable dragonxd"
4b) OpenRC 4b) OpenRC
Rename bitcoind.openrc to bitcoind and drop it in /etc/init.d. Double Rename dragonxd.openrc to dragonxd and drop it in /etc/init.d. Double
check ownership and permissions and make it executable. Test it with check ownership and permissions and make it executable. Test it with
"/etc/init.d/bitcoind start" and configure it to run on startup with "/etc/init.d/dragonxd start" and configure it to run on startup with
"rc-update add bitcoind" "rc-update add dragonxd"
4c) Upstart (for Debian/Ubuntu based distributions) 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. it will automatically start on reboot.
NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they 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 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 Using this script, you can adjust the path and flags to the dragonxd program by
setting the BITCOIND and FLAGS environment variables in the file setting the HUSHD_BIN and HUSHD_OPTS environment variables in the file
/etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here. /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 5. Auto-respawn
----------------------------------- -----------------------------------
Auto respawning is currently only configured for Upstart and systemd. Auto respawning is currently only configured for Upstart and systemd.
Reasonable defaults have been chosen but YMMV. Reasonable defaults have been chosen but YMMV.
</content>
</invoke>

View File

@@ -1 +1 @@
dist_man1_MANS=hushd.1 hush-cli.1 hush-tx.1 dist_man1_MANS=dragonxd.1 dragonx-cli.1 dragonx-tx.1

View File

@@ -1,21 +1,21 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.13. .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.1.
.TH HUSH-CLI "1" "July 2025" "hush-cli v3.10.4" "User Commands" .TH DRAGONX "1" "July 2026" "DragonX RPC client version v1.0.3-95aeaed0c-dirty" "User Commands"
.SH NAME .SH NAME
hush-cli \- manual page for hush-cli v3.10.4 DragonX \- manual page for DragonX RPC client version v1.0.3-95aeaed0c-dirty
.SH DESCRIPTION .SH DESCRIPTION
Hush RPC client version v3.10.4\-7e63e2f01\-dirty DragonX RPC client version v1.0.3\-95aeaed0c\-dirty
.PP .PP
In order to ensure you are adequately protecting your privacy when using Hush, In order to ensure you are adequately protecting your privacy when using
please see <https://hush.is/security/>. DragonX, please see <https://dragonx.is/security/>.
.SS "Usage:" .SS "Usage:"
.TP .TP
hush\-cli [options] <command> [params] dragonx\-cli [options] <command> [params]
Send command to Hush Send command to DragonX
.TP .TP
hush\-cli [options] help dragonx\-cli [options] help
List commands List commands
.TP .TP
hush\-cli [options] help <command> dragonx\-cli [options] help <command>
Get help for a command Get help for a command
.SH OPTIONS .SH OPTIONS
.HP .HP
@@ -25,7 +25,7 @@ This help message
.HP .HP
\fB\-conf=\fR<file> \fB\-conf=\fR<file>
.IP .IP
Specify configuration file (default: HUSH3.conf) Specify configuration file (default: DRAGONX.conf)
.HP .HP
\fB\-datadir=\fR<dir> \fB\-datadir=\fR<dir>
.IP .IP
@@ -47,7 +47,7 @@ Send commands to node running on <ip> (default: 127.0.0.1)
.HP .HP
\fB\-rpcport=\fR<port> \fB\-rpcport=\fR<port>
.IP .IP
Connect to JSON\-RPC on <port> (default: 18030 ) Connect to JSON\-RPC on <port> (default: 21769 )
.HP .HP
\fB\-rpcwait\fR \fB\-rpcwait\fR
.IP .IP
@@ -70,20 +70,25 @@ Timeout in seconds during HTTP requests, or 0 for no timeout. (default:
.IP .IP
Read extra arguments from standard input, one per line until EOF/Ctrl\-D Read extra arguments from standard input, one per line until EOF/Ctrl\-D
(recommended for sensitive information such as passphrases) (recommended for sensitive information such as passphrases)
.PP
In order to ensure you are adequately protecting your privacy when using
DragonX, please see <https://dragonx.is/security/>.
.SH COPYRIGHT .SH COPYRIGHT
Copyright \(co 2024\-2026 The DragonX Developers
In order to ensure you are adequately protecting your privacy when using Hush, .PP
please see <https://hush.is/security/>. .br
Copyright \(co 2016\-2024 Duke Leto and The Hush Developers
Copyright (C) 2016-2025 Duke Leto and The Hush Developers .PP
.br
Copyright (C) 2016-2020 jl777 and SuperNET developers Copyright \(co 2016\-2020 jl777 and SuperNET developers
.PP
Copyright (C) 2016-2018 The Zcash developers .br
Copyright \(co 2016\-2018 The Zcash developers
Copyright (C) 2009-2014 The Bitcoin Core developers .PP
.br
Copyright \(co 2009\-2014 The Bitcoin Core developers
.PP
This is experimental Free Software! Fuck Yeah!!!!! This is experimental Free Software! Fuck Yeah!!!!!
.PP
Distributed under the GPLv3 software license, see the accompanying file COPYING Distributed under the GPLv3 software license, see the accompanying file COPYING
or <https://www.gnu.org/licenses/gpl-3.0.en.html>. or <https://www.gnu.org/licenses/gpl\-3.0.en.html>.

View File

@@ -1,9 +1,9 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.13. .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.1.
.TH HUSH-TX "1" "July 2025" "hush-tx v3.10.4" "User Commands" .TH DRAGONX-TX "1" "July 2026" "dragonx-tx v1.0.3-4caf2fc68" "User Commands"
.SH NAME .SH NAME
hush-tx \- manual page for hush-tx v3.10.4 dragonx-tx \- DragonX transaction utility
.SH DESCRIPTION .SH DESCRIPTION
hush\-tx utility version v3.10.4\-7e63e2f01\-dirty hush\-tx utility version v1.0.3\-4caf2fc68
.SS "Usage:" .SS "Usage:"
.TP .TP
hush\-tx [options] <hex\-tx> [commands] hush\-tx [options] <hex\-tx> [commands]
@@ -84,20 +84,3 @@ Load JSON file FILENAME into register NAME
set=NAME:JSON\-STRING set=NAME:JSON\-STRING
.IP .IP
Set register NAME to given JSON\-STRING Set register NAME to given JSON\-STRING
.SH COPYRIGHT
In order to ensure you are adequately protecting your privacy when using Hush,
please see <https://hush.is/security/>.
Copyright (C) 2016-2025 Duke Leto and The Hush Developers
Copyright (C) 2016-2020 jl777 and SuperNET developers
Copyright (C) 2016-2018 The Zcash developers
Copyright (C) 2009-2014 The Bitcoin Core developers
This is experimental Free Software! Fuck Yeah!!!!!
Distributed under the GPLv3 software license, see the accompanying file COPYING
or <https://www.gnu.org/licenses/gpl-3.0.en.html>.

View File

@@ -1,16 +1,16 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.13. .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.1.
.TH HUSHD "1" "July 2025" "hushd v3.10.4" "User Commands" .TH DRAGONX "1" "July 2026" "DragonX Daemon version v1.0.3-4caf2fc68" "User Commands"
.SH NAME .SH NAME
hushd \- manual page for hushd v3.10.4 DragonX \- manual page for DragonX Daemon version v1.0.3-4caf2fc68
.SH DESCRIPTION .SH DESCRIPTION
Hush Daemon version v3.10.4\-7e63e2f01\-dirty DragonX Daemon version v1.0.3\-4caf2fc68
.PP .PP
In order to ensure you are adequately protecting your privacy when using Hush, In order to ensure you are adequately protecting your privacy when using
please see <https://hush.is/security/>. DragonX, please see <https://dragonx.is/security/>.
.SS "Usage:" .SS "Usage:"
.TP .TP
hushd [options] dragonxd [options]
Start a Hush Daemon Start DragonX Daemon
.SH OPTIONS .SH OPTIONS
.HP .HP
\-? \-?
@@ -32,11 +32,11 @@ How thorough the block verification of \fB\-checkblocks\fR is (0\-4, default: 3)
.HP .HP
\fB\-clientname=\fR<SomeName> \fB\-clientname=\fR<SomeName>
.IP .IP
Full node client name, default 'GoldenSandtrout' Full node client name, default 'DragonX'
.HP .HP
\fB\-conf=\fR<file> \fB\-conf=\fR<file>
.IP .IP
Specify configuration file (default: HUSH3.conf) Specify configuration file (default: DRAGONX.conf)
.HP .HP
\fB\-daemon\fR \fB\-daemon\fR
.IP .IP
@@ -52,7 +52,11 @@ Specify directory to be used when exporting data
.HP .HP
\fB\-dbcache=\fR<n> \fB\-dbcache=\fR<n>
.IP .IP
Set database cache size in megabytes (4 to 16384, default: 512) Set database cache size in megabytes (4 to 16384). Default: adaptive \-
uses most free RAM to speed up initial block download (far fewer
UTXO flushes to disk) and automatically shrinks if other
applications need memory, always leaving a reserve free. Setting
a fixed value disables adaptive sizing.
.HP .HP
\fB\-loadblock=\fR<file> \fB\-loadblock=\fR<file>
.IP .IP
@@ -78,9 +82,15 @@ applied)
.HP .HP
\fB\-par=\fR<n> \fB\-par=\fR<n>
.IP .IP
Set the number of script verification threads (\fB\-8\fR to 16, 0 = auto, <0 = Set the number of script verification threads (\fB\-4\fR to 16, 0 = auto, <0 =
leave that many cores free, default: 0) leave that many cores free, default: 0)
.HP .HP
\fB\-randomxverifythreads=\fR<n>
.IP
Number of threads for parallel RandomX PoW pre\-verification of
post\-checkpoint blocks during sync (0 = inline only, max 16,
default: same as \fB\-par\fR)
.HP
\fB\-pid=\fR<file> \fB\-pid=\fR<file>
.IP .IP
Specify pid file (default: hushd.pid) Specify pid file (default: hushd.pid)
@@ -337,6 +347,40 @@ Do not load the wallet and disable wallet RPC calls
.IP .IP
Set key pool size to <n> (default: 100) Set key pool size to <n> (default: 100)
.HP .HP
\fB\-hdtransparent\fR
.IP
Derive transparent addresses from the HD seed so they can be recovered
from it (default: 1)
.HP
\fB\-hdseed=\fR<hex>
.IP
Restore a fresh/empty wallet from a 32\- or 64\-byte HD seed hex (the
value shown in z_exportwallet's '# HDSeed=' line). WARNING:
exposes the seed to your shell history and process list.
.HP
\fB\-mnemonic=\fR<words>
.IP
Restore/create a fresh/empty wallet from a BIP39 seed phrase, compatible
with SilentDragonXLite (English, no passphrase). WARNING: exposes
the phrase to your shell history and process list; prefer
DRAGONX.conf with tight permissions.
.HP
\fB\-usemnemonic\fR
.IP
Create new wallets from a fresh BIP39 seed phrase so the 24 words can be
exported (z_exportmnemonic) and used in SilentDragonXLite
(default: 0)
.HP
\fB\-hdtransparentgaplimit=\fR<n>
.IP
On \fB\-mnemonic\fR/\-hdseed restore, pre\-derive this many HD transparent keys
so a rescan can find coinbase paid to them (default: 1000)
.HP
\fB\-mnemonicsaplinggap=\fR<n>
.IP
On \fB\-mnemonic\fR/\-hdseed restore, pre\-derive this many shielded (Sapling)
addresses so a rescan can find notes sent to them (default: 100)
.HP
\fB\-consolidation\fR \fB\-consolidation\fR
.IP .IP
Enable auto Sapling note consolidation (default: false) Enable auto Sapling note consolidation (default: false)
@@ -649,8 +693,8 @@ multiple times (default: bind to all interfaces)
.HP .HP
\fB\-stratumport=\fR<port> \fB\-stratumport=\fR<port>
.IP .IP
Listen for Stratum work requests on <port> (default: 19031 or testnet: Listen for Stratum work requests on <port> (default: 22769 or testnet:
19031) 22769)
.HP .HP
\fB\-stratumallowip=\fR<ip> \fB\-stratumallowip=\fR<ip>
.IP .IP
@@ -659,7 +703,7 @@ single IP (e.g. 1.2.3.4), a network/netmask (e.g.
1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). This 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). This
option can be specified multiple times option can be specified multiple times
.PP .PP
Hush Arrakis Chain options: DragonX Chain options:
.HP .HP
\fB\-ac_algo\fR \fB\-ac_algo\fR
.IP .IP
@@ -686,6 +730,12 @@ OP_RETURN minimum fee per tx, regardless of tx size, default is 1 coin
.IP .IP
CODA integration CODA integration
.HP .HP
\fB\-ac_clearnet\fR
.IP
Enable or disable clearnet connections for the entire blockchain.
Setting to 0 will disable clearnet and use sane defaults for
Tor/i2p and require all nodes to do the same (default: 1)
.HP
\fB\-ac_decay\fR \fB\-ac_decay\fR
.IP .IP
Percentage of block reward decrease at each halving Percentage of block reward decrease at each halving
@@ -754,20 +804,25 @@ Starting supply, default is 10
\fB\-ac_txpow\fR \fB\-ac_txpow\fR
.IP .IP
Enforce transaction\-rate limit, default 0 Enforce transaction\-rate limit, default 0
.PP
In order to ensure you are adequately protecting your privacy when using
DragonX, please see <https://dragonx.is/security/>.
.SH COPYRIGHT .SH COPYRIGHT
Copyright \(co 2024\-2026 The DragonX Developers
In order to ensure you are adequately protecting your privacy when using Hush, .PP
please see <https://hush.is/security/>. .br
Copyright \(co 2016\-2024 Duke Leto and The Hush Developers
Copyright (C) 2016-2025 Duke Leto and The Hush Developers .PP
.br
Copyright (C) 2016-2020 jl777 and SuperNET developers Copyright \(co 2016\-2020 jl777 and SuperNET developers
.PP
Copyright (C) 2016-2018 The Zcash developers .br
Copyright \(co 2016\-2018 The Zcash developers
Copyright (C) 2009-2014 The Bitcoin Core developers .PP
.br
Copyright \(co 2009\-2014 The Bitcoin Core developers
.PP
This is experimental Free Software! Fuck Yeah!!!!! This is experimental Free Software! Fuck Yeah!!!!!
.PP
Distributed under the GPLv3 software license, see the accompanying file COPYING Distributed under the GPLv3 software license, see the accompanying file COPYING
or <https://www.gnu.org/licenses/gpl-3.0.en.html>. or <https://www.gnu.org/licenses/gpl\-3.0.en.html>.

View File

@@ -1,25 +1,31 @@
# Hush Overview # DragonX Overview
## Mining Algorithm ## 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 ## Block time
75 seconds 36 seconds
## Block reward
3 DRAGONX per block, halving every 3,500,000 blocks.
## Block size ## Block size
4MB 4 MB (consensus maximum)
## P2P ## P2P
TLS1.3 via WolfSSL is enforced for all network connections as of v3.6.1 . TLS1.3 via WolfSSL is enforced for all network connections. Many ciphersuites are
Many ciphersuites are technically supported by TLS1.3 but many of them technically supported by TLS1.3 but many of them are ancient, proved to be less secure
are ancient, proved to be less secure than intended or likely backdoored. than intended or likely backdoored. DragonX only uses what are widely considered to be the
Hush only uses what are widely considered to be the most secure and [best ciphersuites](https://ciphersuite.info/cs/). 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: time a new connection to a peer is created:
* `TLS_AES_256_GCM_SHA384` * `TLS_AES_256_GCM_SHA384`
@@ -35,10 +41,18 @@ IP address owns which addresses.
## RPC ## 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 ## Consensus
Hush is a mandatory privacy blockchain as of Block 340000 (Nov 2020), DragonX is a fully private blockchain from genesis. The consensus parameter
which means you can only send to a shielded address, never to a transparent `ac_private=1` is active from block 1 and Sapling is active at height 1, so every
address. This is enforced via consensus rules and sometimes called "z2z". 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).

View File

@@ -1,28 +1,28 @@
# Hush Payment API # DragonX Payment API
## Overview ## 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) * 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) * 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 ## 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. 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 nodes wallet, consider using getnewaddress or z_getnewaddress to obtain a new address for each user. Also consider mapping multiple addresses to each user. To support multiple users in a single nodes 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]. Optional parameters are denoted in [square brackets].
@@ -39,7 +39,7 @@ RPC parameter conventions:
* taddr : Transparent address * taddr : Transparent address
* zaddr : Private address * zaddr : Private address
* address : Accepts both private and transparent addresses. * 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. * 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 ### Accounting
@@ -53,18 +53,18 @@ z_gettotalbalance<br>| [minconf=1] | Return the total value of funds stored in t
Command | Parameters | Description 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 nodes wallet.<br><br>Output:<br>zN68D8hSs3... z_getnewaddress | | Return a new Sapling zaddr for sending and receiving payments. The spending key for this zaddr will be added to the nodes wallet.<br><br>Output:<br>zs1...
z_listaddresses | | Returns a list of all the zaddrs in this nodes wallet for which you have a spending key.<br><br>Output:<br>{ [“z123…”, “z456...”, “z789...”] } z_listaddresses | | Returns a list of all the zaddrs in this nodes wallet for which you have a spending key.<br><br>Output:<br>{ [“zs1…”, “zs1...”, “zs1...”] }
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_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 ### Key Management
Command | Parameters | Description 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 nodes 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_exportkey | zaddr | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Return a zkey for a given zaddr belonging to the nodes 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 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_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_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 hushds 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 dragonxds 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_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. 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 nodes 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_listreceivedbyaddress<br> | zaddr [minconf=1] | Return a list of amounts received by a zaddr belonging to the nodes 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_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. 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 ### Operations
@@ -105,13 +105,13 @@ It is currently not possible to cancel operations.
Command | Parameters | Description 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_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…”, … ] 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 ## 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 ### z_sendmany error codes

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

View File

@@ -1,4 +1,4 @@
# Hush Release Process # DragonX Release Process
## High-Level Philosophy ## 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. 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 checkout dev
git pull # make sure dev is up to date git pull # make sure dev is up to date
git checkout master git checkout dragonx
git pull # make sure master is up to date git pull # make sure dragonx is up to date
git diff dev...master # look at the set of changes which exist in master but not dev 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 checkout dev
git merge master git merge dragonx
git push origin dev 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 ### Git Issues
@@ -65,21 +65,21 @@ Install deps on Linux:
- Edit contrib/seeds/nodes_main.txt - Edit contrib/seeds/nodes_main.txt
- Run "make seeds" - Run "make seeds"
- Commit the result - 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` - 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` - 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" - 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 - 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 `make manpages`, commit + push results - Run `./util/gen-manpages.sh`, commit + push results
- hushd must be running so the script can automatically get the correct version number - There is a hack in the script where you can hardcode a version number if dragonxd isn't compiled on this machine
- There is a hack in the script where you can hardcode a version number if hushd isn't running. - Comment out the version line and uncomment the line above it with a hardcoded version number
- Comment out the HUSHVER 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 - 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 - Update checkpoints in src/chainparams.cpp via util/checkpoints.pl
- Run "./util/checkpoints.pl help" to get example usage - 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 - dragonxd must be running to run this script, since it uses dragonx-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 - 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 - 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 - 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 - 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" - 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 - 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` - 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.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 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 - 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
@@ -97,17 +96,16 @@ Install deps on Linux:
- They only provide limited security, because they talk about the past, not future block heights. - They only provide limited security, because they talk about the past, not future block heights.
- Try to generate checkpoints as close to the release as possible, so you can have a recent block height be protected. - 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 - 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 copyright years if applicable. Example: `./util/update-copyrights.h 2022 2023`
- Update doc/relnotes/README.md - 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 - Do a fresh clone and fresh sync with new checkpoints
- Stop node, wait 20 minutes, and then do a partial 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 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 merge if "git pull" creates a merge conflict
- The above command will not push if there is a problem with merging dev - 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 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 `v3.9.2` - 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 - Use util/gen-linux-binary-release.sh to make a Linux release binary
- Upload Linux binary to Gitea release and add SHA256 sum - Upload Linux binary to Gitea release and add SHA256 sum
- Create an x86 Debian package for the release: - Create an x86 Debian package for the release:
@@ -119,18 +117,14 @@ Install deps on Linux:
- Add SHA256 checksum of .deb to release - 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 - 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 - 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 ## Platform-specific notes
- Use `./util/build-mac.sh` to compile on Apple/Mac systems - Use `./util/build-mac.sh` to compile on Apple/Mac systems
- Use `./util/build-win.sh` to build on Windows - 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 ## Optional things
### Updating RandomX ### 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

View File

@@ -10,24 +10,35 @@ and no longer on Github, since they banned Duke Leto and
also because they censor many people around the world and work with also because they censor many people around the world and work with
evil organizations. They also use all your "private" repos to train their AI. evil organizations. They also use all your "private" repos to train their AI.
# Hush 3.10.5 "" # Hush 3.10.5 "Atelic Alpaca"
This is an OPTIONAL but RECOMMENDED upgrade. This is an OPTIONAL but RECOMMENDED upgrade.
* DragonX is no longer supported by this codebase
* DragonX devs have forked our code and we wish them the best
* Find the latest place to download a DragonX full node via dragonx.is
* Concurrent `z_sendmany` now works * Concurrent `z_sendmany` now works
* A longstanding bug relating to run multiple `z_sendmany` operations at * A longstanding bug relating to run multiple `z_sendmany` operations at
once has been fixed. You can now queue up many `z_sendmany` operations once has been fixed. You can now queue up many `z_sendmany` operations
and they will succeed because they now understand how to avoid spending and they will succeed because they now understand how to avoid spending
coins that another `z_sendmany` process is trying to spend. coins that another `z_sendmany` process is trying to spend.
* Updated Autonomous System Map (asmap)
* New RPC `z_listlockunspent` * New RPC `z_listlockunspent`
* Lists shielded notes (coins inside a zaddr) which are temporarily unspendable because an RPC process is currently trying to spend them. * Lists shielded notes (coins inside a zaddr) which are temporarily unspendable because an RPC process is currently trying to spend them.
* If that operation succeeds, they will become spent. If it fails they will be unlocked and become spendable again. * If that operation succeeds, they will become spent. If it fails they will be unlocked and become spendable again.
* Fixed DragonX checkpoints * New option to `z_shieldcoinbase` allows privately donating a percentage of coinbase funds during shielding
* Hush checkpoints were mistakenly listed as checkpoints in the 3.10.4 * This new option defaults to OFF and allows CLI users to opt-in to donating between 0% and 10% of coinbase funds to developers
release, which caused some nodes to be unable to sync. * No GUI currently utilizes this but that feature is planned for SD
* This release fixes this issue. * The donation has extremely good privacy:
* It cannot be determined from public blockchain data if a donation is being made, as it takes the place of a Sietch output
* It cannot be determined from public blockchain data the amount of the donation
* Donations do not create new transactions, do not use additional blockspace and cannot be detected by anyone but the sender or reciever
* New HAC option `ac_clearnet` can be used to disable clearnet networking for an entire blockchain instead of just a single node
* Updated test framework and tests which allowed the fixing of the `z_sendmany` bug above * Updated test framework and tests which allowed the fixing of the `z_sendmany` bug above
* Faster compiling of RandomX internals * Faster compiling of RandomX internals
* GMP dependency removed, as it is no longer needed
* Hush is now compatible with GCC15 and now correctly supports customizing the compiler for a build via the CC env var
* New HTML man pages are now available at doc/man/hushd.html and doc/man/hush-cli.html
# Hush 3.10.4 "Hazy Hākuturi" # Hush 3.10.4 "Hazy Hākuturi"

View File

@@ -1,24 +1,17 @@
#Security Warnings # Security Warnings
## Security Audits ## Security Audits
Hush has not been subjected to a formal third-party security review! But the DragonX has not been subjected to a formal third-party security review. Some of
some of the Zcash and Komodo source code it is based on has. the Bitcoin, Zcash, Komodo, and Hush source code it is derived from has been
audited upstream, and DragonX integrates relevant fixes and recommendations from
Hush does our best to integrate fixes and recommendations from upstream audits those audits where they apply.
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>
## Wallet Encryption ## 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 - Encrypted wallets are unable to correctly detect shielded spends (due to the
nature of unlinkability of ShieldedSpends) and can incorrectly show larger 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 ## 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 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: be able to:
- Determine the values of your secret spending keys, as well as which notes you - 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++. operation. This is due to probable side-channel leakage in C++.
- Determine which notes you own by observing cache side-channel information - Determine which notes you own by observing cache side-channel information
@@ -61,7 +54,7 @@ be able to:
each note ciphertext on the blockchain. each note ciphertext on the blockchain.
You should ensure no other users have the ability to execute code (even 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. vulnerabilities are fully analyzed and fixed.
## REST Interface ## REST Interface
@@ -72,13 +65,16 @@ security review.
## RPC Interface ## 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 ## Logging z_* RPC calls

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

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

View File

@@ -2,47 +2,61 @@
**Summary** **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** **Who should read this document**
Miners, Mining pools, Online wallets Miners, mining pools, online wallets.
## Background ## 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 ## 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 ## 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) 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 ## Examples
Sweep up coinbase UTXOs from a transparent address you use for mining: 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: 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 ### Asynchronous Call
@@ -50,7 +64,7 @@ The `z_shieldcoinbase` RPC call is an asynchronous call, so you can queue up mul
When you invoke 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: 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. 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. 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. 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 ### Anatomy of a z_shieldcoinbase transaction

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 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/test/``; tests using the Google Test/Google Mock
framework are under ``src/gtest/`` and ``src/wallet/gtest/``. The latter framework 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. RPC tests are implemented in Python under the ``qa/rpc-tests/`` directory.
# Example # 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 ./qa/pull-tester/rpc-tests.sh dpowconfs

View File

@@ -1,21 +1,20 @@
# Tor # 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 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. configure Tor.
## Compatibility ## Compatibility
- Starting with version 3.9.3, Hush only supports Tor version 3 hidden - DragonX only supports Tor version 3 hidden services (Tor v3). Tor v2
services (Tor v3). Tor v2 addresses are ignored by Hush and neither addresses are ignored by DragonX and neither relayed nor stored.
relayed nor stored.
- Tor removed v2 support beginning with version 0.4.6. - 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 "localaddresses" output of RPC `getnetworkinfo`
- in the debug log (grep for "AddLocal"; the Tor address ends in `.onion`) - 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, network. This can be useful to see how many onion peers your node knows,
e.g. for `-onlynet=onion`. 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. outgoing connections, but more is possible.
-proxy=ip:port Set the proxy server. If SOCKS5 is selected (default), this proxy -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: 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 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 service to listen on. The goal is to increase the number of available
onion nodes. 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 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 `-listenonion=0`. If it is not disabled, it can be configured using the
`-torcontrol` and `-torpassword` settings. `-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 ### Control Port
@@ -104,20 +103,20 @@ DataDirectoryGroupReadable 1
### Authentication ### Authentication
Connecting to Tor's control socket API requires one of two 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. configuration option.
#### Cookie authentication #### 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 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 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 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 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 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 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: 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 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} usermod -a -G ${TORGROUP} ${USER}
``` ```
Then restart the computer (or log out) and log in as the `${USER}` that will run Then restart the computer (or log out) and log in as the `${USER}` that will run
hushd. dragonxd.
#### `torpassword` authentication #### `torpassword` authentication
@@ -155,22 +154,22 @@ Manual](https://2019.www.torproject.org/docs/tor-manual.html.en) for more
details). 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. 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): 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 HiddenServicePort 18030 127.0.0.1:18032
The directory can be different of course, but virtual port numbers should be equal to 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). 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 this option, and this can be an onion address. Given the above
configuration, you can find your onion address in 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 coming from unroutable addresses (such as 127.0.0.1, where the
Tor proxy typically runs), onion addresses are given Tor proxy typically runs), onion addresses are given
preference for your node to advertise itself with. 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: 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 (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 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: 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 If you don't care too much about hiding your node, and want to be reachable on IPv4
as well, use `discover` instead: 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`). 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 If you only want to use Tor to reach .onion addresses, but not use it as a proxy
for normal IPv4/IPv6 communication, use: 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 ## 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. 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 Otherwise it is trivial to link them, which may reduce privacy. Onion
services created automatically (as in section 2) always have only one port services created automatically (as in section 2) always have only one port

View File

@@ -1,6 +1,6 @@
# Translation Strings Policy # 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? ## How to translate?

View File

@@ -2,37 +2,42 @@
## Overview ## 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). 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 ## 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` `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` ### Using `backupwallet`
To create a backup of your wallet, use: 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. 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`. 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: 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. 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: 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` ### 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. 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. This will return the private key and will not create a new file.
To import a private key for a shielded address, use: 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. 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: 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: 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. 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: See the command's help documentation for instructions on fine-tuning the wallet rescan:
`hush-cli help importprivkey` `dragonx-cli help importprivkey`
### Using `dumpwallet` ### Using `dumpwallet`

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