3) Cap interest accumulation at 90 days. [Incentive to keep node running is much too weak right now.]
I thought that this is implemented:
CBigNum bnCoinDay = CBigNum(nValueIn) * min(txNew.nTime-pcoin.first->nTime, (unsigned int)STAKE_MAX_AGE) / COIN / (24 * 60 * 60);
STAKE_MAX_AGE is set to 90 days.
This is for coin generation. Not for the amount of interest you are paid. PoS security is directly proportional to the amount of coin-age currently on line.
If I don't earn more by being online often, then there is no incentive to come online. Instead I can just hold my PPCoin until I want to cash out.
Then quickly generate my stake block and sell. This does do much to secure the network at all. I should be generating many stake blocks to earn my interest, not just one.
The cap ensures that I have to come online at least once in a while.
I see what you mean:
The likelihood of generating a POS block is capped to 90 days. But when it generates a valid POS block it takes the full coinage for calculating the reward, which can be anything above 30 days.
I generally agree that we need an incentive for people to keep their POS generating nodes running. I don't know whether capping the POS reward to 90 days is enough though, since, as you previously pointed out, 1% per year is a minuscule incentive. The only other way to tune that would be to make it attractive to generate a POS block shortly after the 30 day mark. However, you don't want to penalize late redemption of coinage. Usually exponential functions are good for that: E.g make it 4% for 30 days, 2% for 60 days, 1% for 120 days, 0.5% for 240 days. This has the effect that the POS blocks to get a reward which is rather constant instead of being proportional to the coinage. However, quick redemption (after 30 days) allows a quicker turnover and is beneficial to the POS miner. However this is a drastic change - and the quickest way to get this sorted out would be to work together with Sunny on the issue.
ADDENDUM: While doing a revision of the POS reward scheme, it may also be beneficial to investigate how the incentive structure for including transactions can be optimized. Maybe the block reward can be proportional to the overall destroyed coinage instead of the stake transaction (however, the "likelihood" of generating the POS block should only be determined by the stake transaction)
Then including transactions which destroy significant coinage is beneficial to the miner and it's an incentive to include them instead of leaving them out. The above mentioned exponential modifier can work on the total coinage for the block instead of the stake transaction...
This part in interesting:
Maybe the block reward can be proportional to the overall destroyed coinage instead of the stake transaction (however, the "likelihood" of generating the POS block should only be determined by the stake transaction)
It might also solve several problems at once. I think it would:
- make the number of stakes you claim more important than the amount of the stake transactions (atleast once there are lots of transactions flying around and the destroyed coinage is mostly coming from the included transactions and not the stake transaction itself). This would then encourage you to keep the client running to claim as many stakes as possible and to include as many transactions as possible.
- there would be more reason to include large transactions and not so much of a reason to include the spammy small ones. This is a bit weak but it might give larger transactions higher priority which isn't so bad.
The percents would have to be tweaked and probably dynamic somehow though, otherwise the rewards and inflation would get out of hand as the network processed more and more transactions.