• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Dash Core Group Q1 Quarterly Call - 22.04.2021

Also from a masternode owner perspective.. 0.16 is running since 1.5 years on my servers.. Even when i look at the list of released features on mainnet going back to 0.14 (which is almost 3 years ago). In my opinion i see just a list of bug fixes, no great invention.

But to be fair and honest.. i didnt spend to much time on researching. Its only about how often i have to update stuff on my servers (compared to other cryptos im owning).
Perhaps you've mistaken Dash for one of the other projects? Dash Core 0.16 has only been out ~7 months and 0.14 was released less than 2 years ago (May 2019).

As far as features go, 0.14 introduced LLMQs which made ChainLocks possible. It also enabled a massive change in InstantSend that resulted in all transactions on the network being InstantSend locked (and instantly, securely respendable). Once those features were proven out, 0.15 did a lot of refactoring to remove legacy InstantSend logic to avoid cluttering the codebase while also doing a substantial number of Bitcoin backports (as basically all Dash releases do). Most recently, 0.16 included the block reward allocation, expanded PoSe rules, improved the GUI, and optimized network communication. Scattered throughout these releases were numerous PrivateSend improvements, etc. also.
 
Here are the answers to the remaining questions from the quarterly call:

Question: Is there any formal description of what is considered to be the MVP version for Dash Platform and how far away are we from realizing this MVP version? In other words, what are the main development tasks/issues that still need to be completed/resolved before we have an MVP? (Nthelight)
Answer [Bob Carroll]: The main development efforts remaining for the MVP of Dash Platform can be seen on the Dash Roadmap at www.dash.org/roadmap. Developer documentation can be found at https://dashplatform.readme.io/.


Question: Why is Evo and DashPay wallet not on public testnet yet? (DashFTW)
Answer [Bob Carroll]: The Evolution vision emerged on public testnet with the release of Dash Platform v0.17 in late December and the release of DashPay Wallet for Android in January. These will be going through incremental releases regularly until mainnet delivery. The first testnet release of DashPay Wallet for iOS is expected along with the Dash Platform version 0.17 release in early May.


Question: Regarding the MN count, does the recent drop even with the reward increase cause you any pause for maybe changing allocation more aggressively or dropping the 1000 Dash requirement (to 900 Dash). Or more simply is there a MN count that you think we should stay above? (TL)
Answer [Ryan Taylor]: The majority of the MN liquidations were correlated with the recent price increases. Given the price tripled in the 1st quarter, it’s far too early to draw any conclusions about the effectiveness of the reallocation schedule. It may be that the relatively lower MN counts and relatively higher rewards we now see might act as a coiled spring that will take Dash higher. This could also dampen price declines if the overall crypto market moves lower. We plan to evaluate the effect over a longer period and preferably one that is more stable before we can draw conclusions.


Question: CheapAir was one of the key critical Dash services, yet no longer accepts Dash. What is DCG BizDev doing to address this? (TheDesertLynx)
Answer [Ernesto Contreras]: The service provider they used (GoCoin) shut down, we will reach out to try to get them to use one that supports Dash.

Question: If you re-propose the Variable Miner Allocation Plan for Proposal Funding ('DCG Plan') to the network as a standalone decision proposal (e.g. not including expanded spending cap) and it doesn't pass, what will be your Plan B? Depending on feedback received, will you consider a "stronger" version of the Variable Miner Allocation plan (e.g. 80% MN/20% Miners) for proposal funding? (hilawe)
Answer [Ryan Taylor]: There are a number of other governance-related topics that might make strong candidates for proposed improvements. As voting participation has dropped and shared funds and exchange-operated MNs continue launching on the network without any desire to participate in voting, we certainly don’t want that to become a threat to the functioning of the governance system. There also appears to be great interest in potential changes to the proposal fee. We will assess our options based on feedback from the community and our developers.


