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