You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 30, 2022. It is now read-only.
so, if a small network has less than 21 active producers, a producer cannot leave the schedule because the unregprod will be ignored. This is dangerous for network stability because a BP can unregprod and switch off the server, being sure that they did the right thing. The network will not be able to replace the BP or remove it from the schedule, unless they create sock puppets to fill in 22 positions.
I believe this rule should be removed. It's causing a danger for small networks and doesn't make sense for big ones.
It should be modified to disallow reducing the schedule to zero only.
The text was updated successfully, but these errors were encountered:
It would be better to make this number configurable and able to be modified by the existing BP vote as it presents a risk of network lockup in certain edge cases.
deckb
transferred this issue from EOSIO/eosio.contracts
Apr 21, 2021
There is a more general configuration for the system contract that should be implemented for this contract. I believe we can roll this into that change.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Line 125 in https://github.com/EOSIO/eosio.contracts/blob/7c042002b903bbf13c7ae37851f03edf58ae9ff8/contracts/eosio.system/src/voting.cpp
so, if a small network has less than 21 active producers, a producer cannot leave the schedule because the unregprod will be ignored. This is dangerous for network stability because a BP can unregprod and switch off the server, being sure that they did the right thing. The network will not be able to replace the BP or remove it from the schedule, unless they create sock puppets to fill in 22 positions.
I believe this rule should be removed. It's causing a danger for small networks and doesn't make sense for big ones.
It should be modified to disallow reducing the schedule to zero only.
The text was updated successfully, but these errors were encountered: