Proposal “DCG-SUPPLEMENTAL-FEB24“ (Completed)Back

Title:Dash Core Group February Supplemental Funding Proposal
Owner:quantumexplorer
One-time payment: 612 DASH (15821 USD)
Completed payments: 1 totaling in 612 DASH (0 month remaining)
Payment start/end: 2024-02-09 / 2024-03-10 (added on 2024-02-13)
Votes: 450 Yes / 16 No / 0 Abstain

Proposal description

What does this specific proposal fund?

DCG reserves are slowly getting better but are still very low, this proposal aims to speed up recovery of a small buffer, so DCG can be in a more healthy position sooner.

How are things?

January was a very productive month, and things are looking up. On the platform side we just merged in some long time Pull Requests that had been haunting the team for a while ; Withdrawals are now merged in, and so are the chain lock verification PR and the Dash SDK one. These recent successes have revitalized the mood and energy of the team after the year end holidays.

What is left to do for Evolution/Dash Platform to be released?

We have work pretty much divided into many categories of work. Please understand the time required here are estimates. The work added here is also what we currently know of, and as testing is a dynamic process things might be added to this list as they are discovered. Also please note that some tasks can only be done by certain individuals on the team. Some team members are assigned to lower priority tasks because they are best suited to take on such tasks since putting them on the more complicated tasks would not give good results.

Consensus issues discovered:
Making sure that replaying state transitions can not take down the network (2 people for 4 days left of work - most work here already completed) Done
Implement multithread drive query solution (discovered during stress tests) (3 people for 2 weeks left of work)
Ask for all core information once for all state transitions in a block (discovered during stress tests) (2 people 3 days)
Bug in data contract queries (1 person 1 day) Done

Features left:
Masternode Voting (2 people for 7 days left of work - currently postponed till after issues are finished)

Fine tuning
Making sure that fees are set to values that represent costs to actual Evonode operators (3 weeks 2 people)
Internal code review (All the team 2 weeks)

Client side
Making sure that clients have properly integrated the Dash SDK (4 man/weeks left of work - mostly taken on by mobile team)

Testing
Additional stress tests (2 people 1 week)
Additional mechanisms for better testing (1 person 3 weeks)
Final testing of protocol upgrades (2 people 3 days)
Chain halt mitigation process (2 people 3 days)

Might be needed
State Sync (2 people 3 weeks) - We hope to be able to release without this.
Query fees (2 people 2 weeks) - We currently do not charge state transitions for lookup queries, since this is vastly inferior to other state transition costs we believe we can release without this feature.
Dapi rewritten in Rust (2 people 3 weeks) - Dapi is currently written in Javascript, it's only 14k lines of code (which is mostly boilerplate). Since it was never an expensive part of the system this was kept in Javascript, however it might prove too unreliable. Currently though we see it working well enough for release.

Did DCG start hiring again?

As previously mentioned in a past proposal we were looking for a new infrastructure engineer. I am pleased to note that we made that hire and are very excited to see what they can achieve.

We sadly had a departure in the GroveDB team and are looking to backfill that position. Right now that is the only hire we are looking to do, at least for the next 2 or so months.

How much of an impact do the supplemental proposals have?

A big impact. The supplemental proposals will aid our recovery and put us in a better position for growth sooner.

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

Requested funding is as follows for the February 25th superblock:
  • 611 Dash ($16,802.5 USD @ $27.5 per Dash)
  •     1 Dash Proposal fee reimbursement
Total: 612 Dash

Show full description ...

Discussion: Should we fund this proposal?

Submit comment
 
1 point,1 month ago
Where are the links of the written code that QE claims that he assigned to the developers?

In the meanwhile have a look at the github feed:

https://github.com/dashpay/platform/issues

Too many bugs!!! But if you look to Assignee, nobody is assigned to solve them!

Wasting money through obscurity. A well known recipe.....
Reply
2 points,1 month ago
You can see resolved Pull Requests here: https://github.com/dashpay/platform/pulls?q=is%3Apr+is%3Aclosed

