Proposal “Evo-Accelerated-Release-Schedule“ (Active)Back

Title:Evo Accelerated Release Schedule
Owner:quantumexplorer
One-time payment: 1 DASH (24 USD)
Completed payments: no payments occurred yet (1 month remaining)
Payment start/end: 2024-06-09 / 2024-07-09 (added on 2024-06-11)
Final voting deadline: in passed
Votes: 460 Yes / 222 No / 21 Abstain
Will be funded: No. This proposal needs additional 106 Yes votes to become funded.
Manually vote on this proposal (DashCore - Tools - Debugconsole):
gobject vote-many 615d8a6d4edafdcee65ff16ab9c7bacef6f5d1b1096466c0957f0441287dcc90 funding yes

Please login or create a new DashCentral account for comfortable one button voting!

Proposal description

Proposal Overview:

Recently, there have been many calls from community members upset that Platform has still not been delivered to Mainnet. While we are doing our best effort to release as soon as possible we also understand the frustration of community members that have been waiting for this for a very very long time.

This proposal is for an accelerated release schedule. I would like to be clear that we have never been in a position to make the proposal I am about to make but we are now. If this proposal were to pass we would cut not only things that were non essential, but also some features that currently exist or are very close to being done but that need more testing. We would also cut down our self review time.

One thing that everyone should understand while reading this proposal is that our code quality is very high, but on 600k to 1 Million lines of code, it is almost impossible for there to be no issues. The more time we spend on trying to find them the more diminishing returns we will get. This means that we will find many issues in the first month, then less issues in the second and so forth. Decreasing the review time will potentially leave more issues to be found while on Mainnet.

One can see such a release as a Mainnet Beta.

By doing this we could release the project in middle July and hopefully see an activation by Masternodes a few weeks later. Before release we would work heavily on chain halt recovery mechanisms to make sure that we can quickly recover from a chain halt.

The benefits of this proposal passing:
  • Platform will be released three weeks after this proposal passes. 
  • We will move more quickly to an iterative release cycle.

The issues with this proposal passing:
  • The likelihood of Platform actually having an issue that would cause the chain to halt is higher, my personal estimate is that this chance of chain halt would increase from about a third chance to two thirds chance within a month of release.
  • Evonode operators would need to be very attentive and upgrade asap as soon as new releases happen.
  • We might see urgent bug fix releases outside of the scheduled release cycle, which would require evonode operators to react in a timely manner, and might be seen as chaotic.
  • We would disable withdrawals from Platform until I personally have reviewed every line of code there (something that I was previously planning to do before release). Enabling them would mean a new release (DCG can not enable or disable, only the network can do that through a version upgrade).
  • We would set fees higher and more conservatively to lower the chance of attacks on the network as we will not actually know what the ideal fees are.
  • The state sync feature is almost done, but almost is not done. In this accelerated release schedule there would be no state sync, new nodes would have to “catch up” which could lead to nodes needing multiple days to sync, even after just a few months, but only in the case of high usage.
  • There would be no fungible token support for MVP, which are needed for stable coin support. This was not something that was in the roadmap for pre-mainnet, but something we were still vying for if we were able to do it.
  • Documentation will not be as complete. 
Things that would stay the same:
  • Because of sum trees, the likelihood of loss of funds in the system itself is extremely low (except for social attacks and scams that obviously can not be prevented at the protocol level).
  • We would still have NFT support.
  • All the advanced features of Platform that we have been talking about for years would still be there (absent the ones mentioned above).
  • We would still have masternode voting and the features needed for Dashpay to work properly.
  • We would still have an iterative approach for data contract release. Dashpay data contract would be set to activate 1 or 2  weeks after Platform activation.
  • The RS-SDK will be released as a beta.
  • The JS-SDK will be usable as an alpha.

After the initial launch our main priority after stabilization would be state sync and withdrawal activation, then additional reviews and fee improvements.

I would like to emphasize that DCG is striving to best serve the wishes of our community. It is far from known to me if the majority want a safe and slower approach or a more aggressive approach that is laid out in this proposal.

As this is not a monetary proposal, DCG will follow the wishes of 2/3rds of the voting network. Because Platform activation would require 2/3rds support from Evonodes, we will also need 2/3rds of voting Evonodes in support as well to see this proposal as passing.

If this proposal does not pass by a long margin we will continue our previous plan and release with withdrawals and state sync completed, and with our self reviews completed.

If we see that the network is more evenly split we will try our best to find a compromise solution that we will present each month. Like this as time goes forward and as more and more features get more stable (withdrawals/state sync/documentation…) we can release once we have buy-in from 2/3rds of the voting network.

If you have any questions, please direct them to quantumexplorer at dashcentral or on discord.

Show full description ...

Discussion: Should we fund this proposal?

Submit comment
 
2 points,4 days ago
It does seem like the proposal might have passed by the slimmest of margins (around 68%). I need to verify these results and then I will be making a blog post tomorrow giving DCG's plan over the next month with a fixed release date.

