This is a released version of Reddcoin Core wallet.
PLEASE take all necessary precautions and make backups of data.
Prebuilt binaries are available from:
https://download.reddcoin.com/bin/reddcoin-core-4.22.9.5/
A maintenance release for the 4.22.9 series. No reindex is required and existing wallet files load unchanged. It does restore one validation check that had been missing, so unlike previous maintenance releases this one is not a no-op for validation - see Proof of Work verification restored below.
If your node unloads or closes wallets while running, upgrade. Doing that on 4.22.9.4 and earlier is a use-after-free.
What is fixed
Six Proof of Stake staking defects. Between them they cost stakes, left wallets holding coins they should have been able to stake, and could crash or hang a node outright.
- Unloading a staking wallet was a use-after-free. The staking thread held a bare
CWallet*, soUnloadWallet()destroyed the wallet while the thread was still dereferencing it. Closing a wallet in the GUI reaches the same code. Shutdown was never affected - this only ever mattered for a runtime unload. unloadwalletcould hang permanently against a staking thread that was still starting up, taking an HTTP worker with it until restart. This was the window left open by fixing the above; both halves are needed.setstaking falsecould not be undone. It ended the staking thread and a subsequenttruecould not bring it back, whilegetstakinginfoand thestakingRPC disagreed about whether the node was staking. A node already running an affected build can recover without restarting by cycling the global switch:staking falsethenstaking true.- The staking thread lifecycle had a data race plus three bookkeeping faults: a stop arriving early left the thread behind, re-enabling a staking wallet launched a duplicate thread, disabling could block the staking RPC for up to a minute, and a locked wallet could never return its thread at all.
- A staked block could be rejected by the node that staked it. A stale tip read meant the coinbase claimed the wrong height, and the node rejected a block it had just staked and signed with
bad-cb-height. Observed twice in ten days on a mainnet staker, 2 of 2311 staked blocks, each one a lost stake. - Orphaned coinstakes are now abandoned when their block is disconnected, instead of by sweeping the entire wallet before every block template. A wallet that was not staking previously never abandoned an orphan while running, so its spendable balance stayed short until the next restart.
Update check security. The check fetched over HTTPS but authenticated nothing - no trust anchors were installed, verification was never requested, and the hostname was never checked against the certificate. Anyone able to intercept the connection could substitute the response, and the most useful thing that buys an attacker is silently suppressing upgrade notices, which is precisely the wrong failure mode for this mechanism. TLS certificates are now verified and SNI is sent. Several related robustness fixes come with it, including a missing timeout and a failed check that rendered as a successful one.
Verified release upgrades. The client can now identify, download and cryptographically verify the release build for the machine it is running on. Nothing is installed and nothing is executed on your behalf - the sequence ends with a verified file on disk and your platform's own next step offered to you.
Releases now carry a BIP340 Schnorr signature over SHA256SUMS, made with an air-gapped key whose public key is compiled into the client. A downloaded artifact is either proven to hash to the digest that key signed for it, or it is deleted. Verification is entirely local: no key server, no network trust, no dependency on the transport. This sits alongside the existing OpenPGP SHA256SUMS.asc, which remains the signature for manual verification.
Descriptor wallet key derivation. Descriptor wallets appended a hardcoded 0' as the BIP44 coin type, inherited from Bitcoin Core, while legacy HD wallets already use Reddcoin's registered SLIP-0044 value of 4'. A single seed produced keys in two different places depending on which wallet type created it, and restoring a descriptor seed into third-party tooling would show an empty wallet. Mainnet descriptor wallets now derive at m/44'/4'/0', m/49'/4'/0' and m/84'/4'/0'.
Existing wallets are unaffected and no migration is needed. A descriptor string is built once at wallet creation and stored, so wallets created before this change keep deriving where their keys already are. Only newly created descriptor wallets use 4'.
GUI status icons. The staking, HD and encryption icons no longer disappear permanently after a wallet unload.
Proof of Work verification restored
CheckBlockHeader was a stub returning true, so a block's claimed nBits was never tested against any actual work and the scrypt hash was never called from validation. The check was removed during the PoSV migration rather than adapted, and nothing was put in its place.
It is restored in the form develop already carries: hash GetPoWHash(), skip Proof of Stake blocks, exempt blocks at or before CHECK_POW_FROM_NTIME to match the historical chain.
This reaches the historical Proof of Work era, mainnet heights up to 260799. Every block produced today is Proof of Stake and carries a versionbits nVersion, so the check is dormant for current blocks and covers exactly the range that was unprotected.
No reindex is required, and this changes nothing about which chain a node accepts - both the mainnet and testnet chains pass it. A voluntary reindex now verifies scrypt Proof of Work for the historical era, which it previously skipped. It is a tightening rather than a relaxation, but it is a change to what the node checks, which is why this release does not claim "no consensus changes".
Upgrading
Please use the download page above rather than the in-app link for this upgrade. The update check improvements shipped in this release, not in the version you are upgrading from.
macOS: this build is signed but not notarised
The dmg carries a valid Developer ID signature, but it has not been through Apple's notarisation service. On macOS 10.15 and later you will see "cannot be opened because the developer cannot be verified" on first launch.
To open it: right click (or control click) Reddcoin-Qt in Applications, choose Open, then confirm. This is only needed once.
Verifying your download
SHA256SUMS covers every published build output:
https://download.reddcoin.com/bin/reddcoin-core-4.22.9.5/SHA256SUMS
3623642ec00b2459eb54a720141211d0368237ded688e0c1c76169663a803aaa reddcoin-4.22.9.5-win64-setup-signed.exe
6a89be0099053206cb0cb20e49cf6c8b6437cd3fa712fc9af2a2bdd0e217a719 reddcoin-4.22.9.5-osx-signed.dmg
7fdf030710f0fee778f80823ef1e56b1883e458cfa0180d133d95984f76ec255 reddcoin-4.22.9.5-x86_64-linux-gnu.tar.gz
83268c51344dd19de2e02fd46aad1128e3216ad39210031174b85976c5590b77 reddcoin-4.22.9.5.tar.gz
The manifest is published with two independent signatures:
SHA256SUMS.asc- OpenPGP, for manual verification, signed byABEDC4489B9188E45C2342A82E91240B293BA5D3SHA256SUMS.sig- BIP340 Schnorr, the signature the client itself verifies, made by the air-gapped release key23e6b696f2b69cd753de0d8fe3875e989085fbb6f2dc09026ba8ba1df33585db
To check the Schnorr signature yourself, from a checkout of this tag:
./contrib/release-signing/sign-release-manifest.py verify SHA256SUMS SHA256SUMS.sig \
--pubkey 23e6b696f2b69cd753de0d8fe3875e989085fbb6f2dc09026ba8ba1df33585db
The Windows installer is signed by Redd Ink Technology Pty Ltd and timestamped. The macOS bundle is signed by Developer ID Application: Redd Ink Technology Pty Ltd (Q6ZYKJ3NR2).
Full detail on every change, including the change log, is in doc/release-notes.md.
Full Changelog: v4.22.9.4...v4.22.9.5