It should be a topic for discussion the possibility of an automatic increase on the amount of what I call "Security Council"seats, which is currently the Top20 witnesses that govern the Hive blockchain.
Reason: further decentralization of the network as it increase in active participants.
The amount of spots could be changed by direct voting in a similar way it is already done to decide saving interests, with only votes casted by witnesses already on Security Council being valid, with a, let's say, 30 days gap after consensus to be increased(of no witness changes the vote in the meantime) and, let's say, 24 hour gap to decrease(emergencies might affect stability in the short run, so, shorter time for decrease) after new consensus.
Or the amount of seats could also be automatically change periodically using several factors to calculate it, like the stability of the top witnesses outside the Security Council with factors such as weekly block produced/missed ratio, price update at least once every 24 hours, etc.
Anyway, this is just a suggestion for a topic of discussion. Thank you all for your attention.
If you have a spare vote...
If possible I would like the opinion regarding viability from those directly involved in the project, like @blocktrades and @gtg.
Don't break something that works (especially if you don't fully understand how and why).
In short: your idea introduce more complexity, and I can't see any problem that it could solve (while seeing many that it creates).
A lot could be improved by educating users to cast their witness votes responsibly.
For example, you are voting for dbuzz, a "witness" whose node is missing blocks for over a week which not only works against reliability of Hive, but also against your own best interest as they are ranked way higher than you, while doing really, really bad job.
Indeed there's a big potential for things to go wrong. I saw a similar idea from my fellow Top100 witness @igormuba and I really liked his argument about the Top20 being "too centralized" and have similar objections to his about each account being able to cast more votes than spots in the Top20, which was one of the vulnerabilities that allowed people like Sun Yuchen to rise a few sock-puppets using a couple whale accounts.
If not by increasing the Top20 spots, I would like to know opinions about the idea of decreasing the amount of votes each account can cast or at least dilute the votes. I know something like this causes an increase in complexity but is an idea I would like to see discussed.
That is something I also find very important. I even created some topics calling for voters of dead witnesses to uncast them as they are missing too many blocks
I called DBuzz admins on this a few times as it also bothers me to see their server going down too frequently. Whenever I have issues I run to deactivate my witness in order to not miss more blocks as I know how that makes me look unreliable. I was giving chances for correction because they seem nice people but in matters of being a witness, it's about stability.
Thank you for the reply and sorry for any inconvenience.
There's always a tradeoff between reliability, security, flexibility etc.
AFAICT, the idea for witness votes was to be able to cast unlimited amount of votes for witnesses that are "good enough", it was limited to 30 for practical reasons, as you can see it's even hard to keep that number well maintained.
And no, Yuchen-Gate wasn't allowed by 30>20 thing. Please keep in mind that in case where witness votes would be limited, whole landscape would look different, i.e. change would also affect current witnesses, not only his suckpuppets (sic!) It's just a math. This was discussed many times in the past (including live discussions during HiveFests (rebrainding, right?))
"Seemingly nice" isn't really a good attribute to decide whether someone is a suitable candidate for a witness or not. I'm not nice. :-D
No inconvenience. Thanks for looking out on how to improve Hive :-)
Indeed. That's why I don't work with HR. Soft spot for nice yet incompetent people for the job. Will take node stability and update reliability more for the time being.