To those that voted no on this proposal, I would like to say that I hear and share your strong desire to have a clean release and activation that does not result in a chain halt. I will take this into consideration as best I can with the blog post tomorrow.
Reply
-1 point,4 days ago
The proposal didnt pass. 66.42% is the number.

Stop calculating the POSE_BANNED masternodes in the electorate.

Source: https://mnowatch.org/votethenumbers/votethenumbers3/calc3.php?proposals%5B%5D=Evo-Accelerated-Release-Schedule

Report: the_results_dashd_2024-06-21-14-41-47.html.csv
Reply
1 point,4 days ago
I think there is something seriously unclear and in my opinion wrong with the rules set by QE for this DCG decision proposal. Untill yesterday i thought i understood his rules and developed a script that :

* count yes votes of masternodes and compare them to total of voted masternodes (yes+no votes)
* count yes votes of evonodes and compare them to total of voted evonodes (yes+no votes)

However yesterday pmbf posted on Discord a different interpretation of the proposal text

"2/3rds of the voting network": ALL nodes
"2/3rds of voting Evonodes": only Evonodes

*** Which QE gave a point up to ***

This would mean that the yes votes of evonodes are getting counted twice, 1x in all nodes and 1x by only counting yes votes of evonodes. This will completely change the weighing of the yes votes of Evonodes and also gets you a much higher percentage for yes votes for Evonodes from the start.

My script currently is set to fetch the current votes as follows :

Total count of voted Masternodes : 243

- Yes: 159 (simple vote majority : 65.43%)
- No: 84
- Abstain: 13

Total count of voted Evonodes : 91

- Yes: 65 (simple vote majority : 71.42%)
- No: 26
- Abstain: 2

However if QE indeed count the yes votes of Evonodes twice, that would change it to :

ALL voted nodes (Masternodes+Evonodes)

Total count of voted Masternodes + Evonodes : 243 + 91 = 334 total voted nodes
159 yes votes from Masternodes + 260 yes votes of Evonodes (65*4) = 419 yes votes in total
Percentage : 334/419*100 = 79.7%

Only Evonodes : 71.42%
Reply
3 points,4 days ago
The really strange part is that QE never corrected me on the screenshots of the output of my script on Discord, which now seems to have a large discrepancy in percentage, compared to his own calculations. A discrepancy in percentage that could make this proposal either pass or fail.
Reply
2 points,4 days ago
That’s funny that regular MNOs seem to not want to release as much as EvoMNOs.

As I read it, the two ways of counting were as a group (MNO plus EvoMNOs require 2/3 simple majority ) and EvoMNOs needing to achieve 2/3 simple majority. The reason being that QE did not want to strong arm half of the network (the EvoMNOs) into forgoing payments for a possibly substantial amount of time.

We need enough EvoMNOs to upgrade and run despite the fact that they won’t get paid for 6+ weeks to an unknown number of weeks. So we need to see willingness of the EvoMNOs to go for this.
Reply
2 points,4 days ago
'This will completely change the weighing of the yes votes of Evonodes and also gets you a much higher percentage for yes votes for Evonodes from the start.'

Actually after thinking about it a bit, that should just be :

This will completely change the weighing of the yes votes and has an affect on the percentage.
Reply
1 point,4 days ago
So it’s a two tiered vote where these two ways of counting the vote have to pass, not just one or the other.
Reply
1 point,4 days ago
Yep. and currently they do both pass if we take pmbf's interpretation. If that is the correct interpretation.
Reply
1 point,4 days ago
i think you are seriously mistaken.
votes from regular 1K Nodes will most likely not even count for this proposal.
the silence of QE is not exactly helpful either.

this proposal will only consider votes from 4K Evonodes, and it requires 2/3 as in YES/(YES+NO) in order to be approved.
Reply
2 points,4 days ago
From proposal text : 'As this is not a monetary proposal, DCG will follow the wishes of 2/3rds of the voting network. Because Platform activation would require 2/3rds support from Evonodes, we will also need 2/3rds of voting Evonodes in support as well to see this proposal as passing.'

How do you translate that to '1K Nodes most likely not even count' & 'only consider 4K Evonodes' ?
Reply
1 point,4 days ago
Result for total network:
(159 + 4 * 65) / (243 + 4 * 91) = 69%
Reply
2 points,4 days ago
91 is number of voted Evonodes, why are you multiplying that with 4 ?
Reply
1 point,4 days ago
Because we need the count of the votes, and not the number of nodes.
Count of YES votes: 159 + 4 * 65
Count of ALL votes: 243 + 4 * 91
Reply
2 points,4 days ago
We need both the number of votes and the number of voted nodes.
If you do 4*91 you are saying that instead of 91 evonodes casting a vote, now suddenly 364 Evonodes casted a vote. That is simply incorrect. You can't multiply the 91.
Reply
1 point,4 days ago
It seems to me, that you want to compare apples with pears...
Reply
2 points,4 days ago
It seems to me you are confusing the voted nodes (in this case those 91 evonodes) for votes that need to be multiplied.
Reply
-1 point,4 days ago
The most frightening thing in this vote, is that the infamous quantumexplorer once again instead of using inclusive election methods, he uses divise election methods in order to claim that he has the support the network.

