Community Q&A - Q1 2020 Summary Call

[strophy]

This thread lists questions and answers from the DCG Q1 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: How important, do you think, is the ability to send Dash to usernames without first having to add each other to contact lists? If any, what are the obstacles that prevent you from having usernames as 'public tipping address' rolled out with the initial release of DashPay? (chinmi)
   
   A (Bob): I'll answer that as two separate questions. So, how important is it to be able to do that? We did not think that it was the most important to be able to pay to a username without having them be in a contact list. That's why we prioritized the workflows that have been set up, which is contacts, and contact list management is a separate function from the payment function. We have done that mostly to prioritize security, to make sure that we know that we have two parties accepting a contact request, and that we know that that user name that's in your contact list is somebody that you know. That obviously prevents you from inadvertently sending funds to a contact that you think the user name is kind of close but it's off by a character or something like that. We felt like that was the right prioritization of our MVP stories. But having an integrated user experience, where you could go in and say I want to make a payment to a username, and you put in e.g. demodash1 (as we saw earlier today), and it recognizes that that's not part of your contact list. It then sets up and does the same establishment from a security perspective to validate that user and have them accept you. Then again we're prioritizing security, but having a more streamlined UX there. So that was something that we didn't want to build into MVP, but will likely be a very fast follower for us. We think it's important but we didn't think that it was the most critical.
   
   As far as public tipping addresses go, really we have two things there. One is how do we tip? And can we do it in an easy manner and in a public manner. So obviously if developers want to put their public key address on a footer and say, hey send me a tip if you guys like what I did or if you like this code, that seems like that's the typical use case around it. We'll see in a traditional payment platform somebody says, hey here's my Venmo address, send me a dollar. So there are specific use cases for it. We don't think it's the most common use case, and so again that's why it wasn't necessarily in MVP. There are several ways that public tipping could be set up. Again, we want to make sure that we know who that's being sent to, and that people can accept it. Obviously as you manage public personas, if contacts are to remain private, different people have different levels of comfort in how those usernames are addresses might be out there. Obviously all the wallets will still have the traditional methods. So a QR code can still be put out there, we could still use other addresses, but we'll see those coming in after MVP.
   
   
2. Q: Will we see Dash Platform on mainnet before Q3 this year? (splawik)
   
   A (Bob): Before Q3, the answer would be no, because that would mean it would have to be delivered this quarter. This question was submitted prior to seeing our roadmap and the progress chart against the major components. What you saw today was what will be left over at the end of Q2 to continue to develop. What I've been doing, and I feel really comfortable doing, is saying one: when can we get to testnet? And then secondly: making sure that I'm making commitments for this quarter and where I feel comfortable going to the next quarter. So the next quarter, meaning Q3 at this point in time, I'm not comfortable saying that it will definitely be on testnet in Q3. What I am comfortable in saying is that we're managing the scope very rigorously. The entire team because we wanted to get to testnet as quickly as possible, and so I think we've all provided as good of an insight as anyone has today. We want to make sure that the product is well suited for the purpose at hand. So, no, it won't be out before Q3. But as you saw again in the presentation there is a very small set of tasks left to do after after Q2 of this year, so I'll leave it at that for today.
   
   
3. Q: Will DCG look into submitting a budget proposal to have at least 1 DCG team member working full-time on product adoption in Venezuela?
   
   A (Fernando): Not in the short-term. As we just saw, we have a new and more detailed strategy for Venezuela. Some of those actions are already going on, some will start in the next few weeks. Those costs are paid with business development and marketing budgets, and that's what we will do for the foreseeable future. This is just one more market where Dash is trying to achieve things, so we don't see a reason to separate it completely from the others. It's a multi-budget and multi-department effort. Having said that, we have our Head of Business Development Ernesto Contreras who is himself Venezuelan, so we have a very deep understanding and knowledge of the market, which is great for us obviously. We also have a lot of great local teams with whom we are going to get more involved in the near future. We've started to get more involved with them so we can all work in a more coordinated fashion, as Ryan detailed before. So we are not hiring someone separately, but it will have a bigger share of our time and budget in the next few months.
   
   
4. Q: Request for an update from DCG on any proposal(s) to change the percentages of block rewards and/or the treasury. (Amanda B. Johnson)
   
   A (Ryan): As I said earlier, this is a very meaty topic requiring a great deal of explanation and depth of analysis to really create the backdrop for the decisions that were made and what we're proposing to the network. I am going to be holding a separate video conference with the community to share that information and then answer any Q&As associated with it. Specific dates will be released here within another week or two.
   
   
