Proposal “Expedite-60-20-20-reallocation“ (Closed)Back

Title:Expedite-60-20-20-reallocation
Owner:lysergic
One-time payment: 1 DASH (55 USD)
Completed payments: no payments occurred yet (1 month remaining)
Payment start/end: 2023-10-11 / 2023-11-15 (added on 2023-10-11)
Votes: 529 Yes / 76 No / 9 Abstain

Proposal description

This proposal aims to expedite the previously passed 60-20-20 treasury reallocation proposal https://www.dashcentral.org/p/TREASURY-REALLOCATION-60-20-20.

Background

The next core release is v20 and with it comes a number of changes including the activation of platform.  This release will actually be staged over two hard forks.  The first hard fork will introduce the new features in v20, eg the Randomness beacon quorum members, Asset locks/pools, Bitcoin back ports etc.  This hard fork is not dependent on Platform/Evolution being ready for deployment and can activate as soon as enough the of the network has upgraded.  The second hard fork is for Platform activation and the Treasury reallocation as well as starting the collection of Evonode rewards into the Asset Locked Pool.  This hard fork is dependent on platform being ready and could take some time longer than the first fork as testing and bug fixing continues on Platform on testnet.  Dash Core v20 is currently almost complete and could be expedited to mainnet to facilitate this change.

The change

Voting YES on this proposal would activate the Treasury reallocation at the first hard fork (sooner) rather than the second hard fork, this will give proposal owners like DCG and the incubator more funds sooner, since we don't know exactly how much longer Evo needs for testing.  Voting NO means nothing changes and the Treasury reallocation still takes place on the second hard fork with the activation of Platform when it is ready.

Pros

  • Activating the 60-20-20 change sooner helps DCG finish the job and keep critical staff that are working hard to deliver.
  • By bringing forward the reallocation change, we make the fork that activates Platform less risky due to fewer moving parts.

Cons

  • Some voters may feel like this is opening your presents before Christmas.
  • Some small effort to re-shuffle code to support this change.


I have talked this proposal over with Quantum Explorer and Pasta and both agree to change the release accordingly if this proposal passes.  By voting YES you may help secure the devs some extra funding a month or two sooner and help retain someone's job and help us get Platform out the door finally.



Show full description ...

Discussion: Should we fund this proposal?

Submit comment
 
3 points,1 year ago
*** Thanks to everyone that supported this proposal! ***

Here is the PR that implements this change.

https://github.com/dashpay/dash/pull/5639
Reply
3 points,1 year ago
I heavily support this proposal. Times are very tough. I with the rest of the team are working around the clock to stabilize and release Platform, but we haven't even started stress testing.
Reply
8 points,1 year ago
Just in case Rion's proposal fails (at least this cycle), DCG is renouncing to 500 Dash of desperately needed supplemental funds.
There were other occasions as well, when thoughtful consideration about the *potential*passing* of proposals from other POs (which ultimately failed anyway!!) caused a loss of desperately needed funding for DCG.

This could easily be fixed by introducing a new feature:

-A variable Dash amount to select during proposal creation:
"All monthly available, but unclaimed Superblock funds"

With the following limitations:

-such Variable amount can only be selected for a SINGLE budget cycle, but never as a multi-month proposal !

-if multiple such proposals are submitted, which use this same "Variable Leftover Superblock Funds" amount,
and in the event that multiple such proposals are approved, then only the one with the most net votes gets funded, while all the other proposals who also used this variable amount would be ignored and discarded.

Would such a feature sound reasonable to you? if not, why?
Reply
4 points,1 year ago
I'll vote yes. It will be good for Dash, to keep our developers as long as possible.
Reply
4 points,1 year ago
I guess developers are now starting to realise that they will run out of funding, before Dash Platform can activate on Mainnet. Another sign that DCG started survival mode (lowering their runrate to $125,000) way too late this year.

Voting yes on this decision proposal (and thereby voting yes on implementing the 60-20-20 change sooner), does not diminish the risk in any way. It just means miners will be confronted with a mining halving of their block rewards even sooner then initially intended (first hard fork instead of second hard fork).