Divide and conquer.

Quantumexplorer by continuously using the divisive election method, he drives people away from the community and will eventually end up voting only himself.

More info about the difference of the inclusive and the divisive election methods can be found here:

https://www.dash.org/forum/index.php?threads/pre-proposal-would-you-like-this-proof-of-individuality-to-be-implemented-in-dash.15946/page-6#post-235992
Reply
-3 points,2 days ago
That's what it's like when communities are gentrified. QE, once again, inventing his own rules for what a "decision proposal" looks like. In this particular case he's giving weight to 4K nodes because [insert excuse here].

When he eventually proposes a switch to 10K "HPMN"s, he will likely pull the same shit again and exclude 1K nodes.

On the plus side, the more bullshit he spouts as a dao influencer, the deeper the whole he makes for himself.
Reply
4 points,2 days ago
Both the 1k and 4k nodes clearly voted for this change, stop trying to steer the narrative for your own agenda. The proposal passed.
Reply
0 points,1 day ago
In April 2024 QE said, "If I would guess I would think we would be releasing in June. In about a month from now I will announce the official release date.''

June is here and that announcement is now a proposal to "accelerated release schedule". It's a verifiable fact and not some weird out of context statement. The PO literally said this.

By creating this proposal, the PO is diluting blame to MNOs for the upcoming chain halts, that were never previously declared on a balance of probability.

Indeed, whatever the rules are for this passing, it is the POs rules without reaching consensus as written in the computer code of the dashd daemon. More so, said code is managed by DCG for whom the PO represents.
Reply
1 point,1 day ago
QE has not been steadfast with his estimates and his statements so far. Yes we now have a release date of Platform on Mainnet for 29th of July 2024, but that release date also got extended with 10 days, while this decision proposal very specifically states Platform would be released three weeks after passing of this proposal, not three weeks + 10 days. And i too remember all his previous incorrect estimates (estimate for June, estimate for July, estimate for worst case scenerio August .. which we are now pretty much sliding into).

This all makes me very worried about his statement of enabling withdrawals within 6 weeks after activation of Platform on Mainnet.

Trust has been broken and needs to be rebuild.
First step to rebuilding that trust :

* actually release on 29th of July 2024
* actually enable withdrawals within 6 weeks after activation of Platform on Mainnet
* make Core & Platform release cycles shorter and deliver on what is suppose to be in those releases.
Reply
2 points,1 day ago
* be very very clear on DCG decision proposal rules in the future, the current rules were just too confusing which lead to different interpretations of those rules and the voting that was taking place was difficult to follow for MNO's.
Reply
1 point,1 day ago
You are just purely hate filled now, there is literally NOTHING the core team could do at this stage to make you happy. I'm just going to add you to my ignore list.
Reply
-1 point,4 days ago
Here is an example of what exactly the infamous quantumexplorer is doing in Dash community.

We have 100 people.

He uses the 2/3 divise election method.
33 of them are disatisfied and leave the community .

Then he uses again the 2/3 divise election method.
22 of them are disatisfied and leave the community .

Then he uses again the 2/3 divise election method.
15 of them are disatisfied and leave the community .

So after 3 times the divise election method has been used, how many people remain?

Only 30!!!!

Thats what quantumexplorer is doing to the Dash community, and the stupid masternodes tolerate him.
Reply
-1 point,4 days ago
THIS PROPOSAL FAILED TO GET THE 2/3 OF THE VOTING NETWORK.
It needed 66.66% and it got 66.42%.

https://mnowatch.org/votethenumbers/votethenumbers3/calc3.php?proposals%5B%5D=Evo-Accelerated-Release-Schedule

Electorate = 3434 potential votes (Regular and Evo MNOs)
ValidVotes = 685
Voting participation = 19.94 %

---VOTING RESULTS (depends on which among the below election methods you prefer.)---
( VOTED_NO=0, VOTED_ABSTAIN=1 and VOTED_YES=2)

---Divisive Election Methods---
Most Voted Number = 2 (or 2 base3) was voted by 455 votes ( 66.42 % of the valid votes )

---Inclusive Election Methods---
Median Average = 2 (or 2 base3)
Mean Average = 1.35
Reply
0 points,4 days ago
the above 66.42% result refers to the_results_dashd_2024-06-21-14-41-47.html.csv mnowatch report.
Reply
0 points,4 days ago
And by the way, the proposal reached close to 66.66% of the voting network, due to the unexpectable vote of the long sleeping whale iwashikujira, who didnt vote since 2022, and suddently appeared.

