Show Posts
211
Stakeholder Proposals / Re: BSIP Proposal #5 to address voter apathy for witnesses
« on: December 24, 2015, 02:10:14 pm »
These are very complex subjects that probably were never fully thought through seriously enough
About 1:
At first I did not really like bsip#5's idea of expiring votes, but now I think we probably should focus on the potential issues that the current system could create and have a way to handle cases of lost keys and/or apathetic votes hanging around.
Bsip#5's purpose is not to create instability or drastical and istantanueous changes in voting, it is just a countermeasure that would "kick in" ONLY if needed.
If the current voting system and its partecipants prove to be succesfull enough to guarantee a well working environment, bsip#5 would never really kick in!
If proxies and not-proxying shareholders continue to remain actives, you could easily forget about bsip#5 at all! It will be there to check the "health" of the system, but doing nothing.
Bsip#5 would kick in ONLY when an "issue" arises... only to improve the security and the health of the system in that situation.
We should take "votes hanging around" and "cases of lost keys" (think about a big proxy have such a problem) seriously. And we should have a system that prevents those events to harm the system itself.
I don't think the real question about bsip#5 is "yes or no?", but probably it should be "how?"
How such a system should works?
To me, it should NOT be something that could make drastical and istantanueous changes, instead it probably should kick in only after "x" amount of inactivity-time and then acts in a very slow way over a long enought period of time.
IF properly configured, Bsip#5 would NOT cause active/voted witnesses to be fired, neither inactive/non-high-voted witnesses to step-in in place of the active ones.
It only would make votes more reliable and truthful.
About 4:
I would really like to have more metrics for monitoring witness performance, but I also think it is pretty hard to find good an reliable metrics to evaluate witnesses work, above all in this early stage.
For example, the only metric available now is "missed blocks", and I think that as right now it is not a good metric to evaluate witnesses, not at all!
Lots of witnesses have lots of more missed blocks than me, still I do NOT think they are less reliable or "worthy" than me.
They probably were just more unlucky, and had to manage more unexpected crashes, freezes, forks and so on due to bugs in the node and NOT due to their "lack of skills" or something that should make them to be fired anyway.
In a system that relies on current missed blocks for the future evaluation (if we can not erase the current missed blocks count), could be even more harmful:
The current witnesses that participated to the testnet, that bootstrapped the system, that managed a way less reliable witness_node, that spent lot of times in reporting strange behaviours, crashes, freezes etc, the ones that really helped the system to improve and achieve a better and more reliable status...In such a system All these pleople/witnesses would also be the ones with probably (on average) higher missed blocks and so the one that would be more unfairly penalized by that metrics.
All this just to say that we should be very carefull on deciding what is a fair and good metric to really evaluate witnesses work and their "worthiness", ABOVE ALL in an early stage as the present one.
About parts of 2) and 3):
I think that have good, worthy, and reliable "ready-to-be-active witnesses" is as much important as have good witnesses.
One simple and probably reliable way to achieve that, is to "push" want-to-be witnesses to run a witness_node in the Demo/Dev chain.
(Maybe also by remunerate them just that little enough to be able to run a low end vps to sustain the demo/dev chain power required)
Only after they prove to be capable and reliable in running as witness in de Demo chain, they should be taken into account by shareholders to be voted in the Main chain.
About 1:
At first I did not really like bsip#5's idea of expiring votes, but now I think we probably should focus on the potential issues that the current system could create and have a way to handle cases of lost keys and/or apathetic votes hanging around.
Bsip#5's purpose is not to create instability or drastical and istantanueous changes in voting, it is just a countermeasure that would "kick in" ONLY if needed.
If the current voting system and its partecipants prove to be succesfull enough to guarantee a well working environment, bsip#5 would never really kick in!
If proxies and not-proxying shareholders continue to remain actives, you could easily forget about bsip#5 at all! It will be there to check the "health" of the system, but doing nothing.
Bsip#5 would kick in ONLY when an "issue" arises... only to improve the security and the health of the system in that situation.
We should take "votes hanging around" and "cases of lost keys" (think about a big proxy have such a problem) seriously. And we should have a system that prevents those events to harm the system itself.
I don't think the real question about bsip#5 is "yes or no?", but probably it should be "how?"
How such a system should works?
To me, it should NOT be something that could make drastical and istantanueous changes, instead it probably should kick in only after "x" amount of inactivity-time and then acts in a very slow way over a long enought period of time.
IF properly configured, Bsip#5 would NOT cause active/voted witnesses to be fired, neither inactive/non-high-voted witnesses to step-in in place of the active ones.
It only would make votes more reliable and truthful.
About 4:
I would really like to have more metrics for monitoring witness performance, but I also think it is pretty hard to find good an reliable metrics to evaluate witnesses work, above all in this early stage.
For example, the only metric available now is "missed blocks", and I think that as right now it is not a good metric to evaluate witnesses, not at all!
Lots of witnesses have lots of more missed blocks than me, still I do NOT think they are less reliable or "worthy" than me.
They probably were just more unlucky, and had to manage more unexpected crashes, freezes, forks and so on due to bugs in the node and NOT due to their "lack of skills" or something that should make them to be fired anyway.
In a system that relies on current missed blocks for the future evaluation (if we can not erase the current missed blocks count), could be even more harmful:
The current witnesses that participated to the testnet, that bootstrapped the system, that managed a way less reliable witness_node, that spent lot of times in reporting strange behaviours, crashes, freezes etc, the ones that really helped the system to improve and achieve a better and more reliable status...In such a system All these pleople/witnesses would also be the ones with probably (on average) higher missed blocks and so the one that would be more unfairly penalized by that metrics.
All this just to say that we should be very carefull on deciding what is a fair and good metric to really evaluate witnesses work and their "worthiness", ABOVE ALL in an early stage as the present one.
About parts of 2) and 3):
I think that have good, worthy, and reliable "ready-to-be-active witnesses" is as much important as have good witnesses.
One simple and probably reliable way to achieve that, is to "push" want-to-be witnesses to run a witness_node in the Demo/Dev chain.
(Maybe also by remunerate them just that little enough to be able to run a low end vps to sustain the demo/dev chain power required)
Only after they prove to be capable and reliable in running as witness in de Demo chain, they should be taken into account by shareholders to be voted in the Main chain.