5. Q: What are the teams thoughts around introducing smart contracts? There are just so many beneficial elements that are derived from the ability of entrepreneurs to utilise smart contracts that I would think giving developers the option to utilise should outweigh any downside risk. (itscrazybro)
   
   A (Bob): Our team is generally interested in adding smart contract functionality to the platform. We think that that would be helpful at some point in the future. Obviously we've all had the benefit of looking at smart contract implementations in other projects, and we see the benefits of them, so we don't need to be be sold on that. I think the usability of them, how broadly they would be used and then the level of effort to build it into Dash platform, is probably the more significant thing. So right now it is not on our roadmap. That doesn't mean that it couldn't get on there very easily, but we would definitely also want to engage our masternodes as far as understanding the implications of running some sort of virtual machine and adding to the infrastructure load, we want to make sure that we're handling those trade-offs properly.
   
   I think the best thing to do would be to engage the community. This would mean going back to Discord and creating a discussion around smart contracts and their implementation. This will allow the community at large to engage in that thought process - defining what the specific use cases would be that we would want to target first, what the specific scenarios or personas that we're trying to address are - that could really help us develop that scope. This takes it down from smart contracts, this whole big thing that has to be developed. Maybe we can start implementing things on a more incremental basis. So, for itscrazybro, who asked that question to us, love to have you there as an active member of the community engaged in the conversation and help us define what smart contracts would mean and how they can be implemented within Dash Platform. So today: not on the roadmap. Everybody's interested in them, because we've seen smart contracts deployed before. It's time to start the discussion because all of the foundational aspects of Dash Platform will be released soon.
   
   
6. Q: I noticed that DCG funding requests have had their asks reduced in accordance with the upcoming block reward reduction, what is the new Dash target break even price for DCG funding? (agnewpickens)
   
   A (Glenn): We've committed to not taking more than 60% of the total proposal revenue available from the network. So as the block reward reduction occurs, we correspondingly also ask for less Dash for Dash Core Group. I touched upon it during the presentation, but the new break-even price is $70. Anything above $70 and we're putting away funds towards our reserve, anything lower than $70 and we're starting to eat into our reserve.

 

[strophy]

1. Q: How is the reserve fund holding up, and how is the morale on Core, everybody doing all right? (solarguy)
   
   A (Glenn): In terms of the reserve fund, I dove into that during the financial review. To reiterate, our non-compensation account is in really good shape. Our compensation account right now holds two months salary. We really like to be at a minimum of three months, which is why we submitted two compensation proposals to the network for that sixty percent of the total proposal funds. As far as morale - I would say overall it's good. We've had some great progress in terms of our technology, our Dash Platform releases that Bob referred to. The price is above our breakeven right now, so overall the team is working well together and we're just really excited about 2020 and continuing to deliver.
   
   
2. Q: To cut down on the network's annual legal expenses, could the Trust absorb the functions of the DIF, or the DIF absorb the functions of the Trust? Why or why not? (Amanda B. Johnson)
   
   A (Ryan): The short answer is it is probably not as beneficial as one might think, and there are some downsides to it. I'm not saying it's impossible, but I do think that there are limitations here. First in terms of the legal expenses: currently the the legal expenses for the trust are relatively low. They don't require the same level of government or licensed oversight the way that the DIF does. Part of that is just due to the limited activities that the trustee is required to execute. So once these entities are set up, maintaining them is much less expensive than the set up. The second thing that I would point out is they really have different purposes. Because of the different purposes, the network probably benefits from installing different skill sets to oversee a technology delivery company (Dash Core Group) versus overseeing an investment organization. Those require different skillsets and very different levels of involvement. So it would require that the network consolidate those and that might make it more difficult to assign appropriate people to those tasks.
   
   There's also some differences in the needs of the two entities. In the case of Dash Core Group, one of the advantages of our structure is that we're owned by a trust in New Zealand. New Zealand is well respected, it certainly doesn't introduce any hurdles for us in terms of the interactions that we have with say banks or other financial institutions. In the case of the DIF, we had to set up a structure in which there is no owner and there is no member. That has some advantages and disadvantages. The advantage is that it ensures that there is no ultimate beneficiary outside of the network itself. It has proven difficult for the DIF to obtain financial accounts. They thankfully announced that they managed to obtain their first two. I think that they're hopefully up and running at this point. I think that if the DIF were to acquire all the shares of Dash Core Group, which is not a profit-making entity, that's certainly possible. But it would now introduce those challenges to Dash Core Group. We would have all of those same issues that the DIF has faced in conducting financial transactions. And it's not possible to go the other way. The DIF can't be sold. That's one of the advantages to the structure that we chose. There's no way for the supervisors to divest itself, if you will, and therefore it can't move to the trust.
   
   So there's limitations of what could even feasibly be done. If we were to do them I think there would be serious drawbacks, so if it's not clear-cut to me that that would be a wise move. Hopefully that helps paint some of the complexities of that picture, and why we chose different structures for the two entities. Like I said, I don't think that there is a great deal of savings associated with moving one to the other, because the tasks involved are very different and therefore whether we moved the Dash Core Group under ownership of the DIF, or attempted to do vice-versa... if it were even possible, the fees that the the service providers would charge would simply go up. So I don't think that this would really generate a lot of legal expense savings.
   
   
