Proposal “Expedite-60-20-20-reallocation“ (Closed)Back
| Title: | Expedite-60-20-20-reallocation |
| Owner: | lysergic |
| One-time payment: | 1 DASH (38 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
Cons
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.
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
|
No comments so far?
Be the first to start the discussion! |
Here is the PR that implements this change.
https://github.com/dashpay/dash/pull/5639
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?
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 ?
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.
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 ?
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.
1. Starting Platform.
2. Moving 37.5% of the MN reward into the Asset Locked Pool.
3. The enabling the 60-20-20 reallocation.
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.
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.
Obviously we are looking closely at this proposal and will adjust accordingly.
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.
''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.''
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.
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.
Your words, not mine.
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).
You better confess what you did to Flare to make him leave!
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.
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 ?