https://mnowatch.org/queries/query3/query3.php?iphash=iwashikujira
Reply
0 points,4 days ago
Some scammers may say otherwise, but these scammers count the POSE_BANNED masternodes when calculating the results.
Reply
0 points,5 days ago
Here's an example. Here in Russia they came up with and showed everyone a military robot, Fedor, with a stick in his ass (you can watch it on YouTube).
Billions of dollars were spent on this, and for this huge amount the robot could at least crawl. With a stick in the ass, but crawling.
The developers spent a fantastic budget, everything is great ;)
So, we ask you, the platform developers, to release it as soon as possible, in June-July, even if the platform is on crutches and with a stick in its ass.
We want to see at least some result.
Reply
2 points,6 days ago
I support this proposal. Working with Platform on mainnet will be more efficient for Incubator devs. Testnet tools (faucets, nodes, explorers, etc) are notoriously buggy and unreliable. Being able to use real, reliable mainnet Dash wallets, explorers, and other tools will improve the pace, excitement, and overall experience of developing.

DCG has historically wiped platform data and started the platform chain from scratch when there are issues. That's what concerns me the most. We can't do this on mainnet. I'm assuming that DCG knows how we can recover from chain halts or other issues without losing any data, otherwise they wouldn't have submitted this proposal.

I feel the benefits of moving to mainnet on this schedule outweigh the risks. The only people I know of that are looking at Dash Platform right now are our own (mostly funded) developers who know of and can work with Platform instability. Regardless, the best way to improve reliability is to move to mainnet.

It's good that DCG submitted this proposal. They're giving us a firm and explicit launch date via an official proposal. I think that's a first; they must feel confident that the worst case scenario is manageable. Let's take the offer!
Reply
3 points,6 days ago
I totally agree!
Reply
6 points,8 days ago
I understand the revenue implications for MN & EvoNodes with this first release but from a Product perspective I very much support this proposal. Being able to show progress like this to potential partners is very valuable and from a technical perspective, the sooner we are running Platform on Mainnet, the sooner we will be able to fine tune anything that was not evident on Testnet, thus making it more stable. I also don't want to discount the psychological/emotional benefits to the developers and the community who have been working/watching for so many years; it can be a REAL positive motivator.
Reply
4 points,6 days ago
That is encouraging to hear, Brian.

Once Evo goes mainnet and the kinks have been worked out (and price improves), you can start building out your product management vision/goals.
Reply
1 point,8 days ago
Strange to see you (someone from DCG) feel a need to emphasize the benefits of showing progress to potential partners, by promoting a product to them that is :

* incomplete (missing enabled withdrawals and statesync)
* likelihood of Platform actually having an issue that would cause the chain to halt is much higher (2/3 instead of 1/3) within a month of release !!
* has severe revenue implications for Evonodes specifically (who will not have access to 75% of their masternode rewards for an uncertain time period). The promise of enabling withdrawals within 6 weeks after activation of Platform contains zero certainty, i could easily see withdrawals enabling getting delayed beyond 6 weeks, specially with a Platform stabilization period in play now.

Most of the above can be avoided by just waiting 1 month, after which QE will make a new decision proposal with enabled withdrawals and maybe state sync as well (although the last one is appearently not that essential during the first phase of release, activation, bugfixing and Platform stabilisation).

Lets all remember how we got to this point, where after all this time Dash Platform is still not quite complete after three long years under new leadership and who exactly are responsible for that. We could not show progress for 3 years to potential partners, one month will not matter.

If this proposal does not pass, don't blame Evonode owners, blame DCG.
Reply
3 points,6 days ago
"...one month will not matter"
It's never just one month.

"I could easily see withdrawals enabling getting delayed beyond 6 weeks"
You always have the option of turning your EvoMN to a regular MN temporarily if you need the rewards to pay for your everyday things. Yes, it wouldn't have as high an APY but this sacrifice may be needed to get Evo done. We should see better incentives and pressures to get things done faster once we're in mainnet.
Reply
0 points,7 days ago
Chain halts are only in danger of happening on the platform chain, not L1. Regular Dash should be fine.
Reply
4 points,7 days ago
I am just gonna repeat myself : a chain halt already occurred on L1, due to a Platform-related update (BLS update). Showing that Core is not that isolated from Platform and could unintentionally get affected by it.
Reply
5 points,7 days ago
Basically both chains can have chain halts.
Reply
3 points,7 days ago
I just hope the mn_rr feature does not cause any issues on L1.
Reply
1 point,6 days ago
I'm wondering which feature are you refering to with mn_rr ?
Reply
1 point,6 days ago
See : https://imgur.com/BEeumsc

It is a feature to be integrated into a new Core update that will handle :

* Masternode Reward Location Reallocation (a large portion of the masternode rewards will be moved to Platform and distributed as credits among Evonodes)
* Enhanced hard fork implementation (this will affect Dash next hard fork)

