- PoS
- If nActivateModular Block Passes Then:
- If your balance is above 12000, then you get 1% Interest
- If your balance is above 25000 and the supply is above 1500000 Fantom, then you start getting death blocks (negative numerals)
- If your balance is under 100 and the current supply is under 1080000 Fantom, then you get 8 Coins
- If total supply is above 2000000, then reward becomes nFees of that block.
So this line:
int64_t currentBalance = pwalletMain->GetBalance();
checks the combined balance of all the addresses in your wallet correct? Like someone couldn't just use multiple addresses within the same wallet to exploit this POS schedule correct?
Just curious because I want to figure out the simplest method of exploiting your POS schedule ahead of time so that I can implement it as soon as possible. It looks like I'll just be running as many instances of the client with an many different wallets as possible to exploit it.
The supply is quickly approaching 1080000 FNX so I am assuming this update will not be right on schedule. That is okay though. It gives me some time to figure out the easiest and most cost effective method of getting like 200 instances running at once. I have like 6000 FNX right now so I am thinking about 30 FNX per wallet will be a number to start with.
I'm being sarcastic. Ditch the reward scheme that favors smaller holders. This is far from the first time someone has had this idea. No one has ever implemented it though before it doesn't take long before someone points out that reward schemes such as this are easily exploitable.
POS rewards should not favor the little guy, nor should they allow the rich to get richer. I'm not speaking in terms of absolute number of coins, I am speaking in terms of proportion of the total coins.
Just stick with simple POS 2.0 and forget the "wealth redistribution" junk. Simply removing coinage from the equation favors those who actively stake and support the network and is the fairest system yet devised.
Poll
