Release 2.3.0.0 - fixes the staking bug in a stale singe-UTXO address #35
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the previous release, due to my oversight, a bug was introduced with regards to the staking mechanic.
A temporally sensitive edge case was not considered when upgrading the code to block version 5 within the 2.2.2.2 release.
The consequence was that staking was made practically impossible when certain conditions were met, these were as follows:
This resulted in the client attempting to complete a merge stake, usually reserved for combining multiple older/stale UTXOs after the 30 day period, which has a goal of increasing the chances of a combined UTXO to produce a new block/stake sooner rather than later, making it more fair wrt new block grouping distribution (and potentially preventing whales to effectively hog a large percentage of said new blocks), as well as reducing dust which puts more strain on the compute resources.
Sadly, the block version 5 logic prevents a case where a valid merge stake attempt is made where the 2 conditions above are met.
This PR fixes this logic with a block version 6 upgrade, but like version 5 did, it requires a consensus change/soft-fork.
The activation of this is achieved via IsSuperMajority() function, set at 75% of the last blocks observed & added to the chain being version 6, within the 7200 block window - which equates to 5400 out of the last 7200 blocks being produced. Hoping the community upgrades sooner rather than later, as ISM75 requires majority staker support for successful implementation.
Other changes:
A messaging delay was increased from 100ms to 250ms in the "peeling" part of onion routing to protect the client I/O buffers from getting clogged during the Enigma "chirp". This should slow down the Enigma transaction message processing, but increase the stability of the network during that time.
Release version bumped to 2.3.0.0
A redundant version string was removed from the splash screen, it was also getting cropped and looked ugly/broken.
The windows build 2.3.0.0 is ready for release (including the installer), I will work on getting builds for Linux & MacOS ready next.