The ReddCoin Core 4.22.9.5 release focuses on staking reliability, security, and safer software updates. This covers everything that changed between v4.22.9.4 and v4.22.9.5.
The 4.22.9.4 update was mostly about wallet key derivation. This one is mostly about staking, plus a genuine security fix in the built-in update checker and a new feature that lets the client verify a download before you install it.
If you stake, this release is worth taking. Several of the fixes below are things stakers have been quietly living with.
Plain answers first
Is my money at risk? Can anyone take my coins?
No. Nothing in this release lets anybody take coins, and nothing here makes coins vanish from the chain. There is no remote exploit and no consensus problem.
There is one real security fix, in the update checker, and it is described honestly further down under The update checker was not verifying who it was talking to. The short version: an attacker sitting between you and the internet could have stopped your node telling you that a new release exists. They could not have taken your coins and they could not have made your node install anything, because no version of Reddcoin Core has ever installed anything by itself.
Did I lose coins to the staking bugs?
Not coins, but possibly some staking rewards, and possibly some patience.
Three of the fixes below cover situations where a stake was lost, where coins were held back from staking when they should have been available, or where staking silently stopped and the node still claimed it was running. None of that removes coins from your wallet. It means you may have earned less than you should have over the last while.
Do I have to do anything to my wallet?
No. There is no migration, no rescan, no reindex and no change to your wallet file. Existing wallets load exactly as they are.
The standing advice never changes and is worth repeating: keep a current backup of your wallet.dat.
Who most wants this release?
In rough order:
- Anyone who stakes. Six separate staking defects are fixed.
- Anyone who opens and closes wallets while the node is running, including switching wallets in the graphical client. On earlier versions that could crash the node or hang it permanently.
- Everybody else, for the update checker security fix.
Is there anything I should stop doing until I upgrade?
One thing, and only if you are on 4.22.9.4 or earlier: do not close or unload a wallet while it is staking. On earlier versions that can crash the node, and in some cases hang it in a way that only a restart clears. Stopping the node normally is safe and always has been. It is specifically closing a wallet while leaving the node running that is affected.
Do I need to trust the in-app update link?
Not yet. The version you are running now still has the unverified update check, so please get 4.22.9.5 from the official download page or from links shared in our official channels, exactly as you did last time.
From 4.22.9.5 onward this improves considerably, and that is one of the bigger changes in this release. See The client can now check its own download below.
ReddCoin Core 4.22.9.5 staking fixes
Six distinct problems are fixed in the ReddCoin Core 4.22.9.5 release. You may recognise some of these as things you have seen and assumed were normal.
1. Closing a wallet while it was staking could crash the node
If you closed or unloaded a wallet while that wallet was staking, the staking process kept using the wallet after it had been thrown away. The usual result is a crash.
This affected both the graphical client, where it happens if you close a wallet from the File menu, and the console, via unloadwallet. Shutting the whole node down was never affected.
2. Fixing that revealed a second problem, where the node hung instead
Worth being open about, because it landed as a separate fix after the first one shipped internally.
Once the crash was fixed, a narrow timing window remained where closing a wallet at the exact moment its staking process was starting up would cause the close to never finish. Not slow, not a timeout: it would wait forever and take a chunk of the node’s console handling with it, until the node was restarted.
Both halves are fixed in 4.22.9.5. Together they mean closing a wallet while staking is now an ordinary operation.
3. Turning staking off meant you could not turn it back on
If you disabled staking for a wallet with setstaking false, you could not re-enable it. Sending setstaking true set a flag and nothing else. Staking for that wallet stayed off until you restarted the node.
What makes this worse is that nothing told you. The node continued to report a running staking process, so from the outside it looked like it was staking normally while earning nothing.
If you are on an older version and hit this, you can get staking back without a restart by switching the global setting off and on again: staking false then staking true.
4. Your node sometimes rejected a block it had just staked
Occasionally the node would successfully find a stake, build the block, sign it, and then reject its own block because of an internal inconsistency in how the block’s height was recorded. The stake was simply lost.
This is rare but real. On one monitored mainnet staking node it happened twice in ten days, out of 2311 blocks staked. If you stake a large balance, you have very likely lost the occasional block to this without ever knowing why.
5. Coins were held back from staking after an orphaned stake
When two stakers find a block at the same height, one of them wins and the other’s block is orphaned. This is normal and happens constantly.
The problem was in the cleanup afterwards. The coin used in the losing attempt has to be released back to the wallet, and that release was only being done as part of building a new block. So:
- If your wallet was staking, the cleanup ran, but it ran a full scan of your entire wallet roughly once a second, which is pure wasted work on a wallet with a lot of coins.
- If your wallet was not staking, the cleanup never ran at all, so the coin stayed marked as spent and your spendable balance stayed short until you next restarted the node.
That second case is the one people would actually notice: a balance that looks lower than it should be and mysteriously corrects itself on restart.
Cleanup now happens at the moment the orphaned block is removed from the chain, which is both correct and far cheaper.
6. Your log was full of alarming messages about conflicts
If you stake and you have ever looked in debug.log, you will have seen lines like this:
Transaction abc... (in block def...) conflicts with wallet transaction
ghi... (both spend jkl...:1)
That wording is inherited from Bitcoin Core, where it can only ever mean something genuinely suspicious. On Reddcoin it is the completely normal result of an orphaned stake being replaced by the winning one.
The message now has a second line after it explaining, in the cases where we can prove it is harmless, that this is ordinary staking behaviour rather than a double spend. Where it might genuinely be a conflict, for example if you spent a coin while it was staking, the message is unchanged.
ReddCoin Core 4.22.9.5 security fix: update checker
This is the one item in the release worth reading properly.
What was wrong. Reddcoin Core checks whether a newer release exists by contacting GitHub over an encrypted connection. The encryption was there, but the client never checked who was on the other end. It did not verify the certificate and did not check that the certificate matched the site it had asked for. In practice that means the encryption was providing privacy but not authenticity: the conversation could not be read by a bystander, but it could be impersonated.
What somebody could actually do with that. They would need to already be in a position to intercept your traffic, such as a hostile network, a compromised router, or an ISP-level attacker. Given that, they could:
- Silently suppress update notices, so your node never tells you a new release exists. This is the significant one, and it is the wrong failure mode for the exact mechanism whose job is to tell you that security fixes are available.
- Show you a made-up version number in the update notice.
What they could not do. They could not take coins, read your wallet, affect your balance, alter the blockchain, or make your node download and install anything. No version of Reddcoin Core has ever installed an update by itself, so there was no path from this to running attacker code on your machine.
What is fixed. 4.22.9.5 verifies certificates properly, checks the hostname, and gets its list of trusted authorities from your operating system, so it follows your system’s own security updates rather than a list frozen into the program. If it cannot establish trust it reports the failure instead of quietly continuing unverified.
Please note this is not fixed in the version you are running now, which is why the advice above is to get 4.22.9.5 from the official download page rather than from an in-app link.
Related fixes in the same area
- The update check had no time limit. A server that accepted a connection and then went silent could freeze the client indefinitely. In the graphical client that meant a frozen window, since the check was also running on the same thread that draws the interface. Both are fixed: there is now a proper timeout, and the check runs in the background.
- A failed check looked like a successful one. Because of a mismatched field name, when the update check failed the dialog showed “Installed version:” with nothing after it, which looks like a normal “you are up to date” result. A network failure, a certificate failure and a GitHub rate limit all looked identical to success. Now failures are reported as failures.
- The status bar told you to update to the version you were already running. A one-word mistake put the local version into the message instead of the new one.
- Pre-release builds were not showing their warning. Test builds carry a caution telling you not to stake or accept payments on them. It was being read and then discarded, so it never appeared.
- The response had no size limit, so a hostile or broken server could make the client consume memory until it died. There is now a sensible ceiling.
ReddCoin Core 4.22.9.5 download verification
This is the main new feature, and it is the reason several of the fixes above were worth doing.
The problem it solves. Until now, the update notice could tell you a new version existed and link you to a folder containing roughly fifteen files. Working out which one you needed was your problem, and verifying that what you downloaded was genuine was also your problem, which in practice meant almost nobody did it.
What 4.22.9.5 does.
- It names the exact file your machine needs and links straight to it, rather than to a directory. It works this out from what your build was compiled for, so a Windows user is offered the Windows installer and a Linux user is offered the right tarball for their processor.
- It checks the file is actually there before naming it, so you do not get a confident link to a missing file.
- It can download it for you, with a progress bar and a cancel button.
- It verifies the download cryptographically. Releases are now signed with a dedicated release key, and the matching public key is built into the client itself. After downloading, the client checks the file against that key. If it does not match, the file is deleted rather than kept.
- It then hands over to your operating system. On Windows it offers to run the installer, on macOS to open the disk image, on Linux to show you the file in a folder.
What it deliberately does not do.
It does not install anything, it does not replace the running program, and it does not execute anything on your behalf. You stay in control of the final step. That is a deliberate design decision, not a limitation to be removed later.
Why the built-in key matters.
Because the key is compiled into the client, verification does not depend on the network, on a key server, or on you having imported anything in advance. Even if someone tampered with the download in transit, the check happens locally against a key they cannot change without replacing your client entirely.
This sits alongside the existing OpenPGP signatures, which are unchanged and remain the right tool for manual verification. Nobody who verifies releases by hand today needs to change anything.
For anyone who wants to check it, the release public key is:
23e6b696f2b69cd753de0d8fe3875e989085fbb6f2dc09026ba8ba1df33585db
There is also a new console command, downloadupdate, for people running a node without the graphical interface. It fetches and verifies the current release and tells you where the verified file is. It installs nothing.
The other changes
Proof of Work checking was restored
A check that verifies a block’s proof of work against its stated difficulty had been removed years ago during the move to Proof of Stake, and was never replaced. It has been restored.
To be clear about the scope, because “proof of work check was missing” sounds worse than it is: this affects the historical part of the chain, the blocks mined before Reddcoin switched to staking at block 260799. Reddcoin’s current blocks are staked, not mined, and are validated by an entirely separate set of checks that were never affected. The live chain passes the restored check, and nothing about which chain your node follows changes.
This is a tightening rather than a loosening, and it brings this release into line with what our development branch already does. Two related fixes came with it, covering ways an invalid difficulty value could previously have been accepted.
Wallet status icons come back after closing a wallet
In the graphical client, closing one wallet while another stayed open made three status bar icons disappear for the rest of the session: the staking indicator, the HD indicator, and the encryption indicator.
That is more than cosmetic. The staking icon is how you turn staking on and off by clicking it, and the encryption icon is the quick lock and unlock control. Losing them meant losing those controls until you restarted. All three now return properly.
Descriptor wallets now use Reddcoin’s own key numbering
Reddcoin has a registered coin number, 4, used when deriving addresses from a seed phrase. Ordinary Reddcoin wallets have always used it. One newer optional wallet type, called a descriptor wallet, was still using Bitcoin’s number, 0, inherited from the upstream code.
Almost nobody is affected by this.
Descriptor wallets are off by default and have to be deliberately selected when creating a wallet, so unless you went out of your way to make one, you do not have one.
If you do: existing descriptor wallets are not changed and need no migration. A wallet’s derivation is fixed when it is created and stored in the wallet file, so yours keeps working exactly where its keys already are. Only newly created descriptor wallets use the corrected number. The practical benefit is that a seed phrase from a new descriptor wallet will now restore correctly into third-party tools that expect Reddcoin’s number.
Security and build maintenance
- OpenSSL updated from 1.1.1 to 3.5.7. The old version stopped receiving security fixes of any kind in September 2023. On top of that its download had stopped working entirely, which meant builds were failing. 3.5.7 is the current long term support release.
- Test suite repairs. Four stacked problems were preventing the automated test suite from running to completion on this release line, including one that crashed it outright. Three of the four turned out to be faults in the actual program rather than in the tests, which is a fair illustration of why a test suite that does not run is worse than it looks.
- Copyright headers, man pages and the example configuration file regenerated for the release.
For users wondering whether they should upgrade, the ReddCoin Core 4.22.9.5 release is primarily a reliability and security update, with the biggest benefits going to users who stake.
Summary
- Nobody can take your coins. No coins are lost and no wallet changes are needed.
- If you stake, upgrade. Six staking defects are fixed, including lost stakes, coins held back from staking, and staking silently stopping while reporting itself as running.
- Until you upgrade, do not close a wallet while it is staking. On earlier versions that can crash or hang the node. Shutting the node down normally is fine.
- The update checker has a real security fix. It was not verifying who it was talking to. An attacker in the right position could have hidden new releases from you, but could not have taken coins or installed anything.
- Get 4.22.9.5 from the official download page, not the in-app link, since the version you are on now still has the unverified check.
- From 4.22.9.5 the client can verify its own downloads against a key built into the program. It still installs nothing by itself, and you stay in control of the final step.
- Keep a current
wallet.datbackup. This never stops being the advice.
Questions are welcome. If anything above is unclear, ask and we will explain it properly rather than pointing you at the release notes. Join us on Telegram, X, and Bluesky
