Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Witness punishment #185

Open
1 of 5 tasks
MatusKysel opened this issue Dec 14, 2018 · 3 comments
Open
1 of 5 tasks

Witness punishment #185

MatusKysel opened this issue Dec 14, 2018 · 3 comments
Labels
enhancement New feature or request

Comments

@MatusKysel
Copy link
Contributor

MatusKysel commented Dec 14, 2018

Please, fill the following template when reporting an issue.

Issue type:

  • Bug report
  • Documentation issue
  • Improvement suggestion
  • Question / support request
  • Other

General description

We should introduce punishment rules for missing blocks and not feeding current price. We suggest to disable witness for number of rounds and remove percentage of his votes when witness misses block or does not update price feed regularly.

Expected behavior

First step will be change of counting missed blocks.
Change:
Witness misses block when does not deliver block under 2.5s ( SOPHIATX_BLOCK_INTERVAL - SOPHIATX_BLOCK_TIME_BUFFER ).

Algorithm proposal:
We will keep track of two counters:

  • E_COUNTER -> exponential counter will disable witness for 2^E_COUNTER number of rounds, until shutdown_witness_operation will be executed, because witness did not delivered block in the last 24h. This operation will also set this counter to zero and successfully mined block will decrement this counter. When witness is disabled from round schedule, it is considered non-active.
  • P_COUNTER -> percentage counter will reduce witness total votes by P_COUNTER %. Witness can regain his full power ( reduce P_COUNTER ) when community will revote for this specific witness.

This algorithm takes place only if there is 31+ active witnesses so the network overall health is preserved.

There are two possibilities to increase those counters:

IF witness misses block:
E_COUNTER ++
P_COUNTER ++

IF witness_feed is older then 2H (this validation should be run every TODO H)
P_COUNTER ++

@MatusKysel MatusKysel added the enhancement New feature or request label Dec 14, 2018
@Firexsprit
Copy link

If you introduce a way for witnesses to lose votes (not justifyable for a few missed blocks, only for major neglect imo) then you also need to incentivise the community to vote, since that is not the case currently.

This should be very carefully balanced. I propose that both counters regenerate fully as soon as the node is operational again within 24h.

@ejossev
Copy link
Contributor

ejossev commented Dec 19, 2018

The idea is, that the witness will loose small percentage (in 0.1% ranges) of received votes for every missed block - small enough that it does not matter when there are sporadic loses. However, would the witness loose huge amount of blocks, i.e. due to day-long server failure or consistent problems with networking etc., the loss can push him out of the witness group.
One can gain the loss back when the voters vote for him again - so the witness will need to re-apply for voters support.

@Firexsprit
Copy link

Firexsprit commented Dec 28, 2018

Frankly, this is a terrible idea at this point. Witness nodes are running at a loss at current prices already. Voter support is incredibly hard to gain (back) as there is zero incentive for token holders to vote. I agree there should be mechanisms to get bad nodes from the list but I don't see permanent reduction of votes (it will be permanent, people don't vote again) as a well balanced way. I would strongly prefer giving holders incentives to vote good nodes and show them proper metrics (e.g. blocks missed last week, latancy, uptime last month, ...) rather than this kind of penalization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants