Releases: CloakProject/CloakCoin
2.2.2.2 (2x4) wallet update
IMPORTANT: SECURITY ISM SOFT FORK IMPLEMENTED
UPDATE A.S.A.P. : This version fixes a possible vulnerability in the staking algorithm
We've come to realize there is a flaw in the algorithm that could enable a staker with a significantly large amount of coins ("whale") to create/stake a large number of blocks (possibly sequences) by not splitting or merging their coins - this is only possible by manually modifying the client & creating custom binaries (aka a malicious actor). This is a consensus rule change - it will be applied via super-majority functionality, the sooner everyone upgrades, the better. Blocks version 5 will have the new check enforced at 75% ISM(v5), blocks version 4 (current) will be rejected at 85% ISM(v5), counting the last 20160 blocks.
If you're running a v3 electron wallet, update your associated daemon with one from these binaries or compile one from the new code
Important to note: they would not gain more coins by staking this way but the fair distribution of staked blocks could be affected (normal, standard clients would stake later than usual).
This is not inflation bug or a reward hack - but introduces a small chance that a malevolent whale could control block creation, and hence the txns in them, for a period of time
RL example for nodes with equal amounts:
I'm throwing one coin. You're throwing a 1000 coins.
If I get a head, I get $6000. Each one of your coins that gets a head, you get $6.
The caveat is: as soon as your 1 coin hits head, we both throw again. And you're throwing 999 coins now.
(until they mature)
I get 2 heads in a row, I'm up $12000. You probably might win the next 2000 throws ($6) so we end up even, but winnings is not even the biggest point, it's the distribution of winning the tosses - since that decides who adds the blocks to the chain and the txns in them.
Potential problematic assumptions of people claiming it ends up being the same and that there is no risk:
1) a flat (or uniform/symmetric around target, at the very least) SHA256 probability distribution, which might not be the case
2) that changing difficulty doesn't affect the small stack probability, which is questionable
3) that competing coin value is constant, which it isn't
Either way - you're less affected by the ripples in probability distribution with a huge stack that doesn't split. This is obviously a possible advantage that we're trying to avoid to make a more even playing field.
Other updates:
- Windows daemon fix, force USE_LEVELDB, was not working properly before, especially enigma sends
- Fix for banscore being applied with Enigma turned off and receiving Enigma messages/data, improves connectivity
- Version bump, onion layers bump to 25 - should improve Enigma performance (less dependency & assumption of network topology)
- New commands added to the daemon (type help in console)
- Improved enigma send security & consistency with the QT code - please use the new
sendenigmacommand to send your coins more securely via daemon/console - Added tolerance for Enigma network delays and people that don't know how to set up their clock properly :)
(but seriously, SET/SYNCHRONIZE YOUR CLOCK!)
ZIP hashes:
Linux: 3d33bbc32a7ff22bbe1a995db7f4350ffe347f6b4936f87be7ed0ed638fbe5cf
Windows: 5e8df66a1e3807fcd91b477cc7b5d5f9933df271b4be9203aa769597f5e3c3b0
Mac: 5e5a1cc48f63736650b9a4a3a98d2d49ff3c5769388071ea9d04f283fdc61333
v2.2.2.1 wallet update
While work is also done on the switch to BTC codebase v0.17, we haven't forgotten about the current version of the wallet, already available for our community. This update is another set of changes & improvements targeting better stability and user experience - after careful revision, code was added to slightly alter the speed of Enigma transaction handling, as well as some network buffer tracking/shaping. Motivation was to fix the d/c storm issue associated with Enigma transactions. The issue is not (and was not) reproducible on devnet or testnet with relatively small number of nodes - hard to say this is the final solution without testing it "in the wild" as the problem seems to be large network and/or bandwidth related; we would require most of our users to also run testnet nodes. That being said, we are also looking into putting in place a permanent testnet, where issues like this can be tested properly and will provide us with a better place to catch more errors before they hit livenet.
Note: To isolate the send/receive mechanics from previous client versions that have the issue, Enigma v1.2 is not backwards compatible."
Changelog:
introduced a small delay in processing enigma onion layers & relaying messages
added a delay to socket read when receive buffer approaching full to allow time for processing and relaying messages in the main thread
bumped client version to 2.2.2.1
bumped Enigma engine version to 1.2
rEvo 2.2.2.0
Increased send and receive message buffers, fixed active stealth address with pre-existing wallet, other fixes.
Enigma ver 1.1
Checksums:
Windows: 24cdca90544424cddb3f0d3a2f8fbdae7d67f28656353275b957df74e17e6ee6
Linux: 961442e42e0d775919f1f2822ab9391c501b7e9884dabfee616a9825f0bbeb70
MacOS: bee6215e63c80f25443b40cc764886ea12a530e441789e7facd33ea5477a2703
RaspberryPi: ba41f1f99f448b3d8719bb5c6d89d1d8a8e5e585f3200cf079f42b5911972678