Maybe during the next two-weekly Sprint review the Core team / Pasta can discuss this specific feature with more details.
Reply
1 point,6 days ago
I am not totally sure if the mr_rr feature by itself will form a hard fork for the network or if it just affect the next hard fork.. it has not really been discussed much.
Reply
4 points,7 days ago
Maybe the BLS update was not specifically Platform-related back then (although it was appearently needed as a stepping stone on a path to reach inter-blockchain communication), but that does not mean in my opinion that Core is completely isolated from Platform and can not be affected by it.
Reply
1 point,7 days ago
Eh, I’ve said this before sorry. I have the memory of a goldfish…
Reply
2 points,8 days ago
Frankly it is a shame we are even in this situation right now.

How was a July release ever even a realistic estimate for Platform release, when withdrawals needed at least 6 weeks of review, could never be publicly tested on Testnet before (as it never was part of the testing phase) and there was also talk about needing 1 month additional time to fully test Platform on Testnet by QE himself (to trie to break it himself).

I have lost all confidence in any estimate from DCG with regards to a timeline when it comes to Platform, including the estimate of withdrawals getting enabled within 6 weeks after activation of Platform.
Reply
-1 point,8 days ago
Let's maybe just not blame anyone, different people have different opinions here, and that's okay. If this proposal does not pass it's really not a big deal, I will make another proposal for the next month, this time with withdrawals from the start, or at least coded in from the start (maybe on a timer to activate 2 weeks after Platform start).

Also while you say: "is still not quite complete after three long years under new leadership". Why don't you ask an AI based on the amount of code we now have and the resources we had if we have done a good job. We didn't have unlimited resources like some bigger projects. I couldn't hire ten 300k/year devs. I hired new faces with the resources we had, and we built a very innovative project, and this only the beginning.

In the end I actually think that you are mistaken when you think we did a bad job. The price is not great I agree, but what has been built is great.
Reply
1 point,2 days ago
fu, u had the budget doubled to pay for more incompetence.

Yeah, let's not just not blame anyone. The price of dash is currently 24.23 USD but that's just one more thing to conveniently ignore. If you'd had concentrated on "digital cash" the price of dash could of been much higher and paid for the devs you claim not to afford. How do I know this? - because this price low can't be any f*ing worse. I'll correct that, I maintain my original prediction of 14 USD. What can you afford to maintain at 14 USD?

You say you have no control of the price yet remain the mouthpiece for DCG, bringing "decision" proposals while inventing your own rules for each. That is not the definition of a dao, it's the output of a company describing their product as a "protocol" when it's not.

Want to prove me wrong? - then show me a fully independent evonode daemon.
Reply
1 point,8 days ago
If a large update in its current state has a rather high increased risk of a Platform chain halt, i would not call that what has been built great. I would call that a large update still needing more test and development time.

Unfortunetely MNO's patience have by now completely ran out (totally understandable). We will see if Evonode owners can stretch their patience with one more month, or if they feel the same as MNO's.
Reply
0 points,8 days ago
While Im as eager as everyone else to finally have platform launch, I personally don't think another 3 months is going to make or break the situation, however I could see some massive bug doing so. I tend to lean conservative on this and will vote no, but am open to some compromise solution.
Reply
3 points,10 days ago
Regardless of the outcome of this proposal I will promote whatever release we have.

That being said, I'm in favor of releasing as soon as possible. I believe that every day that passes without a release of some kind affects our reputation and price in a negative way.
Reply
-1 point,9 days ago
The press reported the last chain halt. Seems dash has gone from laughing at Solana to joining them.
Reply
7 points,10 days ago
Just so everyone knows, the impact of this proposal is that rewards paid out to both regular MNs and eMNs will change, approx 21% for eMNs and 6.5% for regular MNs. Currently, both cohorts are earning 8.5%. More details here https://mnowatch.org/evonodes/

Something else to note is that for eMNs they will be paid once per cycle on the L1 chain, however, 3/4 of their payment will be held on Platform with no ability to withdraw for the first month or so, until that code is activated in a future release.

Also, I spoke with QE and to clarify the voting, it needs a 2/3 majority calculated as (YES/(YES+NO)), key things to note is a vote to ABSTAIN is same as no vote at all. A NO vote does not negate a YES vote. The proposal does not have to reach 'funding' in order to pass. However, I am not clear if both regular MN and eMN need to hit 2/3, or if it is just the eMN votes that count, anyway, check out qwizzie's forum post with a nice script to create the tallies on the fly.

Another thing, in case this proposal fails, it does not mean Evo will be delayed for months on end, either way, we release in July or August, what changes is just how functional the expedited release is and how great the chance is it has a bug that causes the chain to stall.

Also, note that as yet DCG have not tested network upgrades on testnet yet, to date, they always wiped and started over, this remains to be done and we don't know for sure that the network will be able to smoothly upgrade once activated, it might be worth testing that before release.
Reply
2 points,9 days ago
Just a note, the only chain that has risk of halting is the platform chain, core is solid.
Reply
2 points,9 days ago
Normally i agree, but there was a Platform-related Core update that actually caused a chain halt on Core. After witnessing that i feel less confident about Core not in any way getting affected by any future Platform update.
Reply
1 point,10 days ago
Guys, correct me if i´m wrong, but to me it clearly seems like regular 1K Nodes need not even voting on this Evo Launch proposal, as they have no say in this matter.

