DIR 4 - Protection from the ambush attack

[LefterisJP]

Changelog

13-06-2016: DIR created

Problem Definition

With the DAO v1.0 code there is the possibility of a proposal that is quite bad to be made. Since the proposal is bad and has no chance of passing DTH may refrain from voting. At the very end of the voting period a malicious attacker with a lot of tokens may put all of his "yes" votes and pass the proposal when none was expecting it.

Proposed Solution

The solution to the ambush attack is quite simple. An implementation of it can be seen here. The idea is to have a period of days before the end of the debating period by which the proposal needs to have more "yea" than "nay". This is a check that is implemented in a function that anyone can call. If that check is not satisfied then the proposal will not be executable.

As an extra addition towards this issue we can also add a splitGracePeriod which is essentially a period of time between the end of the voting period and the execution of the proposal when people can withdraw from the DAO and lose no funds. An implementation of this can be seen here

[p-s-dev]

Another possible design for this might create something like "max number votes per day". This could be a linear or exponential function over the voting period, decreasing from 100% on the first day to possibly 2% on the last day. When a vote comes in, if it exceeds the maxVotesPerDay, the extra votes would be tallied to a pendingVotesBalance variable. When the next vote comes in, it counts the vote and tries to add any votes from the pendingVotesBalance, up to the max for the day. Ideally, there would be an automated daily execution so that any pendingVotes automatically fill any days that have no reached maxVotesPerDay. This design might create more of a psychological desire to vote early, rather than simply shifting the ambush attach to daysBeforeEndOfDebatingPeriod -1.

[GriffGreen]

If this DIR is implemented, along with DIR 3 which makes the no votes no longer contribute towards quorum. I believe the Minimum Proposal Debate Periods should also decrease to compensate for the increased execution time.

As a mini DIR within this DIR... I believe this allows us to address a real problem that is hurting The DAO

Changelog

14-06-2016: mini-DIR created
16-06-2016: lowered lawyer's time to 1 day from 1 week

Problem Definition

The DAO is very slow to act, even in cases of need. For instance, if the DAO needed to make some sort of update to its code to add a function that would allow the DAO to hold equity in a company but The DAO for some reason wanted a lawyer to spend a day reviewing it (silly example but whatever), here would be the steps:

1. Write the proposal and deploy it's smart contract (2 days)
2. Get it whitelisted by the Curators (3 days)
3. Call newProposal() and wait for DAO Token Holders to vote (14 days)
4. Wait the splitGracePeriod (3 days)
5. Then someone calls executeProposal() so the lawyer can finally receive payment can actually do the work (1 day)
6. Then the changes would need to get implemented into the code (1 day) then the cycle will repeat.
7. The new DAO Contract would get deployed (1 day)
8. Get it whitelisted by the Curators (3 days)
9. Call newProposal() and wait for DAO Token Holders to vote (14 days)
10. Wait the splitGracePeriod (3 days)
11. Then someone calls executeProposal() so the DAO migration can begin...

I will do the math for you... that process takes The DAO 51 days to accomplish.... and thats not including the time it takes for the users to actually migrate to the new DAO.

45 days is an eternity in crypto.... For example 45 days ago the price of ETH was $9.15 USD and today it is > $18 USD this is quite the handycap. If the DAO is to compete with regular companies that can make a decisions in matter of minutes, The DAO needs to shorten the time it takes to make decisions not lengthen it (splitGracePeriod added 3 days)

Proposed Solution

Very simple:

minProposalDebatePeriod = 6 days
minSplitDebatePeriod = 60 hours (2.5 days)

Note that these are MINIMUMS! If a Contractor wants to, they can still make the There is no longer a disincentive to vote no and because the preSupportTime = 2 days if a complicated proposal reaches quorum and the DAO Token Holders don't think there was enough time for DAO Token Holders to debate the suggested Proposal then they can always vote no and the proposal will not pass. And because the splitGracePeriod = 3 days if this some how fails DAO Token Holders will be able to split the DAO or Withdraw() from the DAO if they feel it was rushed.

If this was implemented the above example would only take 35 days... Still an eternity, but it is still an improvement. Also, remember that Jordi has already implemented Liquid democracy, so that if a DAO Token Holder wants to go on vacation, they can send their DAO tokens to a DAO Token Holder Pool.