3. Q: In the past DCG used to ask for separate funding for each major department. I believe when they stopped doing they said if the DCG proposal got a certain percentage of downvotes they would go back to seperate funding. Is this still the case? What was that percentage number? (Mastermined)
   
   A (Fernando): In the early days, we used to do different proposals for different activities. We decided to do that (integrate them) because all of them were passing with very high net positive votes, so it felt like a waste of time and funds. But we committed to break it down again if the compensation proposal were at any time to get more than 10% no votes of the total votes on the proposal. Even if it were passing very highly, we would do that. That happened in August 2018 I believe, and then in September we broke up the proposals in three. Three of them passed, and what we said then was that once the trust was set up and the protectors were in place, we would stop doing these because now the network has a much more granular and direct way to go into the details of different functions in DCG, and try to intervene in those. So when the trust was set up in early 2019, since then we are having regular meetings with trust protectors. If the network wanted to do anything regarding one of the functions, or several of them, that would be the path.
   
   Regarding this, I want to remind everyone that tomorrow we have trust protector elections starting. So please vote! Precisely because of these and other things, it's very important to get a good set of protectors elected. So as I said, it starts tomorrow. I think it ends at the end of the month. It's a short thing so please be aware, and please vote!
   
   
4. Q: DCG used to list how many full time vs. part time employees it had. Can we get an update on that. (Mastermined)
   
   A (Glenn): We have 34 contributors to the project including 2 volunteers who are currently working for free. They draw no salary. Out of the 32 paid contributors, 25 are full time and 7 work on a part-time basis. Part time we define as anyone working less than 33 hours a week. We will provide that breakout in our compensation proposals going forward, since that is valuable information for the network to have.
   
   
5. Q: Would DCG use a similar hedging strategy as what the DIF and Demelza are planning to do?
   
   A (Glenn): I'm a fan of what the DIF is doing and Demelza in terms of how they're investing: holding Dash and investing into gold. Unfortunately that doesn't work for Dash Core Group. It makes sense when you look at the purpose of each entity. For the DIF, it's surrounded around investing. For Dash Core Group it's really about using the Dash funding that we get from the network in terms of operational expenses. So we don't want to "gamble" with the money we get from the network in that sense. All our liabilities are in USD, so the most prudent thing is to take that Dash and sell it off into USD and hold a USD cushion. If we held significant amounts of Dash and the value of Dash were to go down, that would really affect both our income statement and our balance sheet at the same time. That's not a prudent thing to do. Because we want to limit our risk, we need to hedge all the funding we get from the network out into USD.
   

 

[strophy]

1. Q: Could core devs comment on the “Dash Party” fork of Counterparty that is currently a live proposal? How would this work with Dash Platform, is it complementary or is the required implementation of opcodes contrary to our chosen development direction?
   
   A (Bob): We are not in the habit of commenting on specific proposals as we need the community to vote on what is funded. For those not familiar with the discussions which have taken place on public forums, the proposal is to build CounterParty for Dash. The intended approach includes changes to DIP2 to include storing data on L1 specifically for DashParty. This is not complementary to the architecture of Dash Platform as we handle data storage and business logic on Layer 2. However, this has been applied to other blockchains, so can work. People have found many creative uses for op_codes and it could be implemented this way. I believe there is a component to the proposal which is requesting changes to DIP2 for special transactions looking for a DashParty specific transaction. Protocol changes would likely be much harder to achieve, especially for one group’s individual purpose.
   
   