At some point the question arises : what is best for the Dash network, versus what is best for DCG ?
Reply
4 points,1 year ago
Also having only 11 days for debating this decision proposal is very much on the short side.
Reply
2 points,1 year ago
> Also having only 11 days for debating this decision proposal is very much on the short side.

Indeed, however MNOs these days like to vote late, so I think most everyone will get a chance to see this and vote on it.

> what is best for the Dash network, versus what is best for DCG ?

I am of the opinion that keeping devs is very much in the interest of the network.
Reply
2 points,1 year ago
''The first hard fork will introduce the new features in v20, eg the Randomness beacon quorum members, Asset locks/pools, Bitcoin back ports etc.''

This first hard fork will most likely cause little friction with miners (likely to receive their support). But this decision proposal intention is to add the halving of the miner blockrewards to the first hard fork, which increase the chance for friction with miners.

So what is better for the Dash network ? Having at least one of the hard forks activate without much issue or having the first hard fork most likely cause an issue with miners from the get go ?
Reply
2 points,1 year ago
To be honest, i was not even aware there are two hard forks in Dash Core v20.

I just think integrating the halving of the miner rewards directly in Dash Core v20 (either in hard fork 1 or hard fork 2), brings a lot of risk to that update.

So this decision proposal does little to that risk in general, it just shifts it from later to earlier.
Reply
1 point,1 year ago
Cool, then no harm in voting YES, in fact, if anything, this way would be more transparent.
Reply
0 points,1 year ago
I think i will vote NO. I rather see the 60-20-20 realloacation activate through a spork that DCG controls (second hard fork), then through having to obtain 60% support of miners (first hard fork).
Reply
1 point,1 year ago
The reallocation ALWAYS required BIP9 to pass first, adding the relloc into the second fork was nothing to do with making it coast through under the radar, and everything to do with activating the platform related components together, which are.

