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

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

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

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

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

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

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

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
DanS
2026-07-21 13:59:06 -05:00
parent bf3c33c53a
commit 46693a355a
76 changed files with 829 additions and 1416 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
doc/release-process.md
View File

@@ -1,4 +1,4 @@
# Hush Release Process
# DragonX Release Process
## High-Level Philosophy
@@ -6,39 +6,39 @@ Beware of making high-risk changes (such as consensus changes, p2p layer changes
It is best to keep doc/relnotes/README.md up to date as changes and bug fixes are made. It's more work to summarize all changes and bugfixes just before the release.
## Check for changes on master that should be on dev
## Branch model
Often there are trivial changes made directly on master, such as documentation changes. In theory, no code changes should happen on master without being on dev first, but it's better to be safe than sorry. We want the dev branch which undergoes testing to be as close as possible to what the master branch will become, so we don't want to merge dev into master and just assume everything works. So it's best to merge the master branch into dev just before merging the dev branch into master.
Development happens on the `dev` branch. Releases are cut on the default branch, `dragonx`. There is no `master` branch. Code changes should land on `dev` first and undergo testing before being merged into `dragonx`.
To check if the master branch has any changes that the dev branch does not:
## Check for changes on dragonx that should be on dev
Occasionally trivial changes are made directly on the `dragonx` branch, such as documentation changes. In theory, no code changes should happen on `dragonx` without being on `dev` first, but it's better to be safe than sorry. We want the `dev` branch which undergoes testing to be as close as possible to what the `dragonx` branch will become, so we don't want to merge `dev` into `dragonx` and just assume everything works. So it's best to merge the `dragonx` branch into `dev` just before merging the `dev` branch into `dragonx`.
To check if the `dragonx` branch has any changes that the `dev` branch does not:
```
# this assumes you are working with https://git.hush.is/hush/hush3 as your remote
git checkout dev
git pull # make sure dev is up to date
git checkout master
git pull # make sure master is up to date
git diff dev...master # look at the set of changes which exist in master but not dev
```
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:
```
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
# this assumes you are working with https://git.dragonx.is/DragonX/dragonx as your remote
git checkout dev
git merge master
git pull # make sure dev is up to date
git checkout dragonx
git pull # make sure dragonx is up to date
git diff dev...dragonx # look at the set of changes which exist in dragonx but not dev
```
If the last command has no output, congrats, there is nothing to do. If the last command has output, then you should merge `dragonx` into `dev`:
```
git checkout dev
git merge dragonx
git push origin dev
```
The `--no-ff` flag above makes sure to make a merge commit, no matter what, even if a "fast forward" could be done. For those in the future looking back, it's much better to see evidence of when branches were merged.
Use the `--no-ff` flag when merging `dev` into `dragonx` for a release (see below). The `--no-ff` flag makes sure to make a merge commit, no matter what, even if a "fast forward" could be done. For those in the future looking back, it's much better to see evidence of when branches were merged.
### Git Issues
Look for Git issues that should be fixed in the next release. Especially low-risk and simple things, like documentation changes, improvements to error messages and RPC help output.
Look for Git issues that should be fixed in the next release. Especially low-risk and simple things, like documentation changes, improvements to error messages and RPC help output.
### Pre-release checklist:
* Is this release changing consensus rules? Definitely update protocol version.
@@ -65,21 +65,21 @@ Install deps on Linux:
- Edit contrib/seeds/nodes_main.txt
- Run "make seeds"
- Commit the result
- Update version in configure.ac and src/clientversion.h to update the hushd version
- Update version in configure.ac and src/clientversion.h to update the dragonxd version
- In src/clientversion.h you update `CLIENT_VERSION_*` variables. Usually you will just update `CLIENT_VERSION_REVISION`
- If there is a consensus change, it may be a good idea to update `CLIENT_VERSION_MINOR` or `CLIENT_VERSION_MAJOR`
- To make a pre-release "beta" you can modify `CLIENT_VERSION_BUILD` but that is rarely done in Hush world.
- To make a pre-release "beta" you can modify `CLIENT_VERSION_BUILD` but that is rarely done.
- A `CLIENT_VERSION_BUILD` of 50 means "actual non-beta release"
- Make sure to keep the values in configure.ac and src/clientversion.h the same. The variables are prefixed wth an underscore in configure.ac
- Run `./util/gen-manpages.sh`, commit + push results
- There is a hack in the script where you can hardcode a version number if hushd isn't compiled on this machine
- Comment out the HUSHVER line and uncomment the line above it with a hardcoded version number
- There is a hack in the script where you can hardcode a version number if dragonxd isn't compiled on this machine
- Comment out the version line and uncomment the line above it with a hardcoded version number
- PROTIP: Man page creation must be done after updating the version number and recompiling and before Debian package creation
- TODO: How to regenerate html man pages?
- Update checkpoints in src/chainparams.cpp via util/checkpoints.pl
- Run "./util/checkpoints.pl help" to get example usage
- hushd must be running to run this script, since it uses hush-cli to get the data
- Look for line which says "END HUSH mainnet checkpoint data" near line 560 in chainparams.cpp , that is where checkpoint data ends
- dragonxd must be running to run this script, since it uses dragonx-cli to get the data
- Look for the line which marks the end of the mainnet checkpoint data in chainparams.cpp, that is where checkpoint data ends
- Find the highest block height of checkpoint data, let's call it HEIGHT
- Run `./util/checkpoints.pl 1000 HEIGHT &> checkpoints.txt` to generate the latest checkpoint data
- To copy the new data from checkpoints.txt into the file, one way in Vim is to type ":r checkpoints.txt" which will read in a file and paste it as the current cursor
@@ -89,7 +89,6 @@ Install deps on Linux:
- By default it will generate checkpoints for every 1000 blocks, the "stride"
- You can get a different "stride" by passing it in as the first arg to the script
- To get checkpoint data for every 5000 blocks: `./util/checkpoints.pl 5000 &> checkpoints.txt`
- Currently checkpoints from before block 340k are given for every 5k blocks to keep the data smaller
- checkpoints.pl will just generate the data you need, it must be manually copied into the correct place
- Checkpoints are a list of block heights and block hashes that tell a full node the correct block history of the blockchain
- Checkpoints make block verification a bit faster, because nodes can say "is this block a descendant of a checkpoint block?" instead of doing full consensus checks, which take more time
@@ -98,15 +97,15 @@ Install deps on Linux:
- Try to generate checkpoints as close to the release as possible, so you can have a recent block height be protected.
- For instance, don't update checkpoints and then do a release a month later. You can always update checkpoint data again or multiple times
- Update doc/relnotes/README.md
- To get the stats of file changes: `git diff --stat master...dev`
- To get the stats of file changes: `git diff --stat dragonx...dev`
- Do a fresh clone and fresh sync with new checkpoints
- Stop node, wait 20 minutes, and then do a partial sync with new checkpoints
- Merge dev into master: `git checkout dev && git pull && git checkout master && git pull && git merge --no-ff dev && git push`
- Merge dev into dragonx: `git checkout dev && git pull && git checkout dragonx && git pull && git merge --no-ff dev && git push`
- The above command makes sure that your local dev branch is up to date before doing anything
- The above command will not merge if "git pull" creates a merge conflict
- The above command will not push if there is a problem with merging dev
- Make Gitea release with git tag from master branch (make sure to merge dev in first)
- Make sure git tag starts with a `v` such as `v3.9.2`
- Make Gitea release with git tag from the dragonx branch (make sure to merge dev in first)
- Make sure git tag starts with a `v` such as `v1.0.3`
- Use util/gen-linux-binary-release.sh to make a Linux release binary
- Upload Linux binary to Gitea release and add SHA256 sum
- Create an x86 Debian package for the release:
@@ -118,18 +117,14 @@ Install deps on Linux:
- Add SHA256 checksum of .deb to release
- Use util/build-debian-package-ARM.sh (does this still work?) to make an ARM Debian package for the release
- Upload the debian packages to the Gitea release page, with SHA256 sums
- Update the rpc.hush.is repo for new release by [following these instructions](https://git.hush.is/hush/rpc.hush.is/src/branch/master/README.md)
- Update https://faq.hush.is/rpc/ for new release after updating the rpc.hush.is repo
## Platform-specific notes
- Use `./util/build-mac.sh` to compile on Apple/Mac systems
- Use `./util/build-win.sh` to build on Windows
- Use [these cross compile instructions](https://git.hush.is/jahway603/hush-docs/src/branch/master/advanced/cross-compile-hush-full-node-to-aarch64-with-docker.md) to build the release for ARMv8 (aarch64) systems, as the current build system does not permit us to natively build this on the SBC device
- Then use `./util/build-debian-package.sh aarch64` to build a Debian package for ARMv8 (aarch64)
## Optional things
### Updating RandomX
If you need to update the source code of our in tree copy of RandomX, see issue https://git.hush.is/hush/hush3/issues/337#issuecomment-5114 for details. Currently we use RandomX v1.2.1 from the official repo at https://github.com/tevador/RandomX/releases/tag/v1.2.1
If you need to update the source code of our in tree copy of RandomX, open an issue in the [DragonX Git repository](https://git.dragonx.is/DragonX/dragonx/issues) to track the details. Currently we use RandomX v1.2.1 from the official repo at https://github.com/tevador/RandomX/releases/tag/v1.2.1