Only votes of 4K Evonodes will be considered and it can only be approved by a majority of 2/3 of voting 4K Evonodes, regardless whether it reaches the funding threshold or not. For sure the strangest of all proposals so far.
Reply
0 points,10 days ago
I was under the impression both 1k Nodes and 4K Evonodes each require 2/3 support.

If 1K Evonodes do not reach 2/3 support : proposal does not pass
If 4K Evonodes do not reach 2/3 support : proposal does not pass
Reply
1 point,10 days ago
correction : 1k Masternodes, not 1K Evonodes.
Reply
6 points,11 days ago
Evo has been a major monkey our back since it was announced. Even if it's not feature complete, getting it out the door will finally remove that monkey. Perfection is the enemy of progress. Big yes from me.
Reply
0 points,11 days ago
Lemur.
Reply
-1 point,9 days ago
Lemmings?
Reply
3 points,12 days ago
What role will the Dash community play in the 'beta' phase on mainnet, and how can users contribute to the platform's development and refinement?
Reply
2 points,10 days ago
The main way we can contribute is by testing on testnet and reporting any issues we find, probably the easiest way to do this is use the dapps on https://dashmoney.io/ You should also see your activity recorded on https://platform-explorer.com/
Reply
4 points,13 days ago
Quoting from proposal text :

'As this is not a monetary proposal, DCG will follow the wishes of 2/3rds of the voting network. Because Platform activation would require 2/3rds support from Evonodes, we will also need 2/3rds of voting Evonodes in support as well to see this proposal as passing.'

Looks like we can check for ourself how Masternodes and Evonodes are currently voting and how close to 2/3 support each one is, through the Dash Core wallet - Console.

gobject list : you get a list of all active proposals with their hash
gobject getcurrentvotes hash : you get all the current votes of a specific proposal, if it end with 1 it is the vote of a Masternode, if it end with 4 it is the vote of an Evonode.

To get the current votes of this specific proposal :

gobject getcurrentvotes 615d8a6d4edafdcee65ff16ab9c7bacef6f5d1b1096466c0957f0441287dcc90

Currently 21 Evonodes voted so far with 4 votes. With 13 yes votes and 8 no votes.
(Evonodes are a smaller group, more easy to count votes)

It only becomes clear if there is also 2/3 support among Evonodes for this proposal, once the voting deadline has passed (9 days from now). Most of the voting happens in the last few days of the voting deadline.
Reply
3 points,12 days ago
I made a little Ubuntu shell script with help of ChatGPT, to fetch the current votes of both Masternodes and Evonodes on this proposal more easily. It can also be used for other proposals, if people are curious how Evonode owners / operators in general are voting.

See : https://www.dash.org/forum/index.php?threads/shell-script-to-fetch-masternodes-and-evonodes-current-voting-on-a-certain-proposal-through-dashmate.54991/
Reply
3 points,10 days ago
I adjusted above script to comply with simple majority for this very specific DCG decision proposal, you can find it here :

https://www.dash.org/forum/index.php?threads/shell-script-to-fetch-masternodes-and-evonodes-current-voting-on-a-certain-proposal.54991/#post-238678

The script on post 1 can be used for normal budget proposals with super majority (yes-no)
Reply
-6 points,12 days ago
More scammy shit, pushing responsibility onto non-technical / programmer MNOs. You can not be an influencer / position of authority _and_ avoid responsibility.

There are NO governance proposals, none of the dash software recognizes such thing. All proposal payments _require_ a minimum monetary dash output greater than zero.

The rules for proposal payments and the rules YOU manufacture for changes, are not the same or coherent.

I promise you, the day you face a jury is the day I will personally be present in the public gallery, anywhere on earth.

If you believe your previous vote buying has gone unnoticed / forgotten, you are sadly wrong.

Gullible MNOs will vote NO or YES, but the smart ones will either ABSTAIN, DELETE, or simply ignore this proposal entirely.
Reply
3 points,14 days ago
Easy NO from me.
Not willing to renounce to 75% of the Rewards of my Evonode for an extended period of time.
We don´t even know, what will happen to the 37.5% of Block Rewards reserved for Evonodes, while nothing will be paid out.
Voting NO was never easier.
Reply
2 points,14 days ago
The problem with the extended period of time, before withdrawals are getting enabled, is that it could be within 6 weeks (as QE mentioned) or it could be a lot longer then 6 weeks. With QE track record with regards to estimates combined with the Platform stabilization period (who knows how long that will take), i am thinking a whole lot longer.
Reply
2 points,14 days ago
QE should elaborate, if this were to pass, whether an Evonode will still receive 75% Rewards from the Evo-Pool and only withdrawals being impossible/delayed, or if an Evonode will only earn the 25% Core Reward during such an extended period of time.
Because if its the latter, question remains what happens to all the funds (37.5% of Block Rewards) in the Evo-Pool.
If the Evo-Pool itself wouldn't be enabled, it would still suck BIG TIME as it would mean Evonodes would basically earn the same amount like regular Nodes only from Core.
Reply
0 points,14 days ago
Once Platform activates on Mainnet the new masternode payment schedule comes into effect. An Evonode will get paid 25% Core reward (just 1 masternode reward instead of 4 masternode rewards) and will accrue 75% of his rewards on Platform itself through Credits (as long as that Evonode is functioning well and there is no Platform chain halt).

