CaveSpectre11
commented
5 years ago Yep, there was going to be a problem with the dev and fund payments coming out of just the miner reward; That blew the seesaw algorithm up, as there was the potential for the masternode to get more than 91% of the block reward, thus there wasn't enough left to pay the dev and fund payments. Which, would have ended up with a negative block reward to the staker. And since the value is unsigned... it would have been a coin destroyer and minted the remaining coins left to max supply!
flyinghuman
Reworked Masternode Drift to be percent based instead of Masternode Count based, and implemented the checks. Instead of adding a few masternodes to determine the minimum payment a staker should be paying for consensus approval; it now will add nMasternodePercentDrift to the count of locked coins, to determine the minimum payment. This should, most of the time, be the same as the actual. However in situations where the numbers of masternodes that the staker sees is a few masternodes less than what other nodes on the network sees (or masternodes drop off between the time the block is submitted and the block is verified), and that difference is enough to kick it into a different SeeSawTableIndex; the drift algorithm will allow for that block to be written properly.
Great care should be used when choosing a percentage. You don't want to guarantee a different table index, otherwise bad actors can constantly short change the masternodes. with a 3% setting, this (currently) is about 44k added to the locked balance, but only occasionally causes the required masternode payment to be one index less. Any bad actor that chooses to game this system runs the risk of having their block rejected because they pushed it to the edge and there actually was a difference in masternodes between the block submission and it's validation; in which case they will lose the block and their reward; and thus it is not a profitable game.
A boolean is added to GetMasternodePayment(), and GetSeeSaw() named bDrift. The default is false; and that is the way it is called during block creation. During block validation, GetMasternodePayment() is to be called with bDrift set to true; and thus the 3% will be added to the locked coins, to possibly show a lower required payment... to handle different views of the masternode landscape, or changes between block creation and validation.
The functions can be monitored via debug messages with the string "GetSeeSaw", and are only active when running with -debug enabled.
SeeSaw algorithm has also been fixed after testing, correcting issues where floats less than 1 aren't converted to integer 0 prematurely.
A couple typos were handled as well.