release: bump to v1.3.0 and document the signing step that was never performed

The tree stamped 1.2.0 in both configure.ac and src/clientversion.h, but
v1.2.0 is an annotated tag already pushed at fad05d3ab and dev is 27
commits past it. Both trees therefore produced CLIENT_VERSION 1020050 and
announced an identical /DragonX:1.2.0/ subversion, so a released binary
would have been indistinguishable from the tag on the wire, in
getnetworkinfo, and to the wallet's in-app updater -- destroying the only
provenance check users have: build the tag, compare the binary.

Bump MINOR rather than REVISION: the delta since v1.2.0 adds a subsystem
(RandomX stratum) and a new RPC (stratummine).

  configure.ac, src/clientversion.h  1.2.0 -> 1.3.0 (CLIENT_VERSION 1030050)
  doc/man/*.1                        version strings restamped
  contrib/debian/changelog           1.3.0 entry for the 27 commits
  src/chain.h                        stale "CLIENT_VERSION is 1010050" comment

Man page *content* still needs a real regeneration: util/gen-manpages.sh
requires help2man and built 1.3.0 binaries, so it belongs in the release
build, where it will also pick up the new stratum options.

doc/release-process.md is why v1.1.0 and v1.2.0 were tagged but never
became releases. Followed verbatim it produced a release the wallet
refuses to install:

  - it directed releases to a branch named `dragonx`, which does not
    exist; releases are cut on `master`
  - it never once mentioned signing, yet the updater pins an ed25519 key
    and sets kDaemonRequireSignature = true, so an unsigned release is
    refused outright and every user silently stays on their old daemon
  - it did not require the release tag to be annotated, and genbuild.sh
    calls `git describe` without --tags, so a lightweight tag stamps the
    build `v<older-tag>-<sha>` instead of the release version -- which is
    exactly what happened to v1.0.0 through v1.0.3
  - it referenced util/build-debian-package-ARM.sh, which is not in tree

Adds the signing and checksum-table steps, the annotated-tag requirement
with a `git describe` verification, and the rule that a new version must
exceed every existing tag including unpublished ones.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FU87LdsJZiZkfq1eXubpeo

configure.ac

@@ -2,7 +2,7 @@ dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N)
 AC_PREREQ([2.60])
 define(_CLIENT_VERSION_MAJOR, 1)
 dnl Must be kept in sync with src/clientversion.h , ugh!
-define(_CLIENT_VERSION_MINOR, 2)
+define(_CLIENT_VERSION_MINOR, 3)
 define(_CLIENT_VERSION_REVISION, 0)
 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)))

contrib/debian/changelog

@@ -1,3 +1,31 @@
+dragonx (1.3.0) stable; urgency=medium
+
+  * RandomX stratum mining support: the daemon can serve stratum clients
+    directly, with a reference miner behind the stratummine RPC for testing.
+  * Stratum fixes found by audit: a malformed 63-character job_id no longer
+    aborts the daemon; each block is paid to the miner that actually found it
+    rather than to whichever client asked for work first; and a low-difficulty
+    share is now rejected before it costs a RandomX hash.
+  * Fix -connect never dialing its targets, so a node pinned to specific peers
+    reaches them instead of silently falling through to peer discovery.
+  * Remove roughly 7,100 lines of dead code, including the CBOPRET price
+    validation in the coinbase check, whose guard could not be true on any
+    chain, and adaptive-PoW difficulty logic that DragonX does not enable.
+  * Honor a command-line -rpcpassword across restarts, and fix a misspelled
+    -rpcusername key that silently discarded the configured RPC user.
+  * Default -checkpoints off on regtest so an isolated node leaves initial
+    block download, instead of staying in IBD forever and disabling every
+    operation gated on it.
+  * Release cs_main and the mempool lock on the miner's isStake error paths;
+    the leak presented as a permanent stall rather than a slow response.
+  * Windows cross-build: the mingw target links and finds librustzcash, and a
+    fs::path::c_str() regression in init no longer breaks the build.
+  * Stamp container builds with the real version instead of "-unk".
+  * Repair the qa/rpc-tests harness far enough to start a DragonX node and
+    build the shared test chain; it previously started mainnet nodes.
+
+ -- DragonX Developers <dev@dragonx.is>  Mon, 31 Aug 2026 03:46:19 +0000
+
 dragonx (1.2.0) stable; urgency=medium
 
   * Auto-shield matured coinbase into a wallet-owned Sapling address on a block

doc/man/dragonx-cli.1

@@ -1,9 +1,9 @@
 .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.49.1.
-.TH DRAGONX-CLI "1" "August 2026" "dragonx-cli v1.2.0" "User Commands"
+.TH DRAGONX-CLI "1" "August 2026" "dragonx-cli v1.3.0" "User Commands"
 .SH NAME
-dragonx-cli \- manual page for dragonx-cli v1.2.0
+dragonx-cli \- manual page for dragonx-cli v1.3.0
 .SH DESCRIPTION
-DragonX RPC client version v1.2.0
+DragonX RPC client version v1.3.0
 .PP
 In order to ensure you are adequately protecting your privacy when using
 DragonX, please see <https://dragonx.is/security/>.

doc/man/dragonx-tx.1

@@ -1,9 +1,9 @@
 .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.49.1.
-.TH DRAGONX-TX "1" "August 2026" "dragonx-tx v1.2.0" "User Commands"
+.TH DRAGONX-TX "1" "August 2026" "dragonx-tx v1.3.0" "User Commands"
 .SH NAME
-dragonx-tx \- manual page for dragonx-tx v1.2.0
+dragonx-tx \- manual page for dragonx-tx v1.3.0
 .SH DESCRIPTION
-hush\-tx utility version v1.2.0
+hush\-tx utility version v1.3.0
 .SS "Usage:"
 .TP
 hush\-tx [options] <hex\-tx> [commands]

doc/man/dragonxd.1

@@ -1,9 +1,9 @@
 .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.49.1.
-.TH DRAGONXD "1" "August 2026" "dragonxd v1.2.0" "User Commands"
+.TH DRAGONXD "1" "August 2026" "dragonxd v1.3.0" "User Commands"
 .SH NAME
-dragonxd \- manual page for dragonxd v1.2.0
+dragonxd \- manual page for dragonxd v1.3.0
 .SH DESCRIPTION
-DragonX Daemon version v1.2.0
+DragonX Daemon version v1.3.0
 .PP
 In order to ensure you are adequately protecting your privacy when using
 DragonX, please see <https://dragonx.is/security/>.

doc/release-process.md

@@ -8,32 +8,32 @@ It is best to keep doc/relnotes/README.md up to date as changes and bug fixes ar
 
 ## Branch model
 
-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`.
+Development happens on the `dev` branch. Releases are cut on the default branch, `master`. Code changes should land on `dev` first and undergo testing before being merged into `master`.
 
-## Check for changes on dragonx that should be on dev
+## Check for changes on master 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`.
+Occasionally trivial changes are made directly on the `master` branch, 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`.
 
-To check if the `dragonx` branch has any changes that the `dev` branch does not:
+To check if the `master` branch has any changes that the `dev` branch does not:
 
 ```
 # this assumes you are working with https://git.dragonx.is/DragonX/dragonx as your remote
 git checkout dev
 git pull                  # make sure dev is up to date
-git checkout dragonx
+git checkout master
-git pull                  # make sure dragonx is up to date
+git pull                  # make sure master is up to date
-git diff dev...dragonx    # look at the set of changes which exist in dragonx but not dev
+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 `dragonx` 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 `master` into `dev`:
 
 ```
 git checkout dev
-git merge dragonx
+git merge master
 git push origin dev
 ```
 
-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.
+Use the `--no-ff` flag when merging `dev` into `master` 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
@@ -66,6 +66,7 @@ Install deps on Linux:
    - Run "make seeds"
    - Commit the result
  - Update version in configure.ac and src/clientversion.h to update the dragonxd version
+   - **The new version MUST be higher than every version already tagged**, including tags that were never built or published. Check with `git tag -l --sort=-v:refname | head`. Two trees stamped with the same `CLIENT_VERSION` are indistinguishable on the wire, in `getnetworkinfo`, and to the wallet's in-app updater — and a published archive that does not match its tag destroys the only provenance check users have.
    - 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.
@@ -97,17 +98,27 @@ 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 dragonx...dev`
+   - To get the stats of file changes: `git diff --stat master...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 dragonx: `git checkout dev && git pull && git checkout dragonx && git pull && git merge --no-ff dev && git push`
+ - Merge dev into master: `git checkout dev && git pull && git checkout master && 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 the dragonx branch (make sure to merge dev in first)
+ - Make Gitea release with git tag from the master 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
+   - **The tag MUST be annotated** (`git tag -a v1.3.0 -m 'DragonX v1.3.0'`), not lightweight. `util/genbuild.sh` calls `git describe` *without* `--tags`, which only ever sees annotated tags — a lightweight tag makes the build stamp itself `v<older-tag>-<sha>` instead of the release version. v1.0.0 through v1.0.3 are lightweight, which is why their builds are labelled that way.
- - Upload Linux binary to Gitea release and add SHA256 sum
+   - Verify before building: `git describe` must print exactly the tag, with no `-<n>-g<sha>` suffix.
+ - Use `./build.sh` (container-based, see doc/build-containers.md) or util/gen-linux-binary-release.sh to make a Linux release binary
+ - **Sign every archive and publish the signatures.** This step is mandatory and was missing from this document until v1.3.0 — its absence is why v1.1.0 and v1.2.0 were tagged but never became installable releases.
+   - The wallet's in-app daemon updater pins an ed25519 public key in `ObsidianDragon/src/util/daemon_updater.h` and sets `kDaemonRequireSignature = true`. **An update is refused outright unless a valid `<archive>.sig` is published beside the archive.** No signature means every existing user silently stays on their old daemon.
+   - Sign with `ObsidianDragon/scripts/sign-daemon-release.sh`:
+     - `scripts/sign-daemon-release.sh sign <secret.key> <archive>...` produces `<archive>.sig` (base64 of a detached 64-byte ed25519 signature over the exact archive bytes)
+     - or `scripts/sign-daemon-release.sh release <secret.key> <version>` to zip, sign, and print the checksum table in one step
+   - Keep the secret key offline, mode 600. The matching base64 public key must already be pinned in `kDaemonSignaturePublicKeyBase64`.
+ - Upload each Linux binary archive **and its `.sig`** to the Gitea release
+ - **Paste the SHA-256 checksum table into the release body** as markdown rows of the form `| <archive>.zip | `<sha256hex>` |`. The updater parses this table and will not install an archive that is absent from it.
+ - Confirm the release is actually consumable before announcing it: the updater looks for an asset whose name contains `"-" + platformToken + ".zip"` (`linux-amd64`, `macos`, `win64`). An archive named for a distro variant instead of the platform token is invisible to it.
  - Create an x86 Debian package for the release:
    - Edit contrib/debian/changelog to add information about the new release
    - Use `util/build-debian-package.sh` to make an x86 Debian package for the release
@@ -115,7 +126,7 @@ Install deps on Linux:
    - `lintian` is an optional dependency, it's not needed to build the .deb
    - Upload .deb to Gitea 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
+ - ARM Debian package: `util/build-debian-package-ARM.sh` is referenced here historically but **is not present in the tree**. Skip, or restore the script first.
  - Upload the debian packages to the Gitea release page, with SHA256 sums
 
 ## Platform-specific notes

src/chain.h

@@ -35,7 +35,7 @@ extern bool fZindex;
 // These version thresholds control whether nSproutValue/nSaplingValue are
 // serialized in the block index. They must be <= CLIENT_VERSION or the
 // values will never be persisted, causing nChainSaplingValue to reset
-// to 0 after node restart. DragonX CLIENT_VERSION is 1010050 (v1.1.0.50).
+// to 0 after node restart. DragonX CLIENT_VERSION is 1030050 (v1.3.0.50).
 static const int SPROUT_VALUE_VERSION = 1000000;
 static const int SAPLING_VALUE_VERSION = 1000000;
 // Block-index records written at >= this version store nSaplingValue as a boost::optional

src/clientversion.h

@@ -29,7 +29,7 @@
 //! These need to be macros, as clientversion.cpp's and bitcoin*-res.rc's voodoo requires it
 // Must be kept in sync with configure.ac , ugh!
 #define CLIENT_VERSION_MAJOR 1
-#define CLIENT_VERSION_MINOR 2
+#define CLIENT_VERSION_MINOR 3
 #define CLIENT_VERSION_REVISION 0
 #define CLIENT_VERSION_BUILD 50