33 lines
1.7 KiB
Markdown
33 lines
1.7 KiB
Markdown
|
BSIP: 13
|
||
|
|
Title: Disable negative voting on workers
|
||
|
|
Authors: Daniel Larimer <dan@cryptonomex.com>
|
||
|
|
Status: Draft
|
||
|
|
Type: Protocol
|
||
|
|
Created: 2015-03-09
|
||
|
|
Discussion: https://github.com/cryptonomex/graphene/issues/607
|
||
|
|
https://github.com/cryptonomex/graphene/issues/565
|
||
|
|
|
||
|
|
# Abstract
|
||
|
|
|
||
|
|
This proposal fixes a potential attack vector that might be exploited by rich shareholders that hold more collective voting power than the last approved worker (usually a refund/burn worker).
|
||
|
|
|
||
|
|
# Motivation
|
||
|
|
|
||
|
|
A whale of a group of whales can take funds from the reserve pool by creating a worker and instantly approve it with his stake. Shareholders and proxies can disapprove the new worker but only have a small time-window before the attacker makes a profit.
|
||
|
|
|
||
|
|
# Rational
|
||
|
|
|
||
|
|
Pro-active downvoting is a losing proposition. An attacker can create 1000 workers and the network will not allow you to down-vote so many workers. The only real solution is to *upvote* refund workers or removing DOWNVOTING is the actual solution to this attack.
|
||
|
|
|
||
|
|
Since upvoting of refund workers results in a higher barrier of entry for new legit workers, the solution proposed here is to remove down voting entirely.
|
||
|
|
|
||
|
|
Furthermore, a negative vote is equivalent with upvoting all alternatives and results in slightly narrower gaps between votes. It compares pretty will with comparing -1 with +1 (currently) and 0 with +1 as in this proposal.
|
||
|
|
|
||
|
|
# Specifications
|
||
|
|
|
||
|
|
This proposal could be implemented by removing the ability to cast negative votes or by not taking negative votes into consideration during vote counting in the maintenance interval.
|
||
|
|
|
||
|
|
# Copyright
|
||
|
|
|
||
|
|
This document is placed in the public domain.
|