Should we incorporate vote vesting (limiting voting attacks and rogue proxies)?

Started by bobmaloney, September 27, 2015, 08:21:53 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sittingduck

Any delay on incoming votes also reduces response times when it matters most.   I suspect fast responses to outside threats are more important than slowing down internal threats. 


Sent from my iPhone using Tapatalk

bobmaloney

I think Bitshares is making a wise move in eventually including vote decay as a tool to weight active vs. non-active voters, gradually faze out votes from lost keys, etc.

However, I think the same type of gradual delay is required on the incoming side as well, in order to limit the possibility of rogue proxies or coordinated voting attacks.

I would propose consideration of vote vesting as one type of safety mechanism – to allow for community voter mobilization in the case that an extremely large vote is placed.

Maybe we could start with something like a 24 hour 0% vest period (but with network notification of incoming vote), followed by initiation and gradual vesting to complete within the next 24 or 48 hour period?
"The crows seemed to be calling his name, thought Caw."
- Jack Handey (SNL)