All code we write is open source and published to Github. The fact that we haven't gone through community issues yet is just a matter of priority. Eventually once we have something relatively stable we will definitely make sure all issues are closed.
Reply
0 points,1 month ago
>The fact that we haven't gone through community issues yet is just a matter of priority.

Exactly. Community is not your priority. Your priority is to receive money from the community in order to implement whatever stupidity comes into your mind.
Reply
2 points,1 month ago
Why don't you list the issues that you think we should stop other work and switch focus to deal with?
Reply
2 points,1 month ago
It would be nice if someone took a look at my reported Github issue about a possible memory leak of v20.0.4 --> https://github.com/dashpay/dash/issues/5872
Reply
2 points,1 month ago
Thanks @qwizzie, I'll ask the core team to look into it.
Reply
1 point,1 month ago
Thank you.
Reply
1 point,1 month ago
I bet it would take a dev only a few minutes to determine if this is normal Ubuntu behavior or a possible memory leak from either dashd or from docker.
Reply
1 point,1 month ago
Note : i saw this memory usage increase before on a VPS where i used to ran a high number of masternodes. It would slowly start increasing memory usage, then at some point would start eating into my swap space and then start giving all kinds of problems to my masternodes. At which point i would normally just reboot the server and the whole process would start again.

For awhile i thought that Docker / Dashmate was handling this much better (after all it only need to handle the memory of 1 instance), but now i am seeing the same kind problematic behavior (though it has not yet reached my swap) and i am just not sure if this is normal Ubuntu behavior or a possible memory leak.
Reply
1 point,1 month ago
Currently Evonodes just have access to L1 and are therefore operating pretty much as a normal masternode. Once Platform features get activated Evonodes will get accesss to both L1 & L2 and memory usage will increase dramatically (3x or 4x ?).

I want to make sure there is no memory leak that could impact Evonodes that will already have a pretty high memory usage at that point.
Reply
0 points,1 month ago
Have you tried the DMZ? It optimises all this out.
Reply
-1 point,1 month ago
Because you are the one who is being paid, thus it is your job to do this.

It is not not mine.

https://forum.polkadot.network/t/slider-voting-system/6029
Reply
2 points,1 month ago
I have done this work, and I am working on the stuff that I think is the most important. You should either be competent enough to figure out what issues you want us to change our focus to, or basically let us do our job.
Reply
0 points,1 month ago
If you have done this job as you claim, then why there is not a single label in the pull requests of the platform?

Why dont you label the pull requests depending on their type (bug, feature etc) and their severity (critical, minor etc) etc etc

Wasting money through obscure pull requests. A well known recipe of the developers who want to waste money.....
Reply
0 points,1 month ago
And why dont you assign the pull requests and bugs to specific persons?

Look at the "Assignee" tab, nobody has been assigned to do something.

Finally, why dont you reveal the reward to whoever finished whatever pull request?

Thats your job, to provide transparent expenses, but you do nothing towards transparency.
Reply
0 points,1 month ago
And why there is not a single label in the pull requests of the platform?

Which among all these pull requests are really needed? Why dont you label them depending on their type (bug, feature etc) and their severity (critical, minor etc)

Wasting money through obscure pull requests. A well known recipe of the developers.....
Reply
1 point,1 month ago
My point is, not only QE should publicly assign to specific developers the solution of the numerous bugs of the platform, but also he should reveal how much he is paying them for solving these bugs.

As long as he refuses this transparency, his role against Dash becomes more and more suspicious.
Reply
0 points,1 month ago
But the real suspicious is not QE himself.

There real suspicious whose role should be investigated is the masternodes that are supporing the platform stupidity.

https://mnowatch.org/the_results_dashd_2024-02-18-06-02-49.uniqueHashVotes.165.html?3=DCG
Reply
0 points,1 month ago
These masternodes have names.

spirit, combine, ayver, DIFSHelpMall
Reply
0 points,1 month ago
The only hope for Dash community is to succeed in expelling the DCG.
If the Dash community succeeds to defund DCG, the DCG will sell the masternodes they use to control the community, and that way new wise people and proposals will appear that will make DAsh rise again.
Reply
4 points,1 month ago
Demo, do you not remember Ryan Taylor having to step down because with him at the helm MNs wouldn't fund the DCG request? If DCG controlled the votes as you are saying why did that ever happen? Why did several ideas over the years that were brought to the network by DCG fail to get enough support?

