Use cryptonote::reward_money in db_sqlite #1802
Open
+3,422
−403
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
the bulk of the code for transitioning to HF21 is present, and much testing code is present. This code does not yet work, and the tests are not yet complete. add hf21 transition mechanism to sqlite db
After HF21, any nodes which did not transition to SENT stakes need to be removed. Doing them all at once would be chaotic with swarms, so they will be removed by the existing decommission/deregister system. That system now has a config-determined limit of deactivations per block so that this transition (but also huge network outages) won't cause swarms to disappear (or other possible chaos resulting from mass removal).
Staked oxen addresses which are not registered for the SENT transition will have their pending service node rewards paid out in full on the final block before HF21. Modified local devnet testing to leave a staked static-startup address out of the registration for testing this (and adjusted expected numbers accordingly).
nodes which did not transition to hf21 will be removed by the decommission->deregister mechanism rather than by the bls-key-not-in-the-contract mechanism
script needs parameters set as appropriate: - oxen -> eth address mapping - transition bonus mapping - staking requirement and scaling ratio TODO: some mainnet nodes have a larger stake, scaling needs to be normalized for those
They cannot ever come back, so there's really no point of leaving them for a week. (We *don't* want to immediately dereg them because going into decomm still allows SN comms between storage servers, allowing the leaving nodes to still transfer their files out to the remaining nodes upon swarm dissolution).
nodes which do not transition at hardfork 21 should not be in the reward payment rotation
calling this method returns a before and after as if hf21 would happen the very next block. Because outstanding oxen rewards will differ from the exact fork height (and from block to block), this can only be approximate, but it should be fairly close to what the actual result will be.
higher staking requirement to test hf21 transition correctly scaling stake proportions in multi-contrib
one line of this commit was kept and moved, making actually reverting it and demolishing this commit tedious, so it stays, but the important aspect of it which was to be reverted was later reverted.
The block before HF21 all addresses with accrued rewards which are not registered for the HF21 transition with an ETH address will have their OXEN balance paid out at that height rather than converted. This was not working correctly for multiple reasons, but is now.
also update devnet hf21 parameters
This lets the caller control the final values that the transition will run with. For ordinary usecases this is not important, the transition parameters are pulled from the compile time constants. For testing and mocking it can be useful to modify these values at runtime to simulate different transition conditions.
For mocknet and testing we now allow changing the staking requirement at runtime (i.e. for testing different staking requirements and conversion ratios) the staking ratio needs to be updated with the appropriate values. Allow a higher precision conversion ratio to allow for more fine grained conversions. For the $OXEN to $SESH conversion we now defer to a 128 bit multiply to avoid overflow for the conversion.
I was counting the number SESH calculated for each contributor as the amount they contributed to the node. This was incorrect because that number is not the amount they were able to stake, just the amount the were required to have to be able to keep the node alive. This mean that `tokens_allocated >= staking_requirement` was incorrectly attributing a node as having made it past the transition when it actually didn't. Instead of trying to be clever and calculating the partial collaterised nodes that will be zombified, only count tokens from a fully collateralised node.
Doy-lee
changed the title
Doy-lee
changed the title
```diff
std::bitset<sizeof(uint16_t) * 8> bitset_view16(uint16_t val) {
- std::bitset<sizeof(uint16_t) * 8> result = val;
+ std::bitset<sizeof(uint16_t)* 8> result = val;
return result;
}
```
clang-format constantly tries to re-format this line, moving the '*'
back and forth all the time. Seems to be a bug that we can avoid
completely by just pulling out the expression into a constexpr value.
There's various conversions back and forth between atomic OXEN and atomic DB units that is error prone. This can be mitigated by using a strongly-typed money amount that makes it explicit where and when which unit is being used.
Doy-lee
force-pushed
the
doyle-use-reward-money-in-db-sqlite
branch
from
5639782 to
ea82e61
Compare
Doy-lee
force-pushed
the
doyle-use-reward-money-in-db-sqlite
branch
from
5945dfa to
7b6dc7c
Compare
Doy-lee
changed the title
And somewhere, it already defines WIN32_LEAN_AND_MEAN so we remove that.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This goes on top of/depends on #1800
Only the last commit is relevant to this change which is that I've propagated the usage of
cryptonote::reward_moneyour strongly typed money unit for handling the atomic OXEN and DB units into the SQLite DB layer.--
Passing now. Not sure what those deb failures are atm.