Exactly what I thought when I read @danrobinson’s post
I’m uncomfortable with the thought of people being able to rush through proposals without the communities best critical thinkers having time to think through both the short term & long term ramifications as a result of the proposal being passed
That’s fair but in that case should there not be two types of proposals?
Urgent proposal - Should be a rare occurrence (
) to handle emergency situations with a shorter period of time to both vote on & delegate votes for
Normal proposal - Longer period of time to vote on & delegate votes for
Flip side: we do critically think about a proposal, think it’s good, implement it. However, there’s an unforeseen critical exploit introduced, and funds are at risk as a result.
Quite frankly, I don’t even know if this is possible, but–if it is, you’d then have to wait that same period before you could revert.
What is the attack vector against governance that governance itself could stop?
very good question 
tricky. my answer is that they are too numerous to count in a purely decentralized model.
a decentralized governance group has little recourse should this happen - it’s simply too slow
we all know of the 51% attack concept - here the bar is lower and there is nothing preventing someone from pulling off a 4% attack anonymously
however, there are several critical steps in governance that could mitigate the concern. each relies on some form of centralization.
Delegates have the ability to move a proposal to a formal vote. The community can recommend proposals, but it’s no longer an autonomous function. Just make the trigger multi-sig. Here’s the trade-off.
Pros
-No single person can shove a deleterious proposal through on volume of UNI alone
Cons
-No longer a decentralized function either.- Prone to internal politics, and can easily be utilized to stall efforts to progress the platform
Do none of the above, but let’s continue with the idea of an ‘approved delegate’. Here is the post-hoc solution. If an attack is imminent, then give them a multi-sig ability to ‘cancel’ a vote.
Pros
-No single person can pull off an attack
Cons
-not decentralized when you give a small group ‘veto’ power
-may also expose a critical weakness of multi-sig, because it assumes all delegates are paying attention and ‘able’ to vote
Extend the power of a governor. This ‘governor’ address (presumably uniswap employee) already has the override power to ‘cancel’ a vote. A classic fail-safe mechanism that is built into the code, unless i’m reading it incorrectly. There should be an ‘appeal’ process that allows us to ask the Governor to ‘cancel’ a vote.
Pros
-Nothing in the code needs changing
-No single bad agent can get away with an attack
Cons
-can be misused in a trustless system
this is a matter for a different post altogether, but we are at the stage where the foundational assumptions behind ‘decentralized social groups’ should be challenged.
so, maybe a ‘hybrid’ model that mixes decentralized with centralized structures. the purists will cry foul because they prefer to see the universe as a convenient, non-quantum, arrangement of 1s and 0s. fair enough, the clockmakers among us may be right in the end, but i have my doubts. the point of innovation is to ‘temporarily suspend your disbelief’, because it’s the only way to trigger the novelty center of the brain. if we remain stuck in our beliefs, and hold them as sacrosanct pillars, we may as well let go of any claim to critical thought.
otherwise, a purist approach to decentralization will succeed, or not, on the assumption that humans can align on matters of mutual benefit. find precedence and i may be convinced. this is why satoshi was brilliant - he turned it into an economic challenge, and deferred the question of ‘trust’ to one of economic viability. here’s the irony. in order for a truly ‘decentralized’ system to work, we would have to abandon selfish needs and privilege the group over the self. in that system we no longer rely on PoW or PoS to achieve consensus on anything. i fear we are mixing decentralized wealth, identity, ownership of data (SELF) with decentralized governance (SOCIAL). the fact that it works so well with one, does not automagically confer the same outcome for the other.
Can you give an example of one? Specifically, I’m interested in attacks where there is a time delay on governance proposals between creation and delegation snapshot, and someone executes a governance attack that can then be mitigated by governance, but only if the delay is short.
I actually created an account specifically to express this concern as well since I wanted to vote on the Dharma UNI vote and renewing LP. After reading through the thread though, my mind changed and I now understand and am in favor of delayed voting. 
THAT’S TRUE!
and us in the Liquidity Pools??? I am locked on ETH/UNI liquidity.
WE ARE LIKE SOLDIERS IN THE FRONT LINE FIGHTING A WAR WHO CAN "NOT "VOTE!!!
No disagreement! Right now in the protocol there is no reason that a governance proposal would need to be passed within X days. And as a general principle I hope there never is such a reason.
1 month is kind of long, but could easily see 1 week (and then one week for voting).
I believe this change is a good one and is by far the easiest to implement, I called it the preparation period.
It provides the necessary safety check for the system and allows for voter mobilization.
It also, albeit not perfectly, allows the UNI/ETH LP tokens to participate in the governance matters if they’re perceived as critical.
I also support the concern that 48 hours might not be enough - but it shouldn’t be more than a week.
I don’t think that the preparation period should be shorter than the voting period.
If anything, it takes more time to review, audit, and discuss than to vote.
I could see a 6-day preparation - 4-day voting sequence working fine, as an example.
everyone please! Help me join and get my reward. This is my first time working on a project.2
If you’d like to support or oppose the proposal to increase the votingDelay, the snapshot voting on the matter starts on Oct 30 and finishes on Nov 1, 2020.
https://gov.uniswap.org/t/temperature-check-should-we-increase-the-votingdelay/7818
The Maker vote using flash loans shows the unintended consequences that may result from making it easier to delegate mid-vote
I personally don’t like the delegate option at all , prefer the direct vote as far as gas fees goes they really have been that bad at all lately