The Credits can only be withdrawn for dash, once withdrawals are enabled. QE mentioned this would happen within 6 weeks after activation of Platform. I suspect it will be longer.

Better to have Platform activation with withdrawals enabled (the next decision proposal next month), then having to wait for withdrawals to get enabled after activation of Platform on Mainnet.
Reply
0 points,13 days ago
The reason its better to have Platform activation with withdrawals enabled, is that this does not cause a disruption in the payout of the blockrewards for Evonode owners / operators.
Reply
4 points,14 days ago
Voting Yes

1) If we take the "a safe and slower approach" for another 3-4 months it may not matter if the difficult market conditions for Dash continues. Getting some good news *could* do wonders.

2) Platform devs can start fixing issues right away and take a more iterative real-world approach to making our tech better. Right now it's all theoretical.

3) If you leave it up to the slow approach, we may not get Evo by the end of the year and you know that doesn't sound crazy to say after all these years.

It's the opposite of what a lot of large holders would think IMO. You're actually protecting your investment with the accelerated approach rather than risking it to more delays. Almost every project runs into issues soon after launch but at least we're actually delivering something.
Reply
1 point,14 days ago
'If you leave it up to the slow approach, we may not get Evo by the end of the year and you know that doesn't sound crazy to say after all these years.'

QE mentioned if this decision proposal does not pass he could introduce a new decision proposal next month, which would include enabled withdrawal.

Quoting QUE:
'If this proposal fails, I will make sure to make another proposal for activation one month later, in that one withdrawals will already have been reviewed. This is an accelerated release schedule, so I needed to cut everything I wasn't sure of.'

Something to keep in mind.
Reply
1 point,14 days ago
Let's please not provide more situations/reasons that could extend out extra months. It's hardly ever just a short time.
Reply
0 points,14 days ago
QE added that he meant another proposal for release one month later (not activation)
Reply
3 points,14 days ago
If QE even makes this an option, I feel comfortable taking the risks. We only have one Evo node, but I will make sure that I am here to update and keep an eye on everything, 16 or more hours a day. I will still sleep, LOL. This means we might miss payouts, it's risky but we need to take more risks again as long as L1 is safe.

Now let me be clear, I'm living off my payouts. I have a roof over my head, but I have to pay for the server and my food with Dash. I'll go on an extended fast if I have to. This is going to hurt me when it goes down, but I'm all for it. Lets get this show on the road like we're all 21 years old again!!!
Reply
0 points,14 days ago
Or you could just downvote this one and wait a month for QE next decision proposal (one that includes withdrawals).
Reply
1 point,14 days ago
we've done enough waiting :(
Reply
0 points,14 days ago
maybe even state sync...
Reply
3 points,14 days ago
They'll come in time anyways, I'm for the kamikaze option. We've lost our edge, we need to get our blood moving.
Reply
3 points,14 days ago
So L1 payouts would still work, what percentage of an Evo MN would be paid out in actual Dash if any? I use mine to pay for my server. Thanks. I’m leaning toward being less afraid, especially since L1 will stay solid and as long as everyone knows L2 is in beta.
Reply
4 points,14 days ago
What percentage of an Evo MN would be paid out in actual Dash if any -> around 25% of what you are currently receiving will continue through Core.
Reply
2 points,14 days ago
Would you mind explaining to a n00b what MN voting has to do with Platform?
I was thinking the MN voting relies on the L1 Core chain, i am confused.
Reply
1 point,13 days ago
Honestly it should just be called 'Platform voting' as it relates to voting on topics that take place on the Platform chain and which Evonodes vote on through Dash mobile wallets (most likely through some other ways as well, DMT for example). Topics like who gets what username.
Reply
1 point,13 days ago
Or voting on a new Platform version by Evonodes.
Reply
3 points,14 days ago
IMHO this is a very good thing.
You’ll see the issues much earlier on Mainnet, than on Testnet.
Just keep up your good communication.
Voting yes.
Reply
-1 point,13 days ago
Anyone who wants to bet with me that the Dash Platform , when released, it will be proved to be a completely useless thing and a resounding failure?
Reply
-3 points,13 days ago
Ridiculous. This is an attempted cop out from DCG so that when they release their obviously BROKEN and INCOMPLETE product, they can blame it on MNOs and say "But you wanted us to do this even knowing the risks!"

