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

[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?