It is again taking us an awful long time to get to our new fork point. However, I don't think this time it is from the bot intentionally throttling itself, but is instead from the anti-warp targeting finally starting to converge. The average amount of warp effect created by the bot has been steadily decreasing, and we're now coming closer to a point where the bot is not able to solve faster than the TT.
Is anyone human mining lately? Is the difference very noticeable?
The past couple of days have mostly been spent assessing different approaches to on-chain voting for mining parameters. I think we might best be served using something like the Heavycoin approach. I might add one small feature to Heavycoin's implementation, allowing users to defer their vote to that of other users. (So if you don't want to actively manage what parameters you vote for you could just tell your client to always "vote the way e1ghtSpace's address last voted" for example.)
I think we should allow voting over at least what are currently the two constants in the formula: min path length and base hashing work requirement. Other things we could consider including are:
- Hashing work multiplier - in addition to adjusting base (minimum) hashing work target we could adjust number of rounds of hash required before collision check. In this way the network could vote to multiply the anti-warp strength
- TT adjustment- We could allow for a vote on a number of bonus or penalty frames summed to TT. With this, the network could vote to make TT easier/harder than what is set by target
- Block reward adjustment - Although I personally have some qualms with this one, I certainly understand the motivations. With this, the network could decide to reduce/increase average subsidy distributed
- Block interval - I don't think this one has been tried on another coin (probably has and I just missed it) but we could vote on how often blocks are produced, allowing the network to increase/decrease security in trade-off with confirmation rate
- Work credit curve parameters - Instead of intermittently measuring the work curve and hard-coding the logistic parameters we could put all of the parameters up to a vote. However, this runs a risk because it creates the possibility for the chain to "vote itself into an inecure configuration" which concerns me a bit. (This might also be true of block interval voting?)
- Total coin cap - Another one that I don't recall seeing done in another coin yet (EDIT: this is actually done "indirectly" by heavycoin) we could have a vote on the total number of coins to be created. This would have to be handled with some care, as once the set cap is reached the vote should only allow for the cap to be raised, not lowered. It is possible, though, and would give us a nice way to approach the "should we leave MOTO uncapped" question.
- Map size - This one might be a little more difficult to implement correctly, but it should be hypothetically possible. This would allow the network to increase/reduce the dimensions of the play area.
- Map seed density - Another one that would be difficult but hypothetically possible. We could change how densely seeds are applied in the perlin function. This would allow us to raise/lower the overall "entropy" of map generation.
Did I miss anything obvious?
(EDIT: We could of course also include some parameters over the physics itself, like gravity strength, acceleration force, friction, angular momentum applied when rotating, etc... but I'm not sure if that would be a really good idea or a really bad one, hehe. I'm inclined just to "not even go there" for now.)
I will probably start by implementing votes over just the two constant values. If there is significant demand demonstrated for any others, in particular, we will approach those after we prove out an implementation over the two basic requirement values.
Thoughts?
)
