People with large stakes are indeed the main problem. They in fact can mint minimally and still get the 1%. Because their stakes can generate so much coin-age quickly, they just need to open the wallet , say, once every year, and get the POS block in an hour then go off-line again. Secure minting does help to increase the number of minters. But it can only do so much.
If the network estimates how often a stake has been minting if it has just found a kernel, and uses the often-ness factor to adjust the reward, then people will be willing to mint often. For example if a stake has just found a kernel, the protocol will ask the owner to calculate how long it should take for this stake to find a kernel. If the time is longer or equal to the stake’s age, that means this stake has been minting full time. If the time is much shorter than its age, it means the stake has been sleeping most of the time. The ratio of age divided by the minting time will be a laziness factor – if it is greater than a threshold, say 2, then a bigger laziness factor will result in a bigger reduction in POS reward. So for example it would be OK for 100PPC to find a POS block in a year. But a it wouldn’t for a 10,000 PPC stake. The owner can still split the 10,000PPC stake to 100 stakes of 100PPC each to reduce or totally evade punishment. Then he has to make 100 blocks every year. That is far better than making only 1 quick block.
In order to make it easy to calculate how long it should take a stake to find a kernel, every node has to know the history of network difficulty throughout the life time of the stake. To greatly reduce the work load to do this, the blockchain can record network difficulty once in every e.g. 10 blocks, and every node uses this record to calculate the integrated probability of a stake to find a kernel.
For better PR the protocol could reward more diligent minters instead of punishing the lazy ones, or transfer the “fine” from the lazy one to the first non-lazy one down the line, to preserve total network reward. The punishment can go so far as resulting a negative reward for a stake when the stake finds a POS block (or even gets spent). I think it is a kind of demurrage applied on POS reward.
I like it but don’t understand probability calculation, would it give same result as limiting max GetProofOfStakeReward result to some % of nMoneySupply ?
I had a similar idea. The difficulty is already recorded in each block so we don’t need another record. Actually we can easily move backward in time to find out whether this particular kernel was able to mint at each second. We can then count the misses and determine whether this stake was minting constantly or not.
But I’m afraid it would be still too expensive for the nodes. Each time they receive a PoS block they must generate a lot of hashes to calculate the expected reward.
I think an easier solution would be to slowly decrease the reward from the moment when this particular stake’s probability to find a block is 75% (or any other percentage).
To calculate that we need a difficulty. We can take the average difficulty that would exist if everybody was minting (or a percentage).
I think this combined with cold minting would be enough to give an big incentive to mint.
No it is not the same. For the same nMoneySupply minting difficulty (hence the reward) can be quite different. The chance a stake has to find a block is related to difficulty.
[quote=“sigmike, post:3, topic:2363”]But I’m afraid it would be still too expensive for the nodes. Each time they receive a PoS block they must generate a lot of hashes to calculate the expected reward.
I think an easier solution would be to slowly decrease the reward from the moment when this particular stake’s probability to find a block is 75% (or any other percentage).
To calculate that we need a difficulty. We can take the average difficulty that would exist if everybody was minting (or a percentage).
I think this combined with cold minting would be enough to give an big incentive to mint.[/quote]
That might be good enough if the difficulty doesn’t swing wildly. If it does, taking an average difficulty will short change those minters who mint at more difficult times. Difficulty swing doesn’t seem to be a problem for Peercoin so far, however.
I think taking difficulty changes into account isn’t necessarily expensive. For one thing, we only need to to record the difficulty of every M blocks (block_number mod M == 0). I think looking up one block every 10 days may be enough. There will be only 18 diffs in the table for going back 6 months. Actually because the integrated probability is simply coin_number*(Sum_of_difficulty_now - Sum_of_difficulty_of_stake_creation)*constant, so the number of elements in the table doesn’t matter anymore if we record the sum of difficulty (since the oldest block) in the table instead of the difficulty itself. The cost of calculating integrated probability is mainly a one-off cost in creating the table when the miner starts. For another thing, from statistics most block-finding stakes are 100-200 days old. We don’t have to go back in time a lot usually. Once there is an old stake we extend the difficulty table further as needed.
I think the proposed solution works. Here, I just point some features that should be considered.
This sounds quite good. The problem with measuring the lazy stakes is the variance. The reward should drop quickly enough to punish the lazy stakes, but slowly enough so that minting stakes are not punished because of randomness. If you are waiting one year to mint your block and then (because you are in the unlucky 25% of people who seem lazy) get only 50% of expected reward, you will probably be angry, even if “in long term, you will get 1%”.
If you mint on average one block per X blockchain blocks at current difficulty, you have 75% of having found at least one block after 1.39 X blocks and 95% after 3X blocks. So it seems reasonable that the reward should be still quite high around 3X and then quickly drop to zero - around 5X, it can already be zero.
Possible disadvantages:
Similarly to the constant per-block reward, I think there is an incentive to mint on all forks for everyone. (To prove you are not lazy.)
If you do not mint constantly, you risk losing almost whole reward. (Particularly the small stake-holders, big stake-holders lose only the next block from plenty they mint.) This protocol does not allow (small stake) minters to “take vacation”. In constant per-block reward system, the vacation costs current interest rate x vacation time. In capped consumption of coinage per-block system, you are punished for taking vacation only if you have lot of PPC, by longer time you have to spend to claim your 1% reward. So the proposed protocol is quite unfriendly to minters.
P.S. In principle, the second point can be improved, if the reward for lazy minters does not drop quickly to zero, but slowly. But it might be quite difficult to set so that it does not punish active minters because of variance, but punishes the lazy minters enough. Any ideas?
just had an idea about this topic, now we have coinage, you gather always doesn’t matter on or offline. What if it could be recorded, the amount of time people have their wallet online (and minting), you could give credit for it, multiplier for the stake reward.
problem, how to record it, and where, I believe storj credits nodes with higher performance, no idea how it works there tho, and if it is cheat proof
[quote=“irigi, post:6, topic:2363”]I think the proposed solution works. Here, I just point some features that should be considered.
This sounds quite good. The problem with measuring the lazy stakes is the variance. The reward should drop quickly enough to punish the lazy stakes, but slowly enough so that minting stakes are not punished because of randomness. If you are waiting one year to mint your block and then (because you are in the unlucky 25% of people who seem lazy) get only 50% of expected reward, you will probably be angry, even if “in long term, you will get 1%”.[/quote]
We don’t need to punish a lot of people. Our current problems is that the large stake holders seldom mint. We only have ~10% stake minting. If everyone mints 1/3 of the time it’s 3 times better.
* If you do not mint constantly, you risk losing almost whole reward. (Particularly the small stake-holders, big stake-holders lose only the next block from plenty they mint.) This protocol does not allow (small stake) minters to "take vacation".
Not necessarily. Even you take 2/3 your time off by the time you should get your reward with 99.9% chance you still have a 90% chance. If we set the threshold at 99.9%, every stake that finds a POS block after the date when it should have 99.9% chance to find a block, but didn’t, will lose the chance, then at diff=10,
A 170 PPC stake will not get any penalty in a year. If it mints 4 months in the period it has 90% chance to find a block.
A 950 PPC stake will not get any penalty in 90 days. If it mints 30 days in the period it has 90% chance to find a block.
A 7000 PPC stake will not get any penalty in 31 days. Because the first 30 days cannot generate a block, this means that stakes more than this amount should mint on the 31st days, and do this every 31 days. The owner can split large stakes into smaller ones to avoid missing the small window. This is good for the network.
I think the wallet should be able of doing this without causing any significant losses to the owner. One of important Peercoin marketing points is that if you are minting, you can get back your losses caused by the inflation. People shouldn’t be forced (be frustrated) by having to solve the technical problems related to stake organization. But I guess this can be arranged.
Now I am also thinking that in this proposal, minters have incentive to split their big blocks into reasonably small ones. Even if it is done automatically by the wallet, this costs money (transaction size fees) and inflates blockchain. A transaction of 100,000 PPC, if you want to split the amount into 500 PPC comfortably mintable blocks, you will spend 100,000 / 500 / 6 = 0.33 PPC on transaction size fees and it will increase size of the blockchain by ~30 kB instead of ~150 b. (These estimates are from testchain wallet by Peerunity). It would be better if the protocol could handle minting with the big stakes without the need to split them.
Sorry if I’m nagging to much, I just want to cover all potential problems.