2. Q: Request update from DCG / ASU - Investigate methods to apply zero-knowledge proofs to blockchain identities (circleio)
   
   A (Ryan): One of the issues we frequently hear from masternode owners are concerns over the public nature of their proposal system votes. These concerns have resulted in some undesirable effects. For example, some masternodes do not vote on potentially polarizing proposals to avoid the risk of scrutiny or harassment.
   
   Arizona State University is researching the application of zero knowledge proofs (ZKPs) to enable the network to collect and tally votes without revealing individual votes. There are several challenges with doing so, because each algorithm requires trade-offs regarding:
   • setup (trustless vs. trusted vs. semi-trusted)
   • performance / speed of calculation (and therefore frequency with which a continuous vote status can be produced)
   • visibility (e.g., whether you can see who voted, even if you can’t directly determine how they voted)
   • level of maturity (whether open source code exists or the algorithm is still in concept stage)
   • fit with Dash (level of modification needed to integrate)
   
   There is no perfect solution. However, the team is making good progress assessing the range of possibilities and proposing viable options for practical implementations. There are at least two solutions that we believe have promise. One seems to meet the needs for Dash by anonymizing the vote and the voter, but its threshold encryption capabilities are lacking and it can probably only provide periodic snapshots (as opposed to continuous). Improving the threshold encryption capability is feasible, but requires significant effort.
   
   Another proposal leverages an algorithm that provides continuous vote tallying. However, that solution is not yet coded and requires integrating several existing capabilities together. Another problem is that it only anonymizes the vote, but not the voter. With continuous vote tallying, it won’t matter that the vote itself is private, because by tallying the votes before and after a vote is cast will reveal it. To address this shortcoming, the team is investigating the possibility of integrating a Chaumin-like key-swapping capability that would add voter privacy.
   
   The goal of the project is to determine our options and scope the effort required to integrate a practical solution into Dash’s code that will enable ZKP voting. It seems that the team is pursuing a very thoughtful path towards accomplishing that. Results from the research as expected over the summer, and we’re next meeting with the research team on May 22nd for our fourth update on the progress.
   
   
3. Q: Is there a chance of DASH forking away from proof of work in the future? (arwed)
   
   A (Ryan): It is very difficult to speculate about future advances in consensus algorithms. Our assessment of current technologies is that they are either unproven or have known vulnerabilities that proof-of-work doesn’t. Therefore, we don’t think forking away from proof-of-work is prudent currently. If the vulnerabilities of other consensus mechanisms can be addressed, we would reevaluate the situation and whether it could benefit Dash.
   
   
4. Q: What are the risks and benefits of leaving the ability to disable the superblock with three keyholders (as is currently the case), versus transferring that power to the network as a whole? (Amanda B. Johnson)
   
   A (Ryan): There are risks with continuing to maintain this spork. Although it could be used to prevent an error superblock (for example one that exceeds the intended emission), at this point that scenario is unlikely to happen with proven reliable code that has functioned as expected for over 50 superblocks. At this point, we intend to deprecate the spork completely in an upcoming release. While we haven’t scoped the work or assigned it to a specific release on the roadmap, we have determined that it should be deprecated in the next 2-3 major releases.
   
   