You are smarter than that accusation.
Reply
0 points,1 month ago
Your argument has a strong point.

In that case I rearrange my previous argument, and I say that some agent driven Masternodes DESIRE A BAD DCG TO RULE Dash, whether this DCG is the one Ryan Talor used to have or the current one.

These agent driven Masternodes who desire the destruction of Dash by hiring an incompetent DCG have a name: spirit, combine, ayver, DIFSHelpMall e.t.c.

For more info, search here:

https://mnowatch.org/latestlink_DashdUniqueHashVotes.html?3=DCG
Reply
1 point,1 month ago
No matter how much money they give you, it will never be enough for you. You will demand more and more...
Reply
1 point,1 month ago
The problem is not they money he gets. The problem is he does nothing with that money.
Reply
2 points,1 month ago
Voting YES, core devs and mobile are killing it.
Reply
2 points,1 month ago
What exactly are they doing? Where is their github feed?
Reply
2 points,2 months ago
Now that withdrawals (convert Credits to dash) have been finalized and merged, what exactly still needs to be done before Platform is considered feature complete ? I assume masternode voting is one of those features that are still not complete, what else ? Is rapid testing that Paul is working on another feature that is necessary to finish the testing phase ?

Can devs at this point confirm that Platform testing did not produce breaking changes that require a protocol change from Core (v21) and if that is the case can devs finally tie the activation of Platform features (mn_rr fork) that are laying dormant in v20 to a specific minor Core update ? If not v20.1 then devs should at least be able to tie it to v20.2 ? If not, why not ?

In latest Platform and Core Dev Update, Ivan Shumkov mentioned that withdrawals (from Platform chain L2 to Payment chain L1) are currently limited to just 16 transactions in a Payment chain block (L1). Sam later mentioned that technically the max would be 16x16 = 256 transactions.The whole thing became a bit confusing to watch, as transactions limit in a block from L1 was initially confused by Sam with a dash amount limit per day from Platform (2.500 dash per day?).

See : https://www.youtube.com/watch?v=OVCQbMLvzxk&list=PLiFMZOlhgsYKwnv-81_fWLC0DSbDQ1fyc&index=1 (timestamp 22:36)

So what is it exactly ? 16 transactions in a L1 block or 16x16 (256) transactions in a L1 block ? What will be technically possible when Platform features get activated on Mainnet ?

And why is there appearently also a limit in place the first few months, with how much dash can be withdrawn from Platform (2.500 dash per day ?). To me does sounds and feels a lot like capital control measurements put into place with regards to how much can be withdrawn from Platform.

I really hope that 2.500 dash per day will indeed be lifted after a few months. I even wonder if such limitation should be in there in the first place.
Reply
3 points,2 months ago
Hello Qwizzie, I will be adding to the description a list of tasks I think are needed to finish up Platform.

For Withdrawals, we have 16 outputs per transaction (so 16 people can withdraw from one transaction), and 16 transactions per Platform block. Not Core block! Platform blocks happen around every 5 seconds, so this is about 256 withdrawals every 5 seconds. This is only the current limitation in our first version and we will increase this if it is needed. The limitation is there only because the operations are costly and having them be unbounded might introduce a ddos attack vector. I say might because we did not test this, we are instead trying to make these tradeoffs to get this out faster.

As for the withdrawal limit, this is only a temporary safeguard, we are not doing this for capital control but instead just as a precaution as a lot of code will make it to Mainnet at once. I believe this safeguard is better than if we had to revert the chain like Ethereum did, we will get rid of the safeguard asap.
Reply
2 points,2 months ago
Thank you for the speedy reply.
Reply
1 point,2 months ago
WEN EVO?

IF NO EVO, WHAT ACCOUNTABILITY?
Reply
1 point,2 months ago
WEN EVO?
Reply