Skip to content
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.

Delegate should not punished by DPoS violation for first rounds #5110

Closed
shuse2 opened this issue Apr 6, 2020 · 2 comments · Fixed by #5117
Closed

Delegate should not punished by DPoS violation for first rounds #5110

shuse2 opened this issue Apr 6, 2020 · 2 comments · Fixed by #5117
Assignees
Milestone

Comments

@shuse2
Copy link
Collaborator

shuse2 commented Apr 6, 2020

Expected behavior

Delegate for first rounds are punished for the DPoS violation

Actual behavior

{
 "id": "7620152438571012831"
}
15:47:52 INFO lisk-framework: Punishing delegate for DPoS violation (module=lisk:app)
{
 "id": "17099278745515138981"
}
15:47:52 INFO lisk-framework: Punishing delegate for DPoS violation (module=lisk:app)
{
 "id": "10681471986634929949"
}
15:47:52 INFO lisk-framework: Punishing delegate for DPoS violation (module=lisk:app)
{
 "id": "17861655877572574378"
}

Steps to reproduce

Run a node for several rounds, and try to sync with the node

Which version(s) does this affect? (Environment, OS, etc...)

4.0-

@ManuGowda
Copy link
Contributor

  • Blocks cache needed to be sorted desc
  • Used hash onion need to filtered including 3 rounds (103 * 3)

@shuse2
Copy link
Collaborator Author

shuse2 commented Apr 7, 2020

For the hash-onion, it should leave at least one entry per account.
If there are more than 2 entries, the entries that are not the highest height can be removed after finality.

ManuGowda added a commit that referenced this issue Apr 7, 2020
Delegate should not punished by DPoS violation for first rounds - Closes #5110
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants