I don’t foresee any issues here but the event is interesting. It may (but hopefully does not) motivate DOS of elders (to remove them and thus trigger the event). For example elders changing rapidly gives a load very close to 1. It’ll be interesting to see in testing how much load varies. I guess this range will be different for a young network vs old network since elder change will be less frequent in an old network, also the counter will change at differing rates depending on network age…?
Seems like a nice challenge to try analysing the dynamics of the load parameter. Load is one of those simple-but-complex parameters.
Haha I hadn’t noticed this! Ctrl+f shows 7 of each, so a tough decision ahead!!
When reward is on PUT like in rfc0057 it makes sense to target 100% with gradually slower approach over time. The ‘recycling’ and the ‘minting’ are triggered by the same event so operate in lockstep.
But if PUT recycles and GET mints then there needs to be a target less than 100% since there can be periods of mostly recycling or mostly minting. Since the minted coins must never go below 0% or above 100% the economy must push toward some target amount between 0-100%.
The economic design has changed from rfc0012 to rfc0057. rfc0012 is PUT will recycle and GET will mint. rfc0057 is PUT will recycle and mint together.
In rfc0012 total coins in circulation can go up or down.
In rfc0057 total coins in circulation can only go up.
This difference calls for very different control mechanisms.
I’m not sure how much can be learned about one mechanism from the other.
For now rfc0057 mechanics is fine to get a testnet running, but I feel it does not economically ensure permanent data so we will end up with rfc0012 style dynamics.
It’s a can of worms for sure. Would be interested to hear other opinions.
This is only true for rfc0057 style economics.
In rfc0012 where there are boundaries at 0% and 100% with a push-away requirement, those boundaries still have a purpose even though they are never touched (ie ‘never exist’).
If the total coins minted can only go up like in rfc0057 then it makes sense to gradually approach the upper bound and it’s true that if they aren’t minted then it’s as if they didn’t exist.
I feel a lot hinges on this line in rfc0057: “For now, we will use an algorithm which would eventually deplete all farmable coin, but which is simple to implement while we gather further data from testnets.”
My main question from this is, how will data be ensured to be permanent? Rewarding only on PUT as in rfc0057 seems to make this difficult to achieve, although maybe I am merely lacking imagination.
I see this discussion is getting away from the topic of pre-dev-updates so maybe it is time to move to another topic?