Question: Is it possible for DCG to come up with a contingency plan in case a majority of the trust protectors go rogue, and against the wishes of the DAO, attempts to dissolve DCG or otherwise interfere with DCG's leadership? Could DCG fight such a maneuver legally and continue operating? (geert)
Answer [Ryan Taylor]: Trust protectors don’t actually have direct control over DCG. Instead, their power resides in the ability to assign the trustee. The trustee is responsible for ensuring all actions are in the best interest of the beneficiaries - specifically the masternodes - before carrying out any of the proposed actions of the trust protectors. The trustee is a licensed professional similar to a lawyer, so it is unlikely this person would act in a way that violates the intent of the trust. So it would take both rogue trust protectors and a rogue trustee. Even then, the DCG board, DCG officers, or any of the beneficiaries (e.g., any of the masternode owners) could take legal action against a trustee that was not operating in their best interest through the court system. In short, there are many layers of protection in place within a trust structure to prevent beneficiaries from potential harm, which is one of the reasons we selected this structure.


Question: Has DCG been in contact with Coinify since they delisted Dash, can we expect a relisting? (Sidem)
Answer: Yes, we are working to get back into their platform. As mentioned during the call, there are confidential parts of the compliance projects that cannot be shared in public.
 
Here are the answers to the remaining questions from the quarterly call:

Question: Is there any formal description of what is considered to be the MVP version for Dash Platform and how far away are we from realizing this MVP version? In other words, what are the main development tasks/issues that still need to be completed/resolved before we have an MVP? (Nthelight)
Answer [Bob Carroll]: The main development efforts remaining for the MVP of Dash Platform can be seen on the Dash Roadmap at www.dash.org/roadmap. Developer documentation can be found at https://dashplatform.readme.io/.


Question: Why is Evo and DashPay wallet not on public testnet yet? (DashFTW)
Answer [Bob Carroll]: The Evolution vision emerged on public testnet with the release of Dash Platform v0.17 in late December and the release of DashPay Wallet for Android in January. These will be going through incremental releases regularly until mainnet delivery. The first testnet release of DashPay Wallet for iOS is expected along with the Dash Platform version 0.17 release in early May.


Question: Regarding the MN count, does the recent drop even with the reward increase cause you any pause for maybe changing allocation more aggressively or dropping the 1000 Dash requirement (to 900 Dash). Or more simply is there a MN count that you think we should stay above? (TL)
Answer [Ryan Taylor]: The majority of the MN liquidations were correlated with the recent price increases. Given the price tripled in the 1st quarter, it’s far too early to draw any conclusions about the effectiveness of the reallocation schedule. It may be that the relatively lower MN counts and relatively higher rewards we now see might act as a coiled spring that will take Dash higher. This could also dampen price declines if the overall crypto market moves lower. We plan to evaluate the effect over a longer period and preferably one that is more stable before we can draw conclusions.


Question: CheapAir was one of the key critical Dash services, yet no longer accepts Dash. What is DCG BizDev doing to address this? (TheDesertLynx)
Answer [Ernesto Contreras]: The service provider they used (GoCoin) shut down, we will reach out to try to get them to use one that supports Dash.

Question: If you re-propose the Variable Miner Allocation Plan for Proposal Funding ('DCG Plan') to the network as a standalone decision proposal (e.g. not including expanded spending cap) and it doesn't pass, what will be your Plan B? Depending on feedback received, will you consider a "stronger" version of the Variable Miner Allocation plan (e.g. 80% MN/20% Miners) for proposal funding? (hilawe)
Answer [Ryan Taylor]: There are a number of other governance-related topics that might make strong candidates for proposed improvements. As voting participation has dropped and shared funds and exchange-operated MNs continue launching on the network without any desire to participate in voting, we certainly don’t want that to become a threat to the functioning of the governance system. There also appears to be great interest in potential changes to the proposal fee. We will assess our options based on feedback from the community and our developers.


Question: Is it possible for DCG to come up with a contingency plan in case a majority of the trust protectors go rogue, and against the wishes of the DAO, attempts to dissolve DCG or otherwise interfere with DCG's leadership? Could DCG fight such a maneuver legally and continue operating? (geert)
Answer [Ryan Taylor]: Trust protectors don’t actually have direct control over DCG. Instead, their power resides in the ability to assign the trustee. The trustee is responsible for ensuring all actions are in the best interest of the beneficiaries - specifically the masternodes - before carrying out any of the proposed actions of the trust protectors. The trustee is a licensed professional similar to a lawyer, so it is unlikely this person would act in a way that violates the intent of the trust. So it would take both rogue trust protectors and a rogue trustee. Even then, the DCG board, DCG officers, or any of the beneficiaries (e.g., any of the masternode owners) could take legal action against a trustee that was not operating in their best interest through the court system. In short, there are many layers of protection in place within a trust structure to prevent beneficiaries from potential harm, which is one of the reasons we selected this structure.