1. Starting Platform.
2. Moving 37.5% of the MN reward into the Asset Locked Pool.
3. The enabling the 60-20-20 reallocation.
Reply
0 points,1 year ago
I think the current hard fork procedure (first hard fork without reloc, followed by a second hard fork containing a spork to implement the reloc) has a far higher chance to activate Dash Platform on Mainnet, then what this decision proposal intends to do (shift reloc to first hard fork).
Reply
3 points,1 year ago
This is not how the second hard fork works; it is activated via the EHF system, which requires the approval of MNs and Miners; the spork simply delays when MNs will approve it; the spork does not cause the hard fork.
Reply
1 point,1 year ago
The second hardfork activates via a SPORK and does not need the BIP9 miner voting.
Reply
3 points,1 year ago
This is not how the second hard fork works; it is activated via the EHF system, which requires the approval of MNs and Miners; the spork simply delays when MNs will approve it; the spork does not cause the hard fork.
Reply
2 points,1 year ago
Thanks for clarifying !
Reply
2 points,1 year ago
So you want to move the halving of the miner rewards up from hard fork 2 that does not require BIP9 miner voting, to hard fork 1 that does require BIP9 miner voting and it directly and negatively affects miners themselves ?
Reply
0 points,1 year ago
Would it not be better to handle the halving of the miner blockrewards / 60-20-20 reallocation through a spork (second hard fork), then through miners needing to support it at least with 60% of mined blocks ? (first hard fork)
Reply
0 points,1 year ago
The aim is to activate the reward reallocation ASAP so that DCG can keep resources needed to deliver this project.
Reply
1 point,1 year ago
Wow, talking about going from a sure thing (spork / manual activation by DCG) to needing 60% support from miners, because DCG is running out of reserves (which everyone could see coming with the state of the crypto market and the late response of DCG to that state of the crypto market)
Reply
0 points,1 year ago
9 days have passed and still no Platform Release Candidate on Testnet. During the last sprint review Pasta mentioned it would be released a few days later (orginally it was scheduled for release third of october 2023 --> https://github.com/dashpay/dash/issues/5582).

This whole project is still plagued with one delay after another, with no sign of an attempt by DCG to address their constant delays.

And now we (MNO's) are asked to expedite the 60-20-20 reallocation, thereby possibly complicating the activation of Dash Platform on Mainnet, as the blockreward reallocation that will negatively affect miners (by reducing their miner rewards in half) will be moved upward from a spork that masternodes need to support into a hard fork that miners need to support with 60%, all so that DCG can request more funding from the Treasury sooner.

Once the reallocation is active and DCG can request more funding from the Treasury, there will be a lot less pressure on DCG to release Platform to Mainnet ASAP (they will get fully funded by then anyways) and i suspect it will lead to further Platform delays.
Reply
4 points,1 year ago
What do you imagine is happening? That we are just twiddling our thumbs? We do our best with the people we have. And the people we have now are great, they are sacrificing pay to get this out the door and finish what we've started. You can see our work everyday on Github, you can see the advancements we have. Week after week we keep on solving issues. And we are making good progress. If you want us to go faster, we can not. For me I can only work until I can't work anymore and I think that's the same for most people.

I don't think more pressure is what is needed here. More pressure with reduced pay will only get people to quit. Or people will break.
Reply
-1 point,1 year ago
I remember pretty much the same reply from you a year ago, when it became clear that Platform would not launch end of 2022. Now i am hearing it again.
Reply
-2 points,1 year ago
Just one simple question then : is Dash Core v20 release candidate 1 on Testnet partly getting delayed due to awaiting the outcome of this decision proposal (as lysergic assumed to be the case) or not ?
Reply
3 points,1 year ago
It wasn't being delayed due to this decision proposal. The reason we don't have Dash Core v20 RC1 is plainly because it wasn't ready yet.

Obviously we are looking closely at this proposal and will adjust accordingly.
Reply
-1 point,1 year ago
beta4 for testnet was released 3 days ago.

If you are looking closely at this proposal (which will run for 10 more days) and possibly need to adjust accordingly, then i have to conclude that this decision proposal could end up delaying the release schedule for Dash Core v20 (currently planned for early November 2023).

As you are then moving from a few days delay (as Pasta mentioned in last Sprint review, that would not affect the timeline) to a few weeks of delay that could indeed affect the v20 release schedule timeline.
Reply
-1 point,1 year ago
It is just another sign to me that DCG is not focused that much on preventing delays.
Reply
-1 point,1 year ago
Unless you plan to release v20 rc1 to testnet shortly and follow it up with v20 rc2 if this proposal passes.
Reply
-2 points,1 year ago
Fully quoting lysergic for reference :

''As for core, you can see their releases here https://github.com/dashpay/dash/releases , they are up to a beta4 of v20 and probably goto RC1 shortly, probably after this proposal is decided.''
Reply
-2 points,1 year ago
Also another simple question : why is the Dash Roadmap not showing anything for 2024 ?
Reply
-2 points,1 year ago
The Dash Roadmap has been brought up before during last Sprint review, so you should be aware how unclear the Dash Roadmap currently is to people (features for 2024 that got deleted, whole 2024 that disappeared).
Reply
2 points,1 year ago
Correction : not Platform Release Candidate, but v20.0.0.0-rc1

The Dash Roadmap also mentions a Dash Platform Release Candidate on Testnet, but they removed any dates / months / years there, a few months back. Last date mentioned on the Dash Roadmap : July 2023.

They even removed 2024 from the Dash Roadmap. Which makes it very hard to understand what feautures are still planned for 2023 and features are planned for 2024.
Reply
0 points,1 year ago
You can see for yourself, the platform releases are here https://github.com/dashpay/platform/releases they recently refreshed testnet and fixed many bugs, platform is still in beta and an RC will come once it is stable enough.

As for core, you can see their releases here https://github.com/dashpay/dash/releases , they are up to a beta4 of v20 and probably goto RC1 shortly, probably after this proposal is decided.

No need to FUD, you can see better than most the constant work going into this project.
Reply
-1 point,1 year ago
So you are saying that DCG is delaying the v20 release candidate because of this decision proposal ? That just shows that DCG is not even trying to limit their delays. Good to know.
Reply
1 point,1 year ago
No. and stop putting words into my mouth or I will be forced to stop responding to you!
Reply
-1 point,1 year ago
''probably after this proposal is decided.'''

Your words, not mine.
Reply
1 point,1 year ago
That doesn't imply one is after the other, what it implies is that there is at least another 2 weeks worth of work left in v20 which you damn well know because you are following the github very closely. Don't play dumb with me, it's unbecoming.
Reply
0 points,1 year ago
All i know is that during the last sprint review it was announced that v20 rc1 would not be released according the github v20 release schedule (4rd october), but that it would be released a few days after the sprint review (later that week) and that this would not impact v20 release schedule (scheduled for early November 2023).

See : https://www.youtube.com/watch?v=51u_2hBwIIc (time stamp 44:22)

Now 10 days have passed without v20 RC1 on testnet and this decision proposal pops up that once again interfers with the release schedule of Dash Core v20 and could very well lead to an actual delay of Dash Core v20, as DCG mentioned its monitoring its outcome and need to adjust v20, if it passes.

There is no 2 weeks worth of work left in v20, which you could verify here on above YT link at time stamp 43:05. Everything is finished for v20 and EHF is in review.

If there are no fixes beyond beta4, and a release candidate for testnet is not released in the next few days, then i will have to conclude that this decision proposal could very well be causing a delay in v20 release schedule (November 2023).
Reply
1 point,1 year ago
There is no conspiracy, v20 will be pushed as fast as is humanly possible.
Reply
0 points,1 year ago
Specially if it takes 10 more days before the outcome of this decision proposal to conclude (voting deadline 10 days).
Reply
-1 point,1 year ago
And with regards to the Platform release, since they removed any year indication on the Dash Roadmap, they could easily be planning this for 2024 instead of 2023.
Reply
4 points,1 year ago
wen EVO
Reply
1 point,1 year ago
wen Platform Release Candidate on Testnet ?
Reply
1 point,1 year ago
Not soon enough apparently. ;)
Reply
0 points,1 year ago
Boy, its time for you to confess what have you done to Flare, to cause him to leave?
Reply
0 points,1 year ago
WTF are you talking about?
Reply
0 points,1 year ago
Boy, you know exactly what i´m talking about.
You better confess what you did to Flare to make him leave!
Reply
1 point,1 year ago
lol. Send me some Dash and I will tell you everything, all the sordid details, even the top secret Evan stuff.
Reply
-4 points,1 year ago
Option 1: Pressure DCG more: they will quit.
Option 2: Fund DCG more: they will fail.

That's the unfortunate reality of the situation. Either way we are screwed. Just a matter of time before we vote to increase the maximum supply so we can pay ourselves and our cronies even more to indefinitely dump on holders while continuing to deliver a hot mess until quantumexplorer is the only person left on the planet mining dash and paying himself worthless coins. Remember, just because you have a MN doesn't mean you can't short dash on the way down.
Reply
1 point,1 year ago
I second that motion. Yes!
Reply
1 point,1 year ago
With regards to the miners support for the upcoming hard fork (either first hard fork or second hard fork) : what happens if miners do not pass the treshold of support for Dash Core v20 during the specified time period ? According DIP 23 the treshold for activation is between 80% and 60%, which means miners need to show at least 60% support for Dash Core v20 in their mined blocks, at the end of 10 cycles.

https://github.com/dashpay/dips/blob/master/dip-0023.md

''Currently, we utilize a heavily modified version of BIP-9 for hard fork activation in Dash Core. In the previous version of Dash Core, this calculation took into account the percentage of both miners and masternodes that had upgraded. However, since the introduction of the Deterministic Masternode List, the activations have purely been based on miner signalling.''

''The current system declares a start timestamp. The first block of height % 4032 == 0 with a timestamp greater than the start timestamp begins the first signalling cycle. Each signalling cycle has a threshold that must be met in order for the hard fork to lock-in. In our modified BIP-9 style activation, this threshold decreases at an exponential rate (slow at first then accelerating) from 80% down to 60% after 10 cycles have passed. In any cycle, if the final percentage of blocks signalling is greater than the threshold, the activation is locked in. Then after another cycle completes, the hard fork activates.''

What happens if the final percentage of blocks signalling after 10 cycles is less than the threshold of 60% ? Will DCG just proceed with the update and fork off a possible majority of the miners ? Or will DCG consider the update as not passed / failed ?
Reply