5. Q: Digital Cash has a number of properties (instant tx's, privatesend option, user-friendly wallets). Dealing with volatility is the big remaining pillar, it would be great to be able to turn off volatility via a hedging option. DEBNK offers a leading method to build an in-wallet hedging button, what are the next specific steps for Dash to implement an in-wallet hedging solution? (Currency_use_case)
   
   A (Ryan): This is a functionality we are evaluating for our wallets via a simple conversion method such as a button. However, hedging to local currency is actually something our users can already do (with a couple extra steps) through our integration with Uphold. With an Uphold account, users can convert Dash to over two dozen fiat currencies or several precious metals with minimal fees.
   
   
6. Q: What your thoughts, Ryan, on the direction the DIF has taken and its performance to date? (kanuuker)
   
   A (Ryan): The DIF supervisors have taken on far more day-to-day responsibilities than we envisioned when the entity was first proposed - and even at the time of the elections - mostly due to the lower price of Dash. The lack of resources certainly makes that a challenge for these unpaid roles, so I commend all the supervisors for the time they have devoted to make the entity operational. The work involved in establishing accounts, policies, and processes at a committee-like board of supervisors (all with differing ideas) is likely to be many times greater than would be imagined externally.
   
   Now that much of that work is complete, I hope the masternodes can utilize the DIF when funding proposals that come to us from profit-seeking entities. In the meantime, I think the strategy for managing reserves is well-reasoned and provides some admittedly limited price stability benefits to the network.
   
   Speaking honestly, I was not particularly excited about the first proposed investment, as I think it potentially strayed a little far from the mandate under which the DIF was created. A major component of the rationale for the investment was as an opportunity to market Dash in Europe. It would be very difficult for the DIF to prove measurable value from an investment aimed at gaining exposure for Dash. The feedback from the network surrounding that first attempt has helped define a more narrow focus for the DIF going forward, and I know the supervisors are trying to learn from that. It will also likely encourage future supervisor candidates to clearly define their vision for investment strategy as part of the election process. Ultimately, I think these types of growing pains will work themselves out as the DIF and the network align.

 

[strophy]

1. Q: On condition of a successful proposal, would DCG directors and developers agree to a polygraph test to assert they have not been recruited or directed by government agencies such as the CIA, FBI or NSA? (GrandMasterDash)
   
   A (Fernando): Administering a lie detector test would only serve as a distraction to our employees and contractors without any clear benefits. DCG contractors don’t have any information about the protocol that is not publicly available, so it would not make sense for any agency to hire anyone to infiltrate the company or sabotage the product. Even if they did, because the code is publicly auditable, any malicious code would not go undetected.
   
   
2. Q: Has any further thought been put into addressing the legibility/perception/comprehension issues that arise when pricing items in dash, caused by a high single unit value? i.e. low value items such as a cup of coffee are valued as a small fraction of one dash, which makes it very difficult for people to comprehend how much they are actually paying, especially once we go past 2 decimal places. (dashnode)
   
   A (Ryan): This issue has been debated extensively from both usability and technical perspectives. No major coin has expanded its supply through the equivalent of a “stock split” in the cryptocurrency space, and part of the reason is the technical challenges of doing so. Introducing new base units to shift the decimal place risks users requesting or sending incorrect amounts, for example. The way other projects seem to handle this is by leveraging new units for transactions such as satoshis in Bitcoin. We’ve stated in the past that should another major project demonstrate a path to migrate to a new unit system successfully, we would certainly be willing to evaluate it.
   
   
3. Q: What steps can Dash take to incentivize better proposals? Would solutions such as not burning the proposal fee but instead distributing it to professional proposal evaluators be better? What steps can DCG take to implement the use of proposal fees to incentivize competitive, professional and thorough proposal review? Could the proposal fee e.g. be distributed to users making broadly upvoted comments in the proposal discussions? (Currency_use_case)
   
   A (Ryan): Although there are improvements that could be made to the proposal process, we perceive that it functions quite well to distribute funds to teams the network supports as intended. While these or other ideas may improve the system, we plan to continue focusing the vast majority of our development efforts on user-facing aspects of Dash where we can deliver the most value.
   
   
4. Q: Could DCG comment on why we are utilizing inflation to pay for mining? Could we remove payments to miners from the block reward and allow fees to reach a non-subsidized equilibrium instead? (Currency_use_case)
   
   A (Ryan): Transaction fees alone are insufficient to maintain Dash’s X11 dominance. Making such a change would therefore leave the network vulnerable to attack. While ChainLocks provide strong security, in rare circumstances they can fail for a variety of reasons. Subsidies do decline naturally over time, and we will be proposing a change to the subsidy allocation in the near future. However, completely eliminating the subsidy for miners is not something we’re considering.
   
   
5. Q: I remember one of the Evolution plans being the ability to mix with the QT Core wallet and then log in to your mobile Dashpay app (with username) where you can see your private funds and public funds balances and use DAPI instead of trusting an SPV server. Is this still planned or something different? (Bridgewater)
   
   A (Dana): While this functionality will eventually be possible on Dash Platform, it won’t be part of our first release to mainnet. In order to accommodate a feature request like this, we would have to introduce what we call “passport” functionality. This involves the platform associating different wallets together, so that a user can be prompted on their mobile device to take an action regarding funds in a different wallet. The platform team needs to spend time designing this complex feature, and since we have other priorities in mind, namely a faster initial release, we’ve deprioritized this for now.