RE: Proposed changes in the Calibrae fork
I strongly support many of these changes. Particularly, if the SEC decides to come after Steem because of the premining issue, Calibrae may well prove immune, because of the changes you intend.
I would, however, not disburse all those vests right off. There has been some fluctuation in rewards due to HF19, and how the pool was drained quickly. I reckon maintaining more of a pool could moderate fluctuations, and people would find that easier to count on.
I was raised in Alaska, and royalties on the oil industry were accumulated in a permanent fund. The interest generated from this fund not only made it possible for Alaska to not tax it's citizens, it actually paid them by disbursing interest accrued on the account that was not required by state government.
When I was a kid, Alaska paid us ~$1,000/year, just for being an Alaskan.
Give this some thought. It's possible that keeping a healthy vest fund, rather than simply expending that fund quickly, may be something beneficial to the platform, and the community.
I also like the idea of one issue per HF. HF19 was difficult to parse, because it did two diametrically opposed things. Did selfvoting dramatically increase because minnow votes were worth more, or because there were far fewer votes being cast?
While I reckon the latter more convincing, I've seen no data that proves either supposition. One issue per HF would make it much easier to understand the difference between what was expected to happen, and what did happen, as a result of the change.
Have you considered removing the weighting of VP by SP, and thus removing the currency from the SEC's jurisdiction? I have posted and commented profusely on other problems that arise from this 'feature' of Steemit.
However, getting the SEC off our backs is pretty damn compelling.
Thanks for your hard work and careful thought that has gone into this post!
I can see the sense in keeping a bigger pool. This also allows more elasticity in the reward calculation scheme. Bear in mind that I do intend to add the self-hosting code down the track, but that will be part of a total re-implementation based on SporeDB. I'm not sure what exactly this would involve, it seems to me like this might be a subject for a post-release hardfork.
I want to specifically point out some points that maybe you didn't connect directly - direct self voting is banned, as now added as item 8, using reputation to modulate rewards allocation. There does have to be an initial pool or the rewards will be horrible to begin with. The distribution will not follow the patterns we see here, if there is no direct self vote, and vote power is reduced by reputation position. It will help ensure, in theory, that the distribution balances properly. I think a slow and gentle path to equilibrium is better - yes, at first there will be a frenzy, but it will take not a very long time for people to realise that the numbers they see mean in reality about 6.9% per week of that reward can be seen a week after, and so on. So, it will mean a lot of high rep, small accounts will power up a lot.
This will help level the playing field sooner, I think.
I have thought a lot about the issue of stake and weight of votes, and I don't see how unbinding them produces a good result. I do, however, think that reputation scores should have an influence on payouts. This way, a big Stake account can be punished in its ability to influence by downvoting from high reputation accounts. If the big stakeholder returns to good behaviour, and maintains it, they regain their influence.
I have discussed this in my proposals for how to monetise code using votes, where the ability to use stake in a negative way is very patently obvious. I don't think it is any less applicable to the forum in general. I might then perhaps make an 8th proposal that reputation becomes a factor in rewards calculation. The current scheme with reputation is only to implement community driven censure, a way of punishing bad behaviour. But bad behaviour includes using one's stake in ways considered negative by the community.
I only commented sparely, because I am all too given to bloviation =p
I do like very much that you intend to mitigate stake with rep. I reckon it's a great step forward, as rep is community vetting (which will matter much more when bots are incapable of influencing it).
I am not a coder, and much of the guts of the system you are making are above my pay grade. I am also mentally incapable of parsing further the rep/stake weighting of VP, at least until I see a particular implementation.
I'll look forward to further development. I am greatly interested!
It will be interesting to see if I am even capable of doing this at all! But I made great progress today, and I will be making daily posts from now on, about this.