Question: Has DCG been in contact with Coinify since they delisted Dash, can we expect a relisting? (Sidem)
Answer: Yes, we are working to get back into their platform. As mentioned during the call, there are confidential parts of the compliance projects that cannot be shared in public.


What about the below question?

Ryan has said he doesn't see the proposal fee as a priority issue. Could this be because DCG consistently extracts 60% of the budget and has therefore formed a bias i.e. does not fully appreciate the impact the fee has on the treasury as a whole? From the outside looking in, to a prospective Proposal Owner, the proposal fee might be misaligned with expectations or simply not flexible enough.

More so, does DCG accept that a variable proposal fee might be more effective? What price discovery mechanisms would DCG like to explore?

Why didn't you answer?

How the hell do you expect the MN voters to govern effectively, while having currently only 5 questions to judge/answer for a whole month??

Do you know how many questions a parliament votes in a day?

Make the government questions cheaper now!
Make the proposal fee variable, or set it to zero and allow filtering and tagging!
 
Last edited:
What about the below question?



Why didn't you answer?

How the hell do you expect the MN voters to govern effectively, while having currently only 5 questions to judge/answer for a whole month??

Do you know how many questions a parliament votes in a day?

Make the government questions cheaper now!
Make the proposal fee variable, or set it to zero and allow filtering and tagging!

Well, the question was asked, though it was somewhat watered down. To me, Ryan seemed a bit agitated by the question.

I think DCG will continue in a state of denial, not least that their continued funding blinds them to external forces.

What I find most troubling, for years now, Dash Platform has consumed so much of the treasury, and DCG are constantly telling us they can't do X, Y and Z because their focus is so hard on Dash Platform. That's fine, but then really what they should do is separate out the Dash Platform group with their own proposal. This way we can clearly see the proportions and allow MNOs to properly allocate funds to other DCG tasks such as business development, marketing, governance and so on. Right now, DCG is cherry picking the scraps of time it has for everything else, very inefficient.
 
Another question that was posted:
Are spork keys within DCG a vulnerability for Dash? How about decentralized sporks? When?

Thank you for the Q1 update, exciting progress.
 
The same pathetic answer, from a person that does not deserve to be a CEO of Dash.

I hold no grudge, he has strength. If we can separate the Dash Platform processes from everything else, there will be more focus and accountability. Ryan can choose which group he wants to lead, just not both.
 
I hold no grudge, he has strength.

He has no strength.
My opinion is that he is mediocre and one of the reasons Dash is now the 50th coin instead of the 6th it used to be.

Well, you could argue that he has strength, because he rules a bunch of 200 idiots (the MNO electorate)
But can we name strong, a person that rules the idiots?
A strong person is the one who rules the smarts, not the idiots ones.
 
Last edited:
Comparing

Q3-2020 Call Roadmap


with Q1-2021 Call Roadmap



Just makes me feel very sad.. it seems stuff is just shifting quarter over quarter..
I would love to discuss the changes to the roadmap between the 2020 Q3 version and 2021 Q1 version. We publish our roadmap quarterly in order to provide transparency into our plans and I accept the responsibility of explaining changes. The biggest change actually occurred between the Q3 and the Q4 version. Although we thought we identified a path to mainnet in Q1, it had a lot of risk to it. It was flagged with an asterisk and carried many dependencies. By the next quarterly call, we had a real view of the remaining work and didn’t even project a mainnet target. I have tried to keep the focus on our quarterly call to discuss the plan moving forward, so I don’t usually take the time to explain the reasoning behind changes in scope or timing. This is something I can improve on in the future. However, let me explain the reasoning behind the longer delivery roadmap to mainnet.

