Propose DAO phase periods and fees

[ManfredKarrer]

As discussed in #45 I will propose here the periods for the DAO phases. Additionally I would use that for suggesting BSQ fees for proposal and voting.

Phase duration is initially hard coded but can be changed via DAO voting. I would prefer though to use that option only if really required and to get it right from the beginning. We collected some experience with the manual process over the last year so we can assume that a months cycle is reasonable.

Note that 1 day is roughly 150 blocks (real average time is about 9.35 min). We cannot sync with calendar dates but if we use even numbers and start the genesis block on a even number (if we get it mined, but with high fees that should be doable) we stay in a grid with migth be easier to remember.
The breaks are required to avoid problems with re-orgs and should be at least 10 blocks. I think the longest re-org in Bitcoin was 4 blocks. The BREAK1 might be longer as it can serve as a review/discussion buffer for voters (proposal cannot be changed anymore.

Phase durations

1. PHASE_PROPOSAL:
   Here proposals can be submitted and removed. Editing is not supported but removing and re-sumbitting has the same effect.
   Suggested duration: 3600 blocks (about 24 day)

2. PHASE_BREAK1:
   As said that break can be longer to add some buffer for discussions/reviews.
   Suggested duration: 150 blocks (about 1 day)

3. PHASE_BLIND_VOTE:
   As said that break can be longer to add some buffer for discussions/reviews.
   Suggested duration: 450 blocks (about 3 days)

4. PHASE_BREAK2:
   For reorg protection.
   Suggested duration: 10 blocks (about 100 min)

5. PHASE_VOTE_REVEAL:
   Here the voter need to be online so that his app can publish the reveal transactions which reveals the secret key for the previously published encrypted votes.
   Suggested duration: 450 blocks (about 3 days)

6. PHASE_BREAK3:
   For reorg protection.
   Suggested duration: 10 blocks (about 100 min)

7. PHASE_RESULT:
   This triggers the result calculation. We don't need more then 1 block as it is just a trigger but to stick with even number I suggest 10 blocks. There are no re-org issues here as no new transactions have been created.
   Suggested duration: 10 blocks (about 100 min)

The total cycle would be then 4680 blocks which would be about 9.36 min/block if we use the minutes of a average year (525 949 minutes / 12 month = 43829 minutes -> 43829/4680=9,365 min/block which fits nicely to the rough average). But as said above we should not intend to stick with calendar months otherwise we will end up to be always slightly off which is probably worse than having our independent cycle.

Fees

1. Proposal fee:
   To avoid spam we use a fee for submitting a proposal. If a proposal is removed the fee is lost and by re-sumbitting it it need to be paid again. The fee can be changed by DAO voting.
   As the fee is defined in BSQ it is subject to BSQ volatility and might require adjustment over time.
   As we want to incentivize also small contributions we try to keep the fee low.
   Suggested fee: 2 BSQ

2. Vote fee:
   Again as spam protection and to have a regulatory elemente to make voting more expensive if we get too many voters who are not well informed but see voting as "fun" we use a fee here as well. As it can be expected that we will not have both of the mentioned problems we can start also with a rather low fee.
   Suggested fee: 2 BSQ

Note: In case of changes by voting there will be a max. ration for the allowed change. It is not defined yet but might be max 4 times in both directions. E.g. a 4 BSQ fee can be changed in one cycle only to max. 1 BSQ or 16 BSQ. But it can be repeated so next cycle it could be 0.25 BSQ or 64 BSQ.

[devinbileck]

A few comments.

1. Is it necessary to have an extended PHASE_BREAK1? Would any discussions/reviews at this point be too late since if a reviewer asks the requester to adjust their requested amount they would be unable to since we don't have the ability to edit proposals and cannot submit a new one during this phase. Perhaps asking the requester to provide more context/background to their request would be acceptable during this phase, but could/should that instead be done during PHASE_BLIND_VOTE? As I suspect most users may just review proposals while casting their votes anyways.

2. Should PHASE_VOTE_REVEAL be increased? My concern is that 2 days might not be enough time (e.g. no computer/internet access while travelling or away during a long weekend). At least 3 or 4 days might be better. And perhaps starting with a longer phase when the DAO launches might be better than the alternative (users missing the phase; invalidating their vote) and can always be decreased via DAO voting at a later point in time if it is determined that a majority of votes are revealed within 2 days.

3. I guess we also need to decide max increase/decrease of these parameters via DAO voting for these phases as well? Since the max increase/decrease itself cannot be changed via DAO voting, we need to get it right before the DAO launch (unless we want to be able to vote on those as well?). All phases have a max increase/decrease of 3, except for PHASE_BREAK2 which has a max increase of 23 (not sure if that is just a typo?).

[ManfredKarrer]

Re 1:
We had some discussions around that in the past so thats why I adjusted to accoring to that outcome.
I see a bit of a benefit to get some extra time before people start to vote and maybe make wrong decisions if some context needs to be communicated via other channels. E.g. someone makes a dangerous param change request and some stakeholders want to have time to raise awareness to other stakeholders before they start voting.
Beside that this longer break could be used for a solution to freeze/archive the proposals so in case they got changed in GH the original is still available (still an open issue but not critical for launch IMO).

Re 2:
Fine for me. We can make both blind vote and reveal 3 days.

Re 3:
The 23 value was a mistake. Will fix it to 3 as well.
I want to avoid to over-use the param change framework. I think the min/max should give enough headroom and are already prob. too large. Bigger changes can be done in iterations. The min/max only relates to the current value. So if its 2 you can double up each month.

There will be some additional restrictions not covered ny the min/max like vote threshold cannot be lower than 50% or break phases cannot be reduce to < 6 blocks (reorg risk) and they cannot be negative. Those validations are still WIP and I will work on that soon.

[devinbileck]

1. Good point, makes sense.
2. Sounds good to me.
3. I agree 3 seems high. 2 (or maybe even 1.5?) does seem more reasonable.

[ManfredKarrer]

Will wait for a bit more feedback and then change to your suggestions.

[ripcurlx]

Re 2: I'm also for extending the vote reveal phase to the same length of the vote phase, as it might be frustrating if someone voted, but didn't get her vote count because of the short reveal time. Maybe we should think about adding the phases to the event calendar so people could get alerts when they need to start up their client? Doing it via the mobile app might also be a way to do it, but then we need to find a good way to synchronize it.

I agree with everything else 👍

[sqrrm]

Re: 2 I'm also in favor of a longer reveal time.

Otherwise I like these settings, I don't worry too much about the changing of parameters, it will be possible and I don't think these settings will be too far off what we'll want.

[justpaulgmx]

Well thought out as always, +1 here.

[ManfredKarrer]

So lets change from 4 days to 3 days for blind vote and from 2 days to 3 days for vote reveal.

[ManfredKarrer]

Updated durations with 3 days both blind vote and vote reveal phase.

[ManfredKarrer]

Also reduced min/max factor from 3 to 2 for phase durations.

[ManfredKarrer]

I would say lets close that if noboday has further concerns.