There is no winning here. It will be an absolute disaster if we release early, and it's already an absolute mess if we don't release ever. DCG has bitten off more than they can chew, and have been consistently unable to deliver and unable to properly scope the project.
Reply
0 points,11 days ago
Totally, it's embarrassing.
Reply
2 points,12 days ago
You are a bad Unicorn! You complain for years that Evolution is vapourware and will never see the light of day, you only say horrible things and now that they are ready to release, you claim the product will be broken and incomplete! You just don't want to see the release happen at all, you want to be miserable, you want to be proven right, but you are wrong Platform is ready and the devs did a thing.
Reply
1 point,11 days ago
Yes, obviously the product will be broken and incomplete. That doesn't mean I don't support this proposal. I want to see it released so that we can all see the results.
Reply
2 points,13 days ago
The reason for this proposal is not to cop out. It's to respect the wishes of the network. Many big MNOs have told me prior to me making this proposal that they wanted something out asap, even if we had to cut semi-essential features.

I can say right now that there is a high chance that we will have a chain stall. People should expect it if this proposal passes. But a chain stall is not the end of the world. Most blockchains had them when they started, it's hard to name one that didn't.
Reply
1 point,11 days ago
In 2022 you said, "I personally think it is vital that we release something ASAP on which we can improve iteratively".

In April 2024 you said, "If I would guess I would think we would be releasing in June. In about a month from now I will announce the official release date.''

Your "announcement" is now a proposal to deliver with a greater chance than not of a chain halt on Platform, plus your other stated shortcomings. Not least that you previously challenged me over high fees, and now fully justifying higher fees due to security concerns.

You put this proposal to an audience of MNOs that may not be technically competent to understand it, including multiparty masternodes such as Crowdnode.
Reply
2 points,12 days ago
A chance for a Platform (L2) chain stall, not for Core/L1. Didn't want any confusion.
Reply
-1 point,11 days ago
Litecoin
Reply
1 point,14 days ago
Enabling withdrawals would take a new release. Are you talking about a new Dash Core release or a new Platform release ?
Reply
3 points,14 days ago
Platform release.
Reply
2 points,14 days ago
Also how much time would be involved with you personally checking every code line of the withdrawals feature ? How long would we have to wait on having feature withdrawals enabled ? Weeks ? Months ?
Reply
1 point,14 days ago
1 : Platform network stabilisation (possibly with new Platform versions / hotfixes)
2 : Enabling Withdrawals (new Platform version)
3 : Introducing Statesync (new Platform version or maybe released together with Withdrawals)

I am a little worried that step 1 and 2 could take quite a lot of time, financially impacting Evonode owners / operators who rely on those rewards.
Reply
1 point,14 days ago
Just to be clear, not having enabled withdrawals from the start means that Evonode owners / operators will only receive a small portion of its rewards from L1 and they will see a buildup of rewards from L2 (Credits), but with no way to convert those to dash. Not untill withdrawals get enabled.
Reply
3 points,14 days ago
If this proposal fails, I will make sure to make another proposal for activation one month later, in that one withdrawals will already have been reviewed. This is an accelerated release schedule, so I needed to cut everything I wasn't sure of.
Reply
3 points,14 days ago
Sorry I meant for release, not activation
Reply
0 points,14 days ago
I just learned on Discord that enabling withdrawals would be done within 6 weeks after release.

Quoting QE : 'If we released without withdrawals, we would have them within 6 weeks after activation, as having them would be probably the top priority along state sync support. (Once again the feature is written, just needs a crazy thorough audit from me).'

Which to me translates to 6 weeks (or longer) of not being able to convert credits to dash. This will severly impact Evonode owners / operators that financially depend on those masternode rewards, as they will effectively only have access to a small portion of their masternodes (from L1, not L2) until feature Withdrawals get enabled.

I rather support a decision proposal that contains withdrawals enabled, so it won't mess up my masternode operations financially and leave me financially in a dire spot. So unfortunetely i think this will force me to vote no.

If another decision proposal emerge next month that does have the feature Withdrawals enabled, i will reconsider it. Depends by then on how much it will accelerate things for DCG.
Reply
0 points,14 days ago
Few corrections on my above comment :

* within 6 weeks after release, should be within 6 weeks after activation
* access to a small portion of their masternodes (from L1, not L2), should be access to a small portion of their masternode rewards (from L1, not L2)
Reply
1 point,14 days ago
'Because Platform activation would require 2/3rds support from Evonodes, we will also need 2/3rds of voting Evonodes in support as well to see this proposal as passing.'

How do you differentiate between normal masternodes that voted and evonodes that voted, to determine that those evonodes that voted reached 2/3 ?
Reply
2 points,14 days ago
We can see who voted from the voting log, or use mnowatch.com
Reply
2 points,14 days ago
mnowatch.org
Reply
1 point,14 days ago
According xkcc mnowatch does not track voting behavior of Evonodes that consistently. So how can MNO's reliably track Evonodes voting ? Is there an rpc command we can use or are we just relying on DCG for this ?
Reply
0 points,14 days ago
Rustify dem tings !
Reply