Effort to release to testnet - The effort to release Dash Platform to testnet represented a significant body of work which was underestimated in the 2020 Q3 roadmap. The majority of the development work planned for Q4 was pushed forward as the development team prepared environments, tested and hardened code, and migrated the final release of the year onto testnet. We prioritized this deliverable because we believed that it would increase confidence in the quality of code and reality of our progress, despite the cost.

Changes to Dash Platform MVP scope - We increased the scope of what will be included in the MVP release of Dash Platform as we continue to scrutinize items in our backlog and receive feedback from the community. For example, we announced a shorter path to MVP with a release requiring running a full-node. As we contemplated the value of that release, we increased the scope to eliminate that requirement. We have also re-prioritized other post-MVP items for greater resiliency and reliability such as feature flags, strict data contract validation, local network setup, protocol upgrade process, and platform state sync. These should have been identified as increases in scope, but with a value to the network. It is possible that we may yet identify more scope to be included in MVP, but as a team we are prioritizing time to market over breadth of scope whenever possible.

Accuracy in estimating level of effort - We have been utilizing standard scrum processes for a couple years on the Dash Platform team. As I look back over the past couple quarters, there have been several cases where specific sets of development tasks have taken much longer to implement than estimated. We have bi-weekly sprint processes which include planning, grooming, reporting and retrospectives to help us improve in this area.

Dependency on Dash Core releases - In the 2020 Q3 roadmap, we were targeting to have Core v17 on mainnet in Q1 with all features necessary to support Dash Platform MVP. The Dash Core mainnet migration is now occurring in Q2, which represents a slip. However, not all of the features required for Dash Platform MVP made it into v17, so a v18 is necessary. It is fair to ask why we didn’t include all the features needed for Platform, especially since it was on testnet for 4 months. The answer is that design is not complete for asset locking and the resources required are fully engaged on other development efforts.

Dependency on Dash Core migrations - In our 2021 Q1 roadmap, we have included the timing necessary for the actual migration and activation of both v17 and v18 on mainnet. Activation by mining pools has historically taken about 6 weeks to complete. This is one-half of a quarter, and we need to do this twice prior to Dash Platform MVP being activated on mainnet. The 2020 Q3 development roadmap highlighted that 2021 Q1 was the target for a mainnet release. However, the roadmap never communicated the length of the activation and when Platform MVP would have realistically been activated. A Q1 mainnet release would have been a signal of readiness, but not accurately reflect its usability. This is an area for improvement that I see in our current communication which I will look to clarify.

In summary, if you are looking for an accounting of a three quarter change in the delivery date of Dash Platform, here it is. It is not based on Dash Core, although those efforts need to be aligned. We lost time moving to testnet, with scope increases to provide a more resilient, secure and usable product, and due to some under-estimation. We do have a dependency on Dash Core readiness and will need v0.18 activated on mainnet, which can not occur much sooner than Q4 of this year. We definitely missed an opportunity to have v0.17 be the dependency which was due to resource bottlenecks and constraints. This is one of the challenges managing the coordination of product delivery across teams, with a small set of resources - 50% of our 2018 headcount.

Thanks for the question. I hope you appreciate the transparency. I appreciate the opportunity to reflect and continue to mature and improve the organization.
 
Sporks allow features to be deployed to the network with risk mitigation as the goal. I personally believe the feature is brilliant, although - with great power comes great responsibility. It has to be the responsibility of some individuals to hold keys with which to enable and disable sporks. And in turn, with great responsibility, comes great power. That power has to be thoroughly understood by the holders of the keys and we can't put them in the hands of individuals who don't understand the technical and economic details of their actions. So, are keys within DCG a vulnerability for Dash? Absolutely not. Should there be great decentralization of spork activation? Of course, that is always a goal. With desires for anonymity, the need for thorough technical understanding, a vote of confidence by the network for the stewards, and other risk mitigating criteria, I believe the keys have been entrusted properly to this point. The track record of DCG's avoidance of risk is the evidence I need.
 
Bob. I hope you understand that there are masternode owners here who greatly appreciate your efforts and what you've been able to accomplish. IMHO you saved this project. Not everyone here has the ability to understand that, but there are some who do. Thank you.
 
Back
Top