July 25, 2020 1:31 am

Community Q&A – Q2 2020 Summary Call

This thread lists questions and answers from the DCG Q2 2020 Summary Call. The first posts contain transcribed answers from the call, and remaining questions will be collected and posted here over the course of the week. Questions are as follows:

  1. Q: Is Dash Platform and Dashpay still aiming for 2020 release on mainnet? Is there a way we can see the percentage complete of Dash Platform and DashPay?

    A (Bob): I’ve been consistent in only setting expectations around testnet delivery for all of our products, because that’s kind of when it goes out of our our hands and we can have better control of the commitment on that. So, as shown today on the roadmap, we’re aiming for a platform release next quarter to testnet. We’re all very excited about that. We’re still exploring the possibility of Dashpay on testnet as well, and all the teams are really focused on getting Dashpay to the community as soon as reasonably possible. So with the target now communicated for Platform, we will be able to answer that question more fully on the next quarter’s call. Again, going back to what I stated before, this is the first time we’ve gone out two quarters as far as visibility into the roadmap. So what we’re talking about is next quarter, and typically in the past we’ve only done one quarter. So I’ll have an ability to commit to that on the next quarter call for Dashpay wallet in particular.

    Another question (or part of that question) we received was regarding the actual percentage of completion of each project. We do not use that as a primary metric since there’s many, many ways to define both the numerator and denominator. Whether it’s hours or epochs or stories or points… I mean, it’s really really tough. So I think the best metric is the amount of time left, which we just provided greater visibility into. This shows us in the home stretch.

  2. Q: Dash’s codebase continues to diverge from bitcoin and AFAIK the last independent audit was five or six years ago. Will DCG commit to an independent security audit and code review within the next 12 months? If not, why not?

    A (Bob): It’s a great question, and a great prompt for us to take action. The idea of an independent external security audit benefits the entire community. Our role, as just the steward of the development efforts, means obviously that we share the same concern about code reliability, quality and security. We would need to propose to the network to properly fund the venture, as well as safely convey the results of the audit. If any of you have been involved in security audits, you would understand what that means: that we need to make sure that security is protected. So I can’t commit to conduct the audit if there’s no resources. But I can commit to submitting a proposal to the network to fund this. So in short: yes. Thanks again for the question, and we can convene as a team and talk about how to move that forward.

  3. Q: A recent poll Ryan conducted in the #mno channel of the Dash Talk Discord showed 22 MNOs voting for a 65% masternode / 35% miner block reward split, with only 5 voting for the 60%/40% split that Ryan ended up proposing to the network. The same poll showed 26 MNOs voting for 100%-masternode-funded superblocks, with only 9 voting for miners to help subsidize the superblock. In Ryan’s upcoming proposal regarding superblock funding, are MNOs going to have an option to vote for 100%-masternode-funded superblocks, or only the less popular poll option like in the last proposal? (Rion)

    I’d like to take a step back and talk about what the entire poll was about. It was really to get feedback from the masternodes on what their preferences were. There were other questions involved as well, and the questions covered four main areas:

    1. The first area was the amount that was being reallocated
    2. The second was the timing with which the reallocation occurred (and there was some subtext there about the degree to which the reallocation was front loaded versus back loaded within that time period)
    3. The third area was around when a proposal was funded, who does that affect, or when an unused portion of the available proposal funding was not used, where does that funding go? I guess there’s a couple ways you could look at that.
    4. The last was the amount that is being reallocated
So there were several topics covered. What the masternodes voted for, overwhelmingly across all of these questions, was for a larger reallocation from miners to masternodes. They wanted it faster, they wanted it to occur in a more front loaded manner, they wanted it to also provide a fixed amount to miners, such that as proposals were awarded, that would come exclusively from the masternode portion of the funding. One of the things that I pointed out early in this process was all of these things are not compatible with one another. There was one other area, by the way, which was whether or not to have a cap on the funding for the proposal system. The feedback that we got was that most people preferred to have a cap and not allow the network to infinitely fund or fund 100% of the proposal funding towards proposals. The median response was the 20% that we had put forward, so that was good. There was also overwhelming support to accelerate the timeline and make the reallocation occur quicker. That was actually the strongest level of support out of all of these other options. We incorporated that feedback into the proposal, shortening it by about 30% and front loading the reallocations so they occur more quickly, with most of it occurring within the first year and a half. So we really did take the feedback into account.

If you start piling on all of these things, all of which are negative for miners, a couple of things happen. The proposal that we had originally put forward was relatively neutral for miners, despite the reallocation. The price support that it should provide, it could be argued to miners that this is neutral to positive for them overall. And I spent a lot of time with our mining community talking to the largest miners I know of in order to get their feedback and support on it, so that we can get a smooth transition to this new allocation model. And I’ve largely gotten that. But I think if you start to pile on and say well, we’re actually going to do a deeper reallocation, we’re going to reallocate that faster. We’re going to take away some of the variation that you can benefit from if the price of Dash goes up, and the proposal funding doesn’t go fully utilized, that kind of supercharges that effect for the miners. And do some of these other changes that are beneficial to masternodes, but not necessarily beneficial to miners. What that creates is a dynamic where we lose that miner support.

Now, in light of ChainLocks, one of the common questions I get is “well, can’t we use ChainLocks to force a hard fork upon the network?” And the answer is we’ve never used it that way before. We’ve used it to enforce the the first-seen rule on the network, so that a valid chain tip can’t be invalidated later. We don’t have full visibility into what it would be like to use that functionality to actually hard fork the coin. Why is that? The answer is there’s a lot of third-party wallets that don’t recognize ChainLocks or InstantSend. They aren’t capable of detecting them. There are a lot of exchanges that are in the same category. At the very least, you’d want greater than 50% support to eliminate risks and make the transition a smooth and safe one for our users. And so I think the answer for me is, as you start to pile on all of these requests from the masternodes… I recognize the source of the desire for a larger reallocation. I think to the extent that we can reduce the disruption and risk to the network, and do this in a way that ensures that the network moves forward cohesively and not chaotically, I think that that is a beneficial one while addressing the goal that we set for ourselves in the first place, which is to reduce the circulating supply growth rate. The plan that we put forward achieves that without introducing all of these other risks.

So for me, I think if Dash Core Group is going to put forward a proposal, I don’t think it should be on the basis of a popularity poll or a poll from one affected group within the network. It seems pretty obvious to me that if you ask masternodes if they want a larger share of the reward, and they want it faster and they want it, you know… it’s very clear that they have a lot of incentive to answer that way. My incentive is to do it in a way that is safe and that DCG can stand behind a proposal that we’re putting forward that we believe in and believe does not put the network at risk. I believe that it’s our job to evaluate the options and to put forward a set of options that make the most sense for the network overall. So that’s what we’re doing. I’ve really taken the feedback and we’ve done a lot of analysis around this. We’ve engaged with a large number of the developers on what it could mean, or what the risks might be associated with doing something more extreme than what is necessary in order to address the issue that we identified. And we’re not there yet. We’re continuing to …………

Please see Full QnA at:

Author: Strophy
Original link: https://www.dash.org/forum/threads/community-q-a-q2-2020-summary-call.50484/

About the author

tungfa

Communications

tungfa is responsible for social media communications, and posts both original stories and links to news coverage of Dash from around the web.

Back to all articles

tungfa

Communications

Go Offsite Icon
November 4, 2024

Data Contracts: Like Smart Contracts But Better
November 1, 2024

Use your name, not your wallet address!
September 30, 2024

Why hasn't crypto taken over the developing world?
September 19, 2024

DashCore v22.0 Product Brief
September 2, 2024

The Evolution chain has officially launched and is producing blocks!