Store of Value Community AMAs - June 2020

strophy · Jun 12, 2020

This thread captures questions asked and answered by Ryan Taylor, CEO of Dash Core Group, during the June 2020 AMA sessions regarding improving Dash as a store of value.

Dash Nation Discord AMA, 2020-06-10 23:00 UTC

Q: What is the action plan if the move towards lower mining rewards produces the opposite desired effect or other undesired effects that we are not in a position to predict?

A: We have been especially cautious in our approach to avoid as much risk as we can arising from unforeseen effects. However, if there were concerns that the changes were causing greater harm than good, we could conceivably submit another decision proposal to freeze the allocations wherever they were, or even revert to the previous allocation settings.
Q: How are we going to keep track of the effect of lowering the mining rewards? What are the key metrics and what noise should we zero-out (if any)? For example a sharp rise in valuation a month or two after the switch cannot be correlated 100% to this decision (or vice-versa).

A: The changes are targeting to slow the growth rate of circulating supply. This is easily measurable on a quarterly basis, and can be compared to the range we projected in our models. Because valuation is affected by many other attributes, I would not attempt to measure the results based on price.
Q: In the past you have commented on the diminishing marginal benefits of PoW mining as a key reason why it was good for Dash to adopt our current 45/45/10 split of the block reward instead of Bitoin's 100% PoW allocation. In the recent Tokenomics presentations, the focus has been more on providing price support by controlling our expected rate of increase in "circulating supply", as opposed to optimizing our block reward for maximum efficiency.

The new proposal, which is 0-20% flexible treasury with the remaining block reward split 60/40, would reduce the effective miner compensation of the block reward from the current 45%, to somewhere between 32%-40% depending on the size of the treasury. The assumption must be that we are paying for way too much PoW at 45%. How do we know that 45% is too much PoW overkill, and how do we know that 32%-40% for PoW is not still too much PoW overkill?

A: The primary goal is to stabilize the growth of Dash's circulating supply, which would have a stabilizing effect on value over longer periods of time. The reason I illustrated the diminishing returns of incremental hashrate previously was to help illustrate how we can achieve this without a major impact to security of the network. I would not describe the primary goal to be to minimize the amount spent on hashrate... you always want a significant buffer, which this plan retains.
Q: I can recall that in the past the option to have collateralized mining was also on the table of discussion. Since the proposed changes are aiming to provide price support by reducing our inflation could that option be opened up again for consideration? New required collateral can help in the locking up of Dash just like MNs do. Do you see any obvious faults with it from the get-go or are there any reasons that we shouldn't even explore that possibility?

A: Because of the sensitivity of the network economics, introduction of completely new concepts like collateralized mining carry greater risks. It would also require much greater development efforts to pursue this route. Given that we believe we have a solution to the stated problem (circulating supply growth) that requires little effort, results in predictable outcomes, and wouldn't risk dramatic unprojected changes to the circulating supply, we feel this is a more prudent path.

It is possible that some form of collateralized mining could cause sustained demand for Dash that could reduce our circulating supply, it could risk over-shooting what we need and result in a smaller base of circulating supply than we intended. If that were to happen, we would find ourselves with a similar situation just a few years down the road.
Q: How are we going to keep track of the effect of lowering the mining rewards? What are the key metrics and what noise should we zero-out (if any)? For example a sharp rise in valuation 2-3 months after the switch cannot be correlated 100% to this decision (or vice-versa).

A: Even if we do this change, I don't think there's really any good way to prove that it worked or it didn't. If the price goes up we can't know for certain that it wouldn't have gone up even more if we had stayed put; and conversely if it goes down there's no way to know for sure that it wouldn't have gone down more if we had stayed put,...etc. IMO we can only go based on the economic model, either you buy into it or you don't; there's way too much market noise in the wider market for other factors. Unless there's something I'm missing?
Q: Followup to previous question Re: having a significant buffer of hashrate:

What are some ways to evaluate how much of a buffer is needed in terms of PoW hashing? How do we know that we're not already going too low on the buffer with this proposal, or if we still have way more than enough (where we could consider reducing it even further long term, in order to allocate to other purposes)?

A: There are several ways to measure this.

1) "nicehashable" / excess capacity that is currently available for rent vs. hashrate of the network, 2) Dash's share of X11 hashrate across all coins,
3) allocation toward miners per unit of time.
Q: It is obvious that the gravity of influence from DCG towards the proposed changes is considerable. Bundling this with the fact that the MNO network has a tendency towards reactivity instead of proactivity when it comes to voting or researching on proposals in general I would assume the influence on this proposed change (reward re-distribution) is even greater. Since the provided research was spearheaded by DCG, in the event of the proposed changes not achieving our aim and the nature of the proposal not being a deal-breaker, in the sense that the MNO network would not want to defund DCG for just this one mistake, how would DCG react acountability-wise in order to restore the would-be damage on the trust relationship between network and DCG?

A: The changes are targeting to slow the growth rate of circulating supply. This is easily measurable on a quarterly basis, and can be compared to the range we projected in our models. Because valuation is affected by many other attributes, I would not attempt to measure the results based on price. So the best way to measure the success imo, would be to measure the actual vs. projected change in circulating supply growth rates. If the results don't match the models, we should reassess.
Q: Will Dash's total coin supply emission rate always be kept exactly the way it is currently predicted/expected to be? Is there a way for masternodes to guarantee or promise never to manipulate it in the future? Does someone investing in Dash not have to worry that coin supply won't someday be manipulated by the masternodes who control it? Is Dash scarcity as immutably certain as Bitcoin's?

A: Coin supply in Dash - just like any cryptocurrency network such as Bitcoin - is dictated by consensus. Therefore, no network can ever guarantee there will never be a change in supply. If for example, Bitcoin network's security was beginning to risk compromise because the block subsidy was gone and fees were insufficient, it is conceivable that the network could resume a block reward if consensus was reached from the decentralized network. So I think I can only say that we don't have that intention, but it's also not in DCG's control that a change in supply would never occur at any point in the future. But that's no different than any other consensus based network.
Q: What do you think about the idea of fixing the mining reward allocation, and leaving the flexible treasury to only cut out of the MN-reward portion, in order to have a stronger incentive for MNOs to vote optimally? (Voting for a proposal means voting to spend 100% out of MN possible reward, as opposed to 40% coming out of someone else's money/rewards)?

A: The primary issue with this approach is that it misaligns incentives in a similar fashion to networks that rely on donations for development. It basically requires one group (MNs) to shoulder the full costs of proposals that likely benefit the entire network. If a particular proposal adds value to Dash that exceeds its cost, the system should encourage it to be pursued. The miners would presumably benefit as well, so I think having them share proportionally in the cost help the MNs reach more rational decisions without the burden of coat-tail-riding beneficiaries that don't contribute.

The risk is that good proposals may not pass simply because the burden of funding them falls on a subset of the network.
Q: Just to clarify my concern regarding the accountability question. I do not sense any ill intention from DCG on the proposed changes but I do like the quote "Plan for the worst, prepare for the best".

I would be concerned that MNOs might overreact if they view the changes as a solution to a price problem instead of growth rate of circulating supply (even though it has been clearly stated as the second) or as a situation that "We trusted you on this one but it failed" and backlash in the form of downvoting all or part of other proposals from DCG when it's clearly foolish to do that. A what-if contingency plan to any proposed changes is something that I like to see, that's all.

A: Understood. I think it would be difficult to predict the range of possible future outcomes and reactions from the MNOs to build a reliable plan. We always try to listen to the MNOs and community as a whole and react positively to their concerns. I would of course commit to continuing to do that. If many things are going wrong, though, that are impacting DCG's reputation and causing dissatisfaction overall, you could argue that any resulting changes may have been warranted.
Q: Granting that it's impossible to know in advance how strong the community consensus will be on this proposal, but assuming that MNOs are on board with this change with minimal tweaking, how quickly could this change go through the pre-proposal, proposal, implementation & testing, and deployment? (How soon from now until we could see the first hardforked block from the gradual transition?)

A: I disagree. I think you can measure the number of MNs predicted by the model and actual. By definition, you are also therefore able to compare actual vs. predicted circulating supply growth. If the model is correct, you should see the effects in those numbers, and the effects would be largely independent of price (which I agree is impacted by too many other things to measure success of this effort on).
Q: Concerning the increase of the budget by 10% maximum possible to date, to 20% possible, on which economic model an increase in production expenses (the development of the Dash protocol) can this lead to an increase in the value of Dash?

A: That depends on whether the approved proposals deliver more value to the network than they cost. If the MNs make high-quality decisions and approve mostly worthwhile proposals (there will always be some failures) then I think a larger proposal funding allocation could conceivably deliver far more value to the network than the miner allocation it would mostly come from, yes.
Q: This brings the possibility that not 10% but 20% of Dash created will be directly put on exchanges and thus double the available quantity. How can this be beneficial in terms of scarcity/availability?

A: Miners typically operate with narrow margins, so approximately 55% of rewards distributed today are directed toward activities that may require a high share of proceeds to be liquidated to cover expenses. Under the proposed plan, even if the full 20% were allocated to proposals, this would mean 32% would be allocated to miners (e.g., 40% times the remaining 80%). This means even in the most extreme example, 52% would be directed toward activities that may require liquidation, which would represent an improvement. If less than 20% were allocated to proposals, this percentage would be even lower.
Q: So, in your opinion, would it potentially be easier in Dash for masternodes to reach consensus and manipulate our coin supply than it would be for Bitcoin to manipulate its coin supply? Is that a relevant danger? Is being a solid store of value less important to Dash than Bitcoin?

A: I think coin supply is something that most people in crypto (including our MNOs) recognize the importance of. So I would assume that if it ever were to happen, it would be for some very good reasons. For example, security concerns that would make the network unsustainable, or heavy duty research that shows some benefit. I don't think this is a remotely serious near-term threat.
Q: The 20% cap budget is too high for me. Maybe 15% or even 12% to start and see how it does...

A: Thank you for the feedback. I mostly hear the opposite actually, that most people want no cap at all.
Q: From my perspective Dash is better than bitcoin at quickly adapting to what the network needs. In bitcoin what would likely happen is a very high profile long drawn out community split where you end up with two competing chains, and then only time would tell which one made the right decision.

A: Dash "halves" every 10 years rather than four, so Bitcoin, BCH, and LTC will need to grapple with that question long before we will.
Q: Seriously if we look at all the history of our budget we had more waste than positive and great ROI from so much proposals.. We waste so much money.. I don't want to increased this waste...

A: I'm not an advocate for no cap at all. I think that falls into "too many changes at once" for my taste. Especially since you always can retain the option to change it later. I think you need to be conservative with these changes.

I think the fact that proposal funding would affect MN rewards would help address this issue. But still, I would want the cap there in case we are wrong.

strophy · Jun 13, 2020

Zoom AMA, 2020-06-11 15:00 UTC
Recording password: 9k%yF*7B

Q: What is the action plan if the move towards lower mining rewards produces the opposite desired effect or other undesired effects that we are not in a position to predict?

A: I think it's a great question. I mean obviously if we do this gradually, the way that it is the way that it was presented where we're doing a small portion of the reallocation per quarter, we're not locking ourselves in at any point in time. We could take a number of actions, including issuing a freeze on further changes or even reversing them and reverting back to the reward structure that we have today. I will say we've been really cautious in our approach to avoid as much risk as we can, but if there were concerns that the changes were causing greater harm than good we could conceivably submit a follow on decision proposal that would reverse future changes or even go back to the way that things were. So I don't think anything's locked in stone, and given that these are very gradual changes I don't think the risk is very high that we notice anything averse immediately.
Q: How are we going to keep track of the effect of lowering the mining rewards? Are you going to track the price?

A: That's one question that has come up numerous occasions, and the answer is no. I think that probably the best measure of whether this is having the intended effect is: what effect does it have on masternode count, and how smoothly is our circulating supply growth occurring. Does it match the projections? If things go according to plan, we should see an expansion in the number of masterede over the next couple of years. That expansion should be gradual. I think we should start to notice that within the first few quarters. That would be for me the measure of success. Why? Well price is kind of a messy target. There's a lot of things that influence price. This could work exactly as intended, and the price could drop because of other reasons: regulatory reasons, coinbase deciding to delist us, or something... I think that that could occur. On the other hand this could fail to achieve the goals of reducing our circulating supply growth, and yet Dash's price could increase dramatically because of any number of reasons: because the price of Bitcoin goes up, or because Evolution is out and is causing a great stir or something. I think we need to get away from price as far as a goal for this. I would measure the success on whether or not it achieves the primary goal, which is reducing our circulating supply growth rate.
Q: We're talking about mining being an expense, and that's the way that I presented mining back in December. Yet this solution preserves quite a lot of our mining. I'd made the case that a lot of proof of work is overkill, because once you're secure, incremental hash rate beyond that doesn't really add much value, and so it's it's diminishing returns as you spend more and more on mining. The question is: are we still spending too much? Is there more room here?

A: I think it's a good question. I think it begs the question could we reallocate a higher portion here? When I approached the problem one of the principles that we all had in mind is reducing risk to the project. It was part of the objectives. One of the approaches is if you minimize the degree of change to the network, you should minimize the associated risk. So we were looking for a solution that was the least disruptive to these sensitive economics, but also delivered the intended result which was to reduce the circulating supply growth rate. Given our research, we found that a very small amount of proof-of-work reallocation would do the job, and therefore that was kind of a minimum amount of change that we could conceivably come up with that would accomplish the goal. Could you do more? Probably, you probably could reallocate a higher portion of the block reward.

There's a few reasons not to do it: one is that there's diminishing returns with this type of approach as well. Reallocating the first 5% gives you the most bang for your buck. Reallocating the next 5% gives you a little bit more. And as you start reallocating more and more, the maximum growth rate in circulating supply dips just a tiny bit more. So theres diminishing returns on the reallocation itself, and there's less and less an argument for each 5% or whatever percent you do. The other concern here is that ChainLocks are not 100% effective. There are times in which ChainLocks have failed, particularly during high network load periods. Now we've done a lot of optimizations in the last couple of releases, and we've got some more coming that will take advantage of multi-threading, prioritizing ChainLocks over other tasks at the masternode level in order to make those even more effective. But, you know, conceivably we do have to fall back onto proof of work from time to time, and can't 100% bank on ChainLocks for every block.

So with that in mind, we wanted to maintain a high level security. If we could avoid dipping further into that proof-of-work allocation, that was desirable. Because it is conceivable, although we consist of 97% or something of the X11 hash rate today, it is conceivable that at some point in the future Bitcoin Cash or somebody else decides: you know what, I need to be number one of my hashing algorithm and we're gonna switch. So at that point we really will be dependent on ChainLocks.,So to the degree that we can preserve that X11 mining dominance, that's very desirable for us. So that's a few of the reasons why we didn't propose something that was more significant. The more buffer we have, the better.
Q: With the proposed changes, how long will it be until Dash's circulating supply growth rate is under 4%? How long until 3% and 2%?

A: That's a great question. It's not until around the year 2030. I referred to this as flattening the curve because I felt like it was a concept that most people will understand. We're not changing the emission - we're simply shifting a lot of the growth rate in the circulating supply out by sequestering a portion of the coins that are being created into masternodes, or encouraging the creation of masternodes. By doing so, you're actually lowering the base in future years. So for example, compared to doing nothing, in the year 2030 there'll be a lot more masternodes under this plan than the current network allocation. If you have a lower base and the same growth in coins, you have a higher growth rate. So the effect is partially permanent because the growth in masternodes is real and significantly higher, even after the reallocation ends. So part of this is "permanent", but part of it is just shifting that growth rate out into future periods. It isn't terribly significant though. If you look at the difference between the date that you would hit 4% under the models without making a change and the year in which you would hit 4% with this change, it's only about 1-2 years difference. It doesn't significantly change the date at which we'll hit some of those critical growth rates of 4%, 3%, 2%. I don't necessarily want to target matching Litecoin, Bitcoin Cash or Bitcoin on that metric, because I don't think it's necessary. I think as long as the gap is "small", we should be able to make up for that with other strengths the network has, such as paid masternodes or paid nodes on the network, such as ChainLocks, InstantSend, our governance system... all of these are advantages that we have over those other coins. I don't think we need to out-compete them on circulating supply growth as well. I think getting this down into the range in which it's competitive with the long-term growth rate of the US dollar is probably as close as you need to get before it just becomes noise. What I do know is 23% circulating supply growth in a year is far too high, and even probably 12% is far too high. That's noticeable even on a month-to-month basis, and can lead to, you know, the kind of relative performance that we've seen. I think this is about narrowing that gap. Hopefully that answers the question. I don't think we hit 2% circulating supply growth until 2035 or something, but it's basically the same under the both under any circumstance.
Q: A collateralized mining question came up yesterday. Do you see obvious faults with it, or reasons we shouldn't explore that possibility further?

A: What collateralized mining is, is some form of requiring miners to hold a certain amount of Dash in a similar manner to how masternodes are required to hold a certain amount of Dash in order to be considered a masternode on the network. So in order to mine blocks, I have to have my a certain balance associated with my public key that I'm mining to, or some concept similar to that. It would create demand for Dash. Obviously there's value in being able to mine Dash, and so it would create some some form of demand to hold Dash. I think that the downside to it, or the obvious fault, is it's difficult to predict how miners would react, how much they would hold. In a similar fashion to when you launched masternodes - what kind of ROI would they demand? So it would create demand for Dash, but it would cause unpredictability in our future flows. And that could cause spikes or troughs in the future circulating supply of Dash, and that would introduce risks... So that hopefully paints one of reasons why we eliminated that from consideration. Given that there was a much simpler solution here that was far more predictable in terms of how it would play out, we chose the the lower risk approach.

There's another reason too, which is collateralized mining would be a significant undertaking as well. It would take quite a bit of time to to implement, and we'd rather go with a solution that can be implemented very quickly without a lot of resources. But I'd say the primary one is it would be really tough to predict what kind of an effect it would have. We don't know whether it would even solve the problem and, if so, would it overshoot the problem...?
Q: How do we know we have enough X11 hash rate after this?

A: I think there's several ways that you can measure whether or not you've got enough. There's the NiceHash-able rate: this is the capacity that's currently available for rent versus the hash rate on the network. You can also measure it as the percent of X11 hash rate that Dash has across all coins. You could look at the allocation towards miners per unit of time and convert that into US dollars to say how much value are we allocating to miners. So I think there's a lot of different ways you can measure it. I kind of likened it to the Supreme Court's ruling on what is obscenity, and the answer is I know it when I see it. I think that there's a lot of different ways to view security, and I think that you start to recognize it as it's as you're approaching that threshold that the network appears to be less secure than you'd like. An example of this was the beginning of 2019 when we saw a NiceHashable rate where you could 110% NiceHash the network for a few thousand dollars. That was obviously unacceptable, and that's one of the reasons we pursued ChainLocks. I think it's difficult to answer this, especially since it's shades of gray and it's multi-dimensional. I think the answer is we don't want to come close to the edge, we don't want to minimize our mining expenses. That's not the objective here. You don't want to run right up along that cliff's edge. You want to be well away from it. Will we be overspending on on mining, more than we absolutely need to in order to secure the network? You bet, but that's by design. You have to be well away from that cliff's edge.
Q: How will DCG react accountability-wise in order to restore any damage from the trust between the network and DCG if we're wrong?

A: We put a lot of effort into setting up a structure where the network has the ability to judge DCG's performance as a whole. Like any other organization, we have our successes and failures. If this does not achieve the intended goals and is viewed as a failure by the network, I believe the network would lump that effort along with many other efforts into assessing whether or not DCG is doing a good job. If we're not, the mechanisms are in place to facilitate change. That change can come in a number of different ways: it could be pressuring the trust protectors to take action, or electing trust protectors that have campaigned on a specific vision for DCG. They can change the mandate of what DCG is intended to do, they can change the scope of activities that we pursue, they can change management, change our board, fire me, any number of actions. So I don't think there's anything specific to this proposal that needs to be put in place accountability-wise, because I think there's a high degree of accountability there already. And it's there for a reason: it's there for big decisions like this one. I want to be clear: we're deferring to the network on this. We're presenting a case. If we end up misleading the network in some way, presenting a case that proves to be untrue, I think it would certainly damage the reputation of DCG and myself, and I would hope that the network would take action if that were the case and push for change, maybe reverse the decision... things of that nature.

strophy · Jun 13, 2020

Zoom AMA, continued...

Q: Will Dash's total coin supply emission rate always be kept exactly the way it is currently predicted/expected to be? Is there a way for masternodes to guarantee or promise never to manipulate it in the future? Does someone investing in Dash not have to worry that coin supply won't someday be manipulated by the masternodes who control it?

A: Coin supply in Dash, just like any other cryptocurrency network like Bitcoin, is dictated by consensus. So no network can ever guarantee that there will never be a change in the supply, and that includes Bitcoin. If for exam Bitcoin's network security was beginning to risk security compromise because the block subsidy was gone and fees were insufficient, it's conceivable that the network could determine through consensus that a block reward is needed on an ongoing basis in order to maintain the value of the network. So I can only say that we don't have an intention to change the total supply. But it's also not in DCG's control. I do think that it is conceivable that this could happen in the future. I think Bitcoin would face the problem I described first, where network fees may be insufficient to secure a network on its own and a small amount of inflation is acceptable to the network. What I do know is masternodes would be heavily disincentivized from running wild with a concept like that, even if it were necessary to put some inflation in place that exceeded the current goals, if they were to put inflation that was high, people would sell their Dash. Remember masternode owners are large holders of Dash - they would not want to destroy value. (Darren Tapp said that Dogecoin already had this happen.)

I think it's certainly possible. I don't think that Dash is likely to face this first, because we have the equivalent of a having every 10 years, whereas Litecoin, Bitcoin and Bitcoin Cash all have a halving every four years. So they're on a path that reaches the point of whether or not that's necessary about two and a half times faster than we do. So it certainly won't be Dash that is the first that might be required to change that. What I do know is that a small block subsidy is probably all that would ever be necessary to secure the network. I mean these are hypothetical things, and honestly these have nothing to do with the changes that we're proposing here. We're simply talking about the reward allocation itself, not whether or not the total supply should change.
Q: After making the proposed changes, do you expect the network to modify Dash's block reward structure again soon? How frequently? Could the power masternodes have to make frequent changes be seen as giving uncertainty to people considering investing in Dash as a store of value? Should future changes like this maybe require a higher threshold of masternode votes than 50%?

A: There's a lot of questions here, so I'll start with the philosophy around whether or not this creates uncertainty. If I'm an investor in Dash, I think one of the things that I find attractive about the network is the fact that Dash can more easily adjust to market conditions. I think that that's valuable. I think the fact that we have a governance system that allows us to have this decision within a short period of time allows us to be nimble. Do I expect the network to modify our block reward structure again soon? If this works as intended, I don't think that this would be a frequent event. Remember the last time we had any reward structure change was 2015, so it's been five years since our last change. I would expect a similar timeframe to pass before we would consider doing another change, and it would need to be driven by a need. We're not just changing things willy-nilly for the sake of changing them. We're changing them because of a demonstrated need in order to address an issue that's been facing the network for the last couple of years.

I think there's a case to be made to investors along the lines of: hey, look, Dash is actually very flexible and that flexibility allows us to change and react to market conditions in a way that's going to add value to the network. That seems like a positive thing to me. Whether or not future changes should require a higher threshold than 50%, I'd point out that it does require more than 50% of the voters that cast votes in order for a proposal to pass. In fact, you need a net 10% and so if every masternode voted, something like 55% would need to vote yes and 45% no. That's kind of your worst-case scenario in terms of a ratio of support, it has to be at least 55%. In reality not everyone votes, and so the percentage of votes that have to be yes is much much higher than 50% and so I feel like it's already a really high threshold in order to get a proposal passed. It has to be widely supported by the network. I don't think you need a higher threshold than that, and this is not the only form of consensus. If we code it up and there's a silent majority who didn't vote but don't support it and don't download the version that we put out that incorporates this change, then the change won't be adopted by the network. So we're subject to all of Bitcoin's consensus requirements in addition to our governance system's requirements in order for something to to get adopted by the network. So I feel like there's adequate protections in place against an unwanted or undesirable change to the network. And I feel like incentives are aligned on the part of masternode owners, because they are large holders of Dash. They're unlikely to approve something that's bad for users. So I don't feel like it would be necessary to change or create a special proposal type for decision proposals.
Q: If the fee proposal passes for the future changes instead of doing it due to hard forks we can implement a new spork to adjust the fee?

A: So to be clear on fees, we're not planning on putting forward a proposal for that one. What we're planning on doing is, just as we have in the past, periodically changing the default for minimum fee on the network. What this does is it changes the threshold at which nodes will relay messages. So if I send a transaction today that doesn't meet the minimum fee requirement, it will be passed to the nodes that I'm connected to. All of the nodes (unless they've changed their fee requirement in their configuration file) if they haven't changed the fee then the transaction is not going to relayed across the network. It will never reach a miner, and it will never get mined into a block. It will expire before it does. So there's nothing actually stopping a miner from including zero fee transactions as an example, and that's true of Bitcoin too. It doesn't invalidate the block. But that minimum fee is a default that all the miners have within their wallets presumably, as well as all the nodes on the network for relaying.

If you change that minimum fee, it can help (especially if a high percentage of the masternodes leave their default fee unchanged) with ensuring that people are incentivized to pay a higher fee. Lowering fees is a lot easier than raising them. When you raise fees, you can have some older versions of the software on the network that aren't aware that there's a higher fee on the network and can try to send transactions that other nodes won't relay. That can create a bad user experience, so what we're planning on is firstly that these will be infrequent. We'll just do them when there's a major release and readjust the fees, just as we did in the past when the price was going up. In cases when we're wanting to raise the fees, because the price of Dash has fallen, we will coincide that with times when we're doing a hard fork anyway. That way we're not creating this bad user experience for people that are on older versions that are nonetheless still valid versions. It'll only be when there's a breaking change that we're doing anyway for other purposes that we'll incorporate a fee increase to the minimum. So that will avoid some disruption to the users that might be on an older version or using a third party wallet that hasn't been updated with the current fee structure. Hopefully that that answers the question.

By the way, we're retiring sporks more than we're introducing them. For example, version 0.16 just went to testnet this morning. (I don't know if that's been announced yet, but it may be announced within an hour and there's already nodes on testnet that are operating.) But in version 0.16 we're retiring three sporks. We're introducing one new one, but it's for a new flag that's required. But we're aiming to retire more and more of those with each release. Sporks are kind of something we'd like to avoid for something like that. Remember sporks really wouldn't be measured by third party wallets. Multicurrency wallets, for example, probably would not support sporks. So it's something that we'll try to do in a very smart way.
Q: What do you think about the idea of fixing the mining reward allocation, and leaving the flexible treasury to only cut out of the MN-reward portion, in order to have a stronger incentive for MNOs to vote optimally?

A: Oftentimes people ask that question without an argument as to what the rationale for that would be. The main rationale seems to be (for most people) providing certainty to miners. I am personally opposed to the idea for a few different reasons. One is it places the entire burden of funding a proposal on to a subset of the network, the masternodes. If they are the only ones contributing, and yet many others are benefiting, that can create misaligned incentives. And it can increase the burden of passing a proposal, because it has to deliver value enough value back to the masternodes subset in order for it to be deemed worthwhile. Now presumably proposals are only passing that add value to Dash. That's the job of the masternodes, is to evaluate those and decide whether or not the expense is less than the value that's going to be delivered to the network, and also assessing the probability of success and failure and those types of things.

And certainly not every proposal achieves the intended goals. Some of them are not successful. Hopefully over time there are more good ones than bad ones. If you in addition require the full funding costs to be borne by the masternodes, I think it makes it more difficult for those good proposals to pass. Miners should in theory benefit from the proposal system as well. If a good proposal comes along, the masternodes fund it and it adds value to Dash in some capacity, that should add to the value of the Dash that those miners are going to be mining over the next couple of years. So asking them to participate helps to spread the cost a bit further across the network participants, and makes it easier for good proposals to get over the line. This is similar in concept to the reason why we have this system in the first place versus a donation based one. Coins like Litecoin are dependent on large benefactors (or whales) to donate to development efforts, or business development, or what have you. That's hardly efficient. A particular activity has to deliver a hell of a lot of value before a whale will get his or her money back. If it costs a hundred thousand dollars, it has at $100,000 worth to their portfolio. Of course, there's tons of coattail riders in a solution like that. So I think by including the miners, you're avoiding part of the coattail riding problem, and I think that it's a more efficient system overall. I also don't think providing miners more certainty and masternode owners less certainty is a net benefit. Miners already incur a great deal of uncertainty over their future earnings just from the price of Dash alone. I'm not sure that providing them certainty over the number of Dash that they're going to get adds all that much incremental value to miners. So personally I think the advantages of a more efficient alignment of incentives is stronger than the certainty that it provides to the miners. Remember if masternodes don't have certainty over their ROI, it may cause a drop-off in the number of masternodes, and that could be catastrophic, obviously. If a lot of proposals were constantly passing, and a lot of masternode owners that are simply there for passive income were to see their rewards drop significantly, we could see a flood of Dash onto the market, and that seems dangerous and and irresponsible to me. There's just a lot of reasons why I would support something like that and including miners in the proposal funding was very intentional.

strophy · Jun 13, 2020

Zoom AMA, continued...

Q: We got some feedback that there shouldn't be a cap. I also got feedback that the 20% cap is too high - maybe 15% or 12% to start and see how it goes. Thoughts?

A: So I've heard a wide range of opinions on the cap, and it seems to me like I've heard more often that people would like no cap than a smaller cap than the one that I proposed. I think the fact that I'm getting feedback on both sides probably means that you know I'm probably at least decently towards the middle of the range in terms of what people want to see out of that. So I think it's a good compromise. I am wary myself of a no cap on the proposals, simply because I think that the miners should share in the proposal system.

It's really a 2x2 matrix of decisions that you've got here. On the x-axis, you've got: do miners participate in the proposal system? When a proposals awarded, tdo their rewards change, yes or no? And then on the y-axis of this 2x2, you have the question should there be a cap or not, yes or no? And you really have to choose between those two. You can't have a system in which there is no cap and miners participate, because your mining could in theory go to zero. It's okay if my masternode rewards go to zero for a month. It's not okay if mining rewards go to zero for a month, everyone would just shut off their machines. I think that you can't have that combination. You also can't have the combination in which miners do not participate. You basically have to choose between those two things. I believe that it's more important to have an alignment of incentives than to have no cap at all. I cannot see a scenario in which the masternodes want to approve 100% of the rewards anyway. I think that would be irresponsible and dangerous, I think that it could lead to a large number of masternodes liquidating out of anger or out of the belief that they're never going to get rewards or something. I think that's fundamentally unstable.

OK, so there's some feedback on the cap: "I like the 20 percent cap" (quoting response in Zoom chat, not Ryan's words). I do like the fact that there is a trade-off here of approving a proposal. Masternodes are participating in the funding of it, and therefore it really does put additional scrutiny on proposals to say, hey, is this truly valuable? Am I willing to give up one Dash over the next month or something for my masternodes in order to fund this? And so creating that trade-off ensures that people aren't going to go crazy with this. Even in the current scenario we don't use all of the budget all the time, so I don't see a scenario where they're just gonna max out the cap. But I still think that a cap is a good thing to have. It preserves at least some base level of security to miners and masternodes over their future income.
Q: Would it not be possible to envisage a reduction in the percentage allocated to the budget from 10% to 2% or even 1% over time in order to give a signal to investors that Dash is becoming more professional and optimizing its spending, as in other economic activities?

A: The answer is yes it's absolutely possible. Would I be an advocate of lowering it to 1%? No, not today. If we were Bitcoin's size, that might be feasible. But not in today's scenario. I think that 1% of the block reward would be around 500 Dash. I think that'd be around $40,000. That'd be enough to support a handful of people working for the coin. I don't think that that's sufficient. We're certainly at the stage of our growth where we're investing in the future. If we were to reach a large market cap like Bitcoin has today, it might be feasible to run the network off 1%. But I wouldn't be an advocate of doing that today. If we find ourselves the size of the US dollar 20 years from now, that would be more than conceivable. I think the power of the network is the ability to change. The fact that we're proposing a change now, and that we've made changes back in 2014-2015, I anticipate that there'll be more changes in the future. If, in the future, an allocation like the one that Jol proposed there is feasible and would be in the best interest of the network - then great!

Well, hopefully that answered some questions for you or gave you greater insight into some of the rationale. I'd love to hear comments like: do you like it? Are you skeptical but supportive? Any feedback at all would be appreciated. I'm just trying to gauge where we're at as a community on this and and how ready we are to move to a vote at any point in time. Obviously we have these events through at least Sunday, and so far it seems like there's widespread support.

strophy · Jun 13, 2020

Dash Chat Telegram, 2020-06-12 21:00 UTC

Q: Will DCG continue asking for 60% of the budget and thus double their ask if the change passes?

A: No, we don't intend to maintain our ask of 60% of the budget. There has been some concern that this could become a land grab for DCG or other teams. If DCG were to increase our ask above what it is today, it would be submitted through a separate proposal (just as we have done in the past whenever we've asked for funds that exceed the 5% ask for compensation). Right now, 6% of the budget covers our full costs, so unless the price fell, I wouldn't anticipate asking for more than ~ that amount. The really healthy dynamic we're hoping this change creates as well is that the bar will increase for proposal owners. Since there will be a real trade-off that MNOs will need to make (by approving proposals they affect their own income) it should help ensure that proposals need to provide real value before they can gain approval.
Q: Just thinking out loud, but maybe you should ask for more than 60%. You guys have a better track record than any other PO for delivering and you're working on a shoestring budget. I think getting some more people to help get Evo and other updates out the door may provide a greater benefit to the network than scaling back your ask so other less proven teams can get funding. Again, just thinking out loud.

A: Remember that even 35% of the expanded max budget would be more resources than DCG consumes today. I wouldn't draw 60% if for no other reason that we would not be able to efficiently grow the team that quickly. If we do expand DCG, there would need to be good rationale for doing so, a plan for expansion, and a transition. One of the things I think we did poorly in 2017 was expand the team too quickly. That led to inefficiency as newer resources didn't get the level of support needed from management (we were spread too thin). So I think we will start out with observing the dynamics of the new proposal system, and if we have a good case for expanding the team we'll make that case to the MNOs through a separate funding proposal.

But I really appreciate the kind words. We keep learning and doing better and better as an organization. I just don't want to expand simply because it's possible. We need to ensure the resources are well used, and that the network can sustain that higher spend rate (because later letting people go can be incredibly wasteful and disruptive to the team).

Next bull run, I'd like to build reserves before increasing the run-rate, rather than the other way around. And this time we can safely do that because the trust and other legal / financial infrastructure is operational and nobody could run off with funds. Those reserves are there for the network regardless of who operates DCG in the future.
Q: Why change mn/miner ratio 9% and not 10%, it is some number that popped out at the end of some calculation? or does 9% just sound less than 10%?

A: It's actually moving from 50/50 MNO / miner to 60/40% of the block reward by default. It just so happens that currently we have 10% of the block subsidy reserved for the proposal system. So 10% of 90% is 9%. However, we're also (separately) proposing to allow the proposal portion to flex anywhere from 0% to 20%. So the 9% simply assumes the current allocation and is a function of that.

One concern has been that the current system is easy to describe, and maybe this more sophisticated model is tougher to describe. But I actually think it's quite easy...

"Up to 20% of the block reward can go to proposals subject to MNO approval. The remaining funds are split 60% / 40% between MNs and miners." So I think the fears about being able to describe the system succinctly are overblown. The above description is very easy to grasp, in my opinion.
Q: What is the rationale behind taking the proposal reward from both masternodes and miners instead of just from the masternodes. If the idea was to make the decision makers feel it why also take from the miners share? The current system takes from all participants: miners, mnos and regular holders equally via inflation.

A: This question has come up many times. Similar to "altruism" in which whales are asked to pay for development in other networks, it makes it harder for good efforts to get funding if only one of many are asked to fund everything. You have a "coat tail riding" problem. If a proposal is a good one and delivers more value than it costs, it benefits everyone if that proposal is approved. However, if you ask only MNOs to fund it, an otherwise beneficial proposal could be passed over. If a proposal is truly valuable, it should raise the value of Dash being mined by the miners. So no reason they can't participate... it better aligns incentives between those that benefit from proposals.

I'd also point out that it reduces variability in MNO income. This helps buffer a situation in which passive investors that are here for the ROI abandon MN investments because of too much budget being approved. Miners accept a huge amount of risk when purchasing mining equipment. The price of Dash can change dramatically over the course of the life of the equipment. So a small variation in rewards from month to month is acceptable (its actually likely to be much less variation than they already experience from price from one month to the next).

The main benefit is that there is better alignment of incentives though. It ensures the benefits of proposals go to everyone and the costs are spread as widely as possible.

Q: I run a masternode but at this prices the reward in $ is small, any plans or solutions to grow the price? Can you guys control that? Or do anything about it?

A: While this proposal doesn't specifically target a price increase, the changes (independent of other contributors to price) should be accretive because it would incentivize the creation or retention of MN operators. More masternodes requires collateral, so it should generate demand. It would also shift payments from miners (which tend to have low margins and must liquidate earnings) to MNs (which have high margins and aren't forced to liquidate to pay operating costs). So generally, I would expect this set of changes to benefit price.
Q: Not a question but I would argue that the current system already "ensures the benefits of proposals go to everyone and the costs are spread as widely as possible." It doesnt seem broken to me, I believe mnos learned from the past bad/waste props during the bullrun and that learning needed to take place. I feel like this is fixing something that isnt broken (strictly talking about the part where the proposal budget comes from: inflation vs mno/miner reward)

A: The primary aim was to provide greater flexibility over how much funding could be spent. And if we're touching that system, we might as well design it in an optimal way. I do agree that the MNOs that were around back in early 2018 learned some valuable lessons and likely wouldn't react the same way today. However, I do feel they would likely have kept some teams in December 2019 that were defunded, and the current system wouldn't allow them that decision. So the primary aim here is flexibility. The other design choices were further optimizations.
Q: Has a hybrid system been considered were the first 10% come from inflation and the second 10% from miner/mno rewards?

A: Yes. It hasn't garnered much support, though. People tend to think that one is better than the other, so "splitting the difference" tends to lose the support of both groups. It's also yet another complication that raises the barriers for newcomers to understand.
Q: What about setting the reward to 20%, but operate it exactly like we do today?

A: That is certainly possible. It has the same pros and cons as our existing system. One growing con is that it throws into doubt what the final supply of Dash will eventually be. We already suffer from an inablity to say with certainty, and this would expand the range of possible outcomes further.
Q: It seems unnecessary to burn the 5 Dash proposal fees. Can’t these be directed to MNs and Miners? Or simply MNs since they are the evaluators?

A: It's possible, yes. There was some rationale for burning the Dash rather than submitting a fee, but that decision pre-dated my involvement and I don't recall the rationale. I personally think that should be explored. It would be a nice "bonus" to get a huge fee block for MNOs and miners every once in a great while! It's actually in our backlog to evaluate that... just a lower priority backlog item.

Thank you everyone for the great questions and feedback. I hope I was able to clarify a few details about the proposed changes for anyone watching. The feedback on leaving the system similar to today (or even a hybrid) is feedback we haven't received in any other session, but I've noted it and we'll test that with other groups.

strophy · Jun 13, 2020

Call announcement post: https://www.dash.org/forum/threads/dash-economics-discussion-series.50278/

Schedule:

Wed 6/10 11pm UTC: Discord Dash Nation (#dash-talk channel)
Thurs 6/11 3pm UTC: Zoom Webinar
Fri 6/12 9pm UTC: Telegram
Sat 6/13 5pm UTC: Zoom Webinar
Sun 6/14 8pm UTC: Discord Dash Talk (#ryan-questions channel)

For anyone unable to attend these discussions live that would like their input heard, please submit your questions/comments via this form: https://forms.gle/U7LcWH6KxY6Np2M77.

strophy · Jun 15, 2020

Dash Talk Discord, 2020-06-1420:00 UTC

Q: Do you anticipate the continuation of further incremental reallocation from miners to masternodes beyond the proposed 5 year period?

A: We don't have any plans for additional reallocations. Given the delicacies of changing network economics, this is not something we anticipate needing to change often. Each change carries risks, so we aim to be cautious. The last changes to the allocations occurred in 2015, so it's been five years since the last change.
Q: Is there any data to support that supply expansion isn't priced in?

A: I am not aware of any data that supports the assertion that supply expansion is already priced in. This is notoriously difficult to prove without a time machine as evidenced by Bitcoin's past halving events and debate surrounding the current halving. I suspect that most people - prior to my presentation in December - had carefully considered Dash's unique economic model and the implications of it. Without that awareness, I doubt the market is capable of fully pricing in dynamics most don't analyze or understand. The historical data, including the price spikes Dash experienced in past reallocations, suggest that the network prices in this type of information quite poorly.
Q: If you could please summarise the major problem in speeding up the new reward allocations from 5 ½ years to say 3 years?

A: Yes, if you reallocation too quickly (for example by doing the full reallocation all at once) you can "overshoot" your target of slowing the growth of circulating supply and actually cause it to contract temporarily. The result is an actually smaller base of circulating supply than you have even today. With a smaller base (e.g., numerator) and the same emission of new coins, the growth RATE in circulating supply actually increases in future periods. It's a bit counter-intuitive, but the aim with the reallocation we are proposing would smooth the transition, allowing the circulating supply to continue growing, just at a slower pace than we have today.
Q: Granting that it's impossible to know in advance how strong the community consensus will be on this proposal, but assuming that MNOs are on board with this change with minimal tweaking, how quickly could this change go through the pre-proposal, proposal, implementation & testing, and deployment? (How soon from now until we could see the first hardforked block from the gradual transition?)

A: There are two separate proposals we will post to the network. The first is for the reallocation of the MNO / miner split. The second would change how the proposal system works. The first proposal can be implemented rather quickly (probably through a minor release), perhaps by the fall. The vote and adoption of the software by the network would actually take the most time. The coding itself is pretty minor.

The second proposal will take longer and if it gets approved, we'll go through a formal scoping of the work and get a better idea within the next few months. That's probably a 3-6 month effort would be my best guess at this point in time.
Q: Would you consider splitting the proposals into separate ones to disambiguate the voting, eg Proposal 1: For the Miner/MN reward re-allocation. Proposal 2: For increasing the funding cap on the DAO. Proposal 3: For increasing the network fees. etc.?

A: This is already the plan. However, we don't intend to hold a vote for the network fee adjustment. This is simply a default setting on each node and can be changed by the operators. We have retargeted default minimum fees in the past and plan to continue doing so. Operators are already free to change those settings.
Q: Aside from the perceived political cost, are there any other downsides of changing the coin emission rate (inflation) to match that of the Judas BTC?

A: Yes, if cut substantially, the reduced reward reduction for MNOs could risk a rapid decrease in the number of MNOs, which would flood the market with new coins from MN collateral. So there are real risks from an approach that actually changes the emission rate unless it were extremely gradual (like we have with the 7.1% annual reduction).
Q: Do you think the community sees total coin supply reduction as a very drastic/undesirable option? This is already a possibility in Dash when the treasury is not fully allocated, and it harms nobody in the network, right?

A: The bulk of the coins currently are allocated to MNs and miners. I agree that changing the supply slightly is feasible, it's most difficult to decrease the portion that goes toward MNs due to the downstream consequences of that. We identified a solution that minimizes the number of changes to the network precisely because we want to avoid unforeseen risks. The primary goal here is to reduce the growth rate in circulating supply, so if we can do that without changing the emission, with predictable results, I think that is a huge benefit.
Q: What threshold will you set for these proposals? I think you'd mentioned 60%?

A: Decision proposals carry the same threshold of net 10% yes. This requires a supermajority to vote in favor. If 50% of MNOs vote, it would require 60% of them to vote yes. For most votes, less than 50% of the MNOs vote, though. So more than likely, it will take about 70% of those that are voting to vote yes.
I'm doing my best to sense what the MNOs / community want. From what I've experienced, the vast majority really like what was proposed and are interested in moving quickly. In fact, this is the first suggestion during any of the Q&As that we might want to proceed with surveys. There are a couple of details that I've seen the most disagreement on that might warrant further investigation. Some people have asked for no cap on the proposal portion while others have called for a cap less than 10%. The vast majority are somewhere in the middle from my observation. The other is on whether the miners should have a fixed allocation, but most have agreed with my rationale for having them participate and change their minds once I explain. Honestly, I'm seeing a great deal of support that gives me personally the confidence that the best thing for the community is to move forward relatively quickly to a formal vote. However, I'll be getting input from the entire management team regarding that decision before we would finalize it. I'm curious from everyone in attendance here... would you prefer to see us move more quickly to a vote, or should we move slowly and engage in polls on specific aspects of the proposals?
Q: Under the new plan, the "unallocated" Dash that were not created from previous budget cycles, will stay that way (not be recouped?)

A: That would likely be highly controversial, even within our community, with limited benefit. I think more important to focus on optimizing the process going forward.
Q: Is there concern that enticing new MNOs via a perceived higher MN ROI will radically change the MNO makeup with people who perhaps will sacrifice long term goal oriented thinking with short-term profit making motives?

A: The fundamentals of owning / operating a MN are not changing with this plan, so if that were the case, I think that behavior would have already developed. As MNs must first own a lot of dash, I think their incentives are well aligned to encourage them to invest in the future.
Q: How can you sense with 4000 MNOs want? Are these AMAs exclusive to MNOs and is a large fraction of them represented?

A: Normally, I would say it can be tough. However, in this case there has been very little opposition. If there were even a minority but substantial portion of the MNs that opposed the plan, that would be evident. I'm just not seeing that position represented.
Q: I don't think tweaks should be made. I think using the number of MNOs as an economic tool is a fundamental flaw. Number of MNOs should be dictated by what the network technically needs.

A: This proposal would not dramatically change the numbers and remains well within the range of technical needs. In other words, it wouldn't affect network performance in any meaningful way (unlike proposals such as cutting the collateral requirement to a much smaller number). This was a consideration in our decision making.

strophy · Jun 15, 2020

Dash Talk Discord AMA, continued...

Q: Did you come up with an answer regarding the change fees (including mixing fees) that was asked in the video call 2 weeks ago? I'm asking because I fear putting fees up could disincentivise people that mix regularly even further than the slow process already does.

A: The current fees are nice round number and are meant to cover several rounds. I did a back of the envelope calculation on them and they do cover the costs of data they generate. So the fee change would likely only apply to regular transactions and a bump likely isn't needed to the PS fees. If there is a change, it would be minor.
Q: What about my point that number of MNs shouldn't be an economic tool but determined by what is technically needed by the network? What about my point that having more MNs than necessary is waste? What about my point that no longer running a MN doesn't mean selling your DASH?

A: What is technically needed by the network is a wide range of acceptable number. I think the incentives on the network are economic tools already. People aren't operating MNs purely out of altruism. So they already are economic incentives at work. We have analyzed how those incentives drive behavior and have determined a simple solution to an identified issue. So I don't agree. MN creation and / or retention can solve an economic issue, and we can and should leverage that for the benefit of the network, absent a better solution.

Concerning your assertion that MNOs would not sell at least a portion of their Dash, this seems unlikely. Given it costs about $10 a month to operate a MN, the only way a person with 1,000 dash would NOT want to operate a MN is precisely because they are selling and find the rewards vs capital tied up no longer worthwhile. By incentivizing the retention of MNOs we prevent that from happening for a good number of them and slow the growth rate of circulating supply.
Q: Why are pure proof of stake projects so poor as a store of value ? Why will it be different for dash?

A: Dash will remain PoW. Concerning PoS, I think there are too few data points. You could argue that Bitcoin and Ethereum are the only two projects that have reached near certainty of future survival. Two data points is insufficient to say a PoS asset can also become one. Regardless, it's not a relevant comparison for Dash.
Q: If 2000 is ideal, we could dynamically adjust inflation to target 2000 and limit inflation to reduce downward price pressure.

A: There is no mathematically provable "ideal". Rather there are trade-offs. The trade-offs are not linear either and vary over time. "Too few" and the network becomes less secure (which also depends on Dash's price). "Too many" and network performance may slow, BUT performance is a logarithmic function of the number of full nodes (which includes MNs, but also regular full nodes) not linear, so the performance loss is less than the growth. The bottom line is that targeting a specific number isn't realistic. We're targeting a "reasonable range" which we have today and which is maintained with this proposal.
Q: By increasing the reward you only incentivice the running of MN by people who already hold DASH. People who don't want to hold DASH anymore because of price reduction caused by inflation aren't going to hold on to their MN by creating even more inflation.

A: The data suggests otherwise. Increasing incentives for MN operation increasing the number of MNs. And it's very logical that this would be the case.
Q: i dont believe this argument about inflation of the circulating supply. there are too many guesses about which demographics are doing what. we dont know who buys and sells. we cant know

A: The analyses and model don't incorporate assumptions about who sells and who doesn't. Dash sitting in an MN address but not collateralizing a node is still considered "circulating supply" in our models. That said, I agree that rewards granted to a MN are less likely forced to sell (and therefore less likely to be liquidated) than rewards granted to miners.

Regardless, there is no dependency on this in any of the analyses presented on the MNs that are operating in response to the ROI of operating them.
Q: For me personally there is also the psychological unfairness of not benefiting from the inflation if you don't have 1000 DASH. The bigger the miner reward, the less likely I'd be to want to continue to hold DASH if I don't have a MNO. It would be better for price if more people were willing to hold 1 or 10 or 100 DASH without being forced to hold it on an exchange or trusted service.

A: Yes, and for the reasons you point out, I felt the same way, and included them in the range of potential solutions. We identified many risks with this approach that are not easy to solve from a security standpoint (e.g., shared MNs). Given we identified a lower risk and more predictable path with the moderate reallocation, we felt like the lower risk approach makes sense. I hear you on the benefits of that approach though, and they weren't missed.
Q: This path of altering rewards and who gets what does not end well. Tinkering like this. investors dont like it. i went down this route with another crypto investment

A: One of the reasons that the changes are gradual and relatively "contained" is precisely because we wanted to avoid significant risks. It's also the reason we didn't tinker with aspects we would have difficulty understanding the likely range of responses. We have solid historical behavior with MNs that are consistent over time. I agree that tinkering with economics carries risks. I certainly didn't take it lightly and only proposed changes because I feel that the risk of doing nothing is greater.
Q: Should core group be the ones to make or change economics of dash? Should masternode owners have the power to vote more for themselves and less for others? will rival coins think this is scammy?

A: I don't think DCG should. That is precisely why this set of changes needs to be voted upon before we would implement such a fundamental change into the code. I think rival coins will always find issues that they can critique, but I wouldn't hesitate to do what is right for Dash simply because of that.
Q: what about MNO voting more for themselves and less for others? No potential problems with that ? they will vote in interest of everyone (except perhaps miners) not thinking only of their own balance?

A: By design, they need to vote for everyone, because they need to maintain an attractive network for their collateral to maintain its value. For example, what stops them from voting on $10 transaction fees? No one would use Dash. What stops them from taking all the miner rewards? The network would lack security and the coin would lose value. I think they have a lot of incentives to do what is best for the network, and they were designed to be that way.
Q: yes i appreciate your engaging with the community Ryan. I remain against your proposal. I think it is risky and a real chance will make things worse. i'd rather we spent more dash on as high hash rate as we can. However i realise i am almost alone in this. Good luck with it if it goes ahead. I doubt i'll be invested to the degree i am now though

A: I appreciate the honest feedback. Honest feedback is necessary for us to gauge if we are heading in the right direction, so dissent is important. I knew at the outset that there was 0% chance everyone would agree with me, so it was something I didn't take on lightly.

Pretty much everyone has positive intentions in this process. Has been really positive engagement throughout the process. People have argued on the basis of logic and beliefs, without resorting to uglier styles of engagement. I really appreciate the Dash community when it comes to debate. One of the things I like most about Dash.

Well, I may have missed some, but I think I've answered most everything, and we just hit the two hour mark. I also see the pace of questions has slowed / stopped. So I think we'll call it a day here. Thank you everyone for questions and feedback. We'll work on next steps since this is the final AMA. Look for more communication in the coming days. Thanks again!

strophy · Jun 16, 2020

Zoom AMA, 2020-06-11 15:00 UTC
Recording password: 8z^bY?T+

Q: (General explanation of new reward allocation economics)

A: The proposal portion can fluctuate depending on what gets approved in a given month. It creates a range from the other two parties that it could could be, so the range for the proposal system itself would be from 0% (if nothing got approved) to 20% (if the maximum were used up to the cap). If the remainder is split 60/40, that means that for masternodes the range would be 48% to 60%, depending on how large that proposal share was. For the miners, it would range from 32% to 40%. Now in reality, it isn't going to swing that... well I don't think it's very likely that we're going to have a budget cycle with 0% allocated in it. I also think it's extremely unlikely that the masternodes would approve 20% of the funding, not the least of which is getting exactly 20% would require engineering the amounts and knowing ahead of time which proposals would fit. So in reality, the range is much narrower than that, that they would expect to receive. If the current 10% were allocated in a given month, that would reduce the miner and masternode shares by 10% as well. In the case that a 10% budget allocation were approved, that would mean 54% to the masternodes and 36% to the miners. So that's kind of the number that I would target, and it would probably range on either side of that by a little bit in a given month.

If 20% of the treasury were used, their masternode rewards would drop by 20%. Miners would see a 20% reduction in theirs as well. So think of it like you take 60% and multiply it by the remainder. So in the case that 20% were allocated, that means 80% would remain. 60% of 80% is 54%, so that's the math.

Q: The very simple description that one of the concerns that people have is (a) how are you going to describe this in simplistic form? Simplicity is important!

A: I agree! I think the way I would describe it is the default split is 60/40 between masternodes and miners, and any proposal funding proportionally reduces that. So that's the very simple description that I would provide.
Q: Would you mind actually going through the driver behind the proposal and the changes that you're proposing briefly?

A: There are a couple of presentations, the first of which was our open house back in December. I gave a presentation entitled "Improving Dash as a Store of Value". It goes through a number of different unique attributes of Dash's economics that I hypothesized were driving higher market volatility for Dash than many of the competing coins in the market. I propose that we develop a solution to that issue. (I would encourage you to go back and watch that video, you can watch it at 1.25 speed on YouTube and just accelerate through it. Its about an hour long presentation, and so you can get through it in probably 50 minutes or so, and that would go into deal of detail on it.)

But at a very high level, it's that our circulating supply, the supply that isn't contained within masternodes, has been growing at a very rapid rate last two years. It's because the rate of masternode growth has stagnated and in fact it started to reverse a little bit. And that means that our growth rate in practice is much higher than the overall growth in total supply, and that puts downward pressure on price. It's not a long-term issue, it will eventually go away, but it won't go away for quite a few years. So this is a proposal that... I've described it as "flattening the curve" because we're going through Covid right now, and people seem to understand that concept. We're incentivizing the creation of masternodes by doing a small reallocation. It's also a recognition that ChainLocks has made our network more secure with less hash rate, and so we're capturing some of the value of that through this process as well. So that's some of the rationale behind it. There's a lot rationale that went into how we're doing the reallocation, and at what pace what we're trying to do is basically manage that growth rate in circulating supply for the next few years.

Q: Is there any anything that's stopping you from continuing to go in the same direction with these numbers? Meaning higher to the treasury, lower to the miners, maybe lower or the same for the masternodes? Is there anything stopping that from happening over time, is that part of the game plan or is is this the long term goal right here.

A: This would be a long-term goal. This is a multi-year transition period. I think that we would always be open to changes in the future. One of the beauties of our governance system is that we have the ability to vote on these things and make decisions. If we notice that there's an issue, like we have in this case, we have the ability to propose changes to the network in order to accommodate that. One of the things that we wanted to explore was proof of stake. Ultimately a lot of major projects have have attempted to move in this direction. Ethereum actually got as close as having a proof of stake version on testnet and had to reverse because of security vulnerabilities that were found. So we looked at that and said "you know, we don't think proof of stake is quite there yet". I think there's still security concerns to which answers are not yet known. It's not as well proven as proof of work, and so we thought that was an extreme direction to take things. As we learned more about our economics through the research that we did, we found out something extreme isn't actually needed. We can actually solve the majority of the challenges here with a relatively modest reallocation, and so when we found that out... this was kind of the lower risk route, for sure. But if technology changes in the future, maybe we would want to consider proof of stake, if we if we think that it's sufficiently secure. Maybe we could consider a further reallocation at some point, if ChainLocks becomes more reliable, for example, and we're less dependent on the proof of work component.

So I don't think there's anything stopping us from making any further changes. Do we have any changes in mind at this point in time? Absolutely not. I think that this isn't something we want to change on a frequent basis. There would have to be a reason to want to change it, or something that we're trying to to fix in order to pursue it. We have this great governance system, it allows us to make changes without causing our network to fracture, and so if issues crop up in the future, we should absolutely utilize it.

Q: It sounds like you're saying that this isn't necessarily a stepping stone. This is the full move that you're making right here, you have no intention to lower or raise any of those numbers at the moment in the future?

A: No, there's there's no further plans beyond this one.

Q: Because I was just doing some rough math on what does this really changes, and it's really just taking a little bit from the miners, about anywhere from 10% or more, and giving it to the treasury and the masternodes, right?

A: It's a modest change in the allocation model, that takes place slowly over a period of time. That's the summary. We don't want to do it abruptly because it would cause spikes and subsequent crashes, and we don't want to do something like that. We also don't want to take more from the miner portion than we need in order to resolve the issue. This is for a couple of reasons: one is strictly being fair to the the mining community that is there. We determined that a small reallocation, like 5-10% doesn't affect them much in fiat terms, because it should have a supportive effect on price. But when you start to exceed those numbers, that's when it starts to have more of an immediate impact on on the miners. So that was one issue. Another is that we want to maintain a more than adequate margin of safety as far as being the dominant X11 chain. If you make your goal something like: "hey, let's minimize the amount that we can spend on mining", you start to enter solution space where you're maybe getting a little too close to the edge of security in the event that ChainLocks were to fail for a period of time. Or if we have some type of technical vulnerability when ChainLocks don't work, which is pretty rare but it does happen from time to time: you do fall back on proof of work, and we want to make sure that that remains secure. So those were the main reasons to pursue something that was more modest.

Q: Out of curiosity, do you guys have any idea of what percentage of masternode rewards get liquidated versus mining rewards?

A: No, we haven't done that analysis, and this doesn't make any assumptions about that. I would hypothesize that... just in conversations I've had with miners, a much higher percentage of mining rewards are liquidated on the market than are masternode rewards. It makes sense, the margins of operating a masternode are quite high, there's no forced liquidation. Whereas operating mining equipment tends to be very narrow margin and therefore a higher percentage needs to be liquidated to pay for operating expenses. So that would be an added benefit to this: if you're allocating resources towards an entity that's less likely to liquidate them on the open market, I think there's some additional benefits there that are not quantified in this. We nonetheless count loose coins that are sitting at a masternode address as circulating supply, for the purposes of the analysis.

Q: But isn't the whole basis for this that the miners are likely the ones responsible for majority of the selling pressure by far?

A: Remember going back to the goal here, the goal is simply to reduce the growth rate of the circulating supply, rather than stopping people from selling their coins, or allocating them towards people who are less likely to sell their coins, or any other kind of goal.

I want to clarify that although I pointed that out in December as a contributor towards volatility, the stated goal here is not to change the allocation towards entities that are going to do something different with the coins. It's just we're trying to reduce the growth rate of circulating supply as the primary goal. Because that is the metric that is most closely correlated with our relative market performance.

Q: So what is the new inflation rate going to be on an annualized basis? Is it changing?

A: Of total supply or of circulating supply?

Q: Total supply.

A: No, we're not proposing a change to the emission schedule. That was one thing that we thought would be a lot more challenging to get support for. I think that lowering the emission schedule doesn't actual hurt anyone. If you aren't yet invested in Dash, it doesn't affect you in any way, and if you are invested in Dash it reduces your dilution. So there really are no losers when you you do reduce the circulating supply or the emission rate in the future. However, there's two things: one is that that's kind of a more sacred thing for a lot of people in crypto, and so we wanted to respect that. I think the other thing is if you change the future emission rate, you start to involve a number of second-order decisions. For example, how would that affect the ROI of operating masternode? Would a lower ROI of operating a masternode cause a large number of them to liquidate all at the same time? We don't know the second-order behavior changes that would likely occur.

But not all of them were very attractive. So we were looking for something that would create some level of predictability, in terms of how the network would behave as a result of incentive changes. This is one where we had a lot of data on how the network would likely react. So that's another reason why changing the supply itself was was a bit trickier of a solution. I will say that there could be some effect here. Which is currently our ten percent allocation isn't allocated a hundred percent every month. Under our current system, there's a small portion of the coins that are projected in our circulating supply that may never be created, likely a small portion wouldn't be. So you could argue that there's a slight increase in the emission rate from this change. However there's some benefits in that too. There's some messiness in the way that we communicate our circulating supply in the end state. We frequently say: "well, it's less than 19 million coins". We can't say exactly how many less, but it's something less than that. And that assumes that a hundred percent of the budget is approved every month, and so on. So it becomes a messy answer. I think one of the benefits of this, is it makes it very clear that here's what our total supply will be in the end state. We can calculate it. In practice it's a very very narrow/small change, and it would depend on what the future would have held under our current proposal system, but I think it at least provides clarity on that question finally.

Q: So the the reduction in the circulating supply is mostly coming from the fact that we're not printing as much for miners, and we're not printing as much for the treasury right?

A: Actually the primary reduction in circulating supply is driven through the incentivization of masternodes. So you can calculate the number of masternodes that are likely to operate, given a certain reward level. Obviously the more you allocate towards masternodes, and the less you allocate towards miners, the more masternodes you get and the fewer miners you get. That's just the nature of incentives. If you incentivize the creation or retention of masternodes, you get more of them. That has the second-order effect of reducing the growth rate of the circulating supply. Basically we max out from here at about 7.5% growth for the next few years, and then it starts to drop at some point in the future. I think it's the year 2026 when the circulating supply begins to go down in terms of a rate of growth. So it just manages through this period of very high growth rate and circulating supply by doing a small reallocation. Which we are able to do explicitly because of ChainLocks - I think in a very safe manner.

strophy · Jun 18, 2020

Zoom AMA, continued...

Q: OK, I get it. So basically you're making the inference that at a higher reward, there will be therefore more masternodes.

A: Yes, and therefore it will reduce the growth rate of our circulating supply. We're continuing to allow the circulating supply to grow with these numbers. We don't want to actually shrink it, that would make the problem worse in the future as far as a growth rate. If you have a smaller base, the same growth equals a higher growth rate. So what we want to do is manage our way through this period where the circulating supply is expanding more rapidly than our competitors by a wide margin. And then at at some point in the future, that stimulus will no longer be needed because the growth rate in the total supply will be low enough that it won't make much of a difference anymore.
Q: There is no dependence on fiat prices with allocations directly, correct? But is it fair to say that the reallocations change by circulating supply only, which is a reflectance of its value in terms of USD or indirect dependence on USD value of Dash?

A: There isn't a direct dependence on the price of Dash in this. If you are providing Dash-denominated incentives for Dash-denominated investments in masternodes, it doesn't matter if the price of Dash is a hundred or a thousand in that case. Those proportions would move together, and therefore I wouldn't expect the price of Dash to affect the behavior that this would incentivize. There is a small nuance to that, which is the cost of operating a masternode is USD denominated for the most part, or at least fiat-based for the most part. So if the price of Dash is very low, and therefore the value of the rewards of operating a masternode are very low, it can affect the margins of operating a masternode, and therefore the post-cost ROI of operating a masternode. When prices are very high, a change in price of 1% really doesn't make much of a difference to the margins. But when the price of Dash is very low, say 20 bucks a month, those costs can make up a substantial portion of the ROI and therefore can dramatically affect the number of masternodes willing to operate on the network. So there is an exception to that, but at higher prices, even at $100, it's very unimportant in the models. So to fully answer the question, I have to recognize that there is that effect when the price of Dash is low, but for the most part I wouldn't expect the price of Dash to affect the outcomes from the change in a substantial way. Hopefully that was clear. It's a complex concept.
Q: Did you consider collateralized mining, did you consider proof of stake, did you consider you know a lot of different things?

A: Yes. We looked at many different options, and a lot of the rationale behind exploring them back in December was that we hypothesized that the headline ROI was the one that mattered. When we did the actual statistical analysis on previous periods, we found that that simply wasn't the case. We found that it was actually the real ROI - the ROI that is achieved after the effects of dilution from the creation of new coins - that mattered far more. Not far more, but a little bit more than the other one. What that meant is that the masternodes will react to stimulus to a much greater degree than we had initially forecasted. Therefore a small reallocation would have a significant impact. It meant that some of the more extreme solutions that we were looking at may not be needed. The problem with some of these more extreme - or further afield solutions from our current model - is that we simply don't have data on how the network would likely react. Collateralized mining as an example, is a solution in which in order to mine Dash, you have to prove ownership over some of it. The thought being that that would create demand for Dash. We don't know how that demand curve would look. We don't know how much miners would react to the requirement for that, and therefore we don't know what kind of stimulus it would create. Given the sensitivity of these networks, and the history that Dash has making changes to its economics, every time we've changed them, it's caused dramatic moves. We did it twice in 2014, and it caused a major spike in May of 2014 in the price, followed by a subsequent crash. We made changes throughout 2014-2015 that were more gradual, but ultimately had the effect of constricting our supply, and led to the early stages of the 2017 market run. But each one of those is short-lived. It causes a crash. It causes loss of confidence in Dash. We would like to avoid the type of solutions where the outcome can't be modeled, it can only be guessed. So that was some of the reasons why we shied away from some of those types of solutions. We think we have sufficient data at this point on how the network behaves in response to at least masternode incentives. Given that we had a solution that was more predictable and relatively modest, that nonetheless solves the issue we were seeking to solve, I think that's why this was such an attractive solution for most of us.
Q: Why should the miners participate or what was the logic in having the miners participate as proposals are approved?

A: The thought process here is similar to the thought process behind our entire proposal system, which is: altruism doesn't work well. A lot of these other networks require "whales" or corporations to come in and donate funds in order to to have something get achieved. Whether that's development work or funding legal representation or something of that nature. That creates challenges. It means that there's a lot of good activities that could take place and would benefit everyone from being funded, because a whale is only going to fund some something that benefits the whale. That has to be an extremely valuable activity, because they may only have a small percentage of the overall coins in circulation, and the benefit of a given activity is spread across all coin holders. So it really becomes very dependent on altruism, or restricts you to extremely valuable activities only.

So the idea behind our proposal system was: "hey, let's make it so that when proposals are approved, we're all diluted a bit, but we all benefit too, if a proposal is adding more value than it costs". If you only take the cost of a proposal from the masternode portion of the reward, it sets up a similar type of situation where a good proposal that may provide benefit to all coin holders, miners and masternodes, may not get approval simply because the cost requested is fully being borne by one subset of that overall group.

By including the miners in it, presumably if a proposal is adding value to Dash sometime in the next two years, that miners would benefit from that. Presumably through a higher price, higher adoption, higher awareness or some metric that that proposal is improving for Dash. Given that they are a participant in benefiting from it, having them share in the cost of it is a better alignment of incentives across the system, and should lead to better outcomes. It basically means that my masternodes would be more likely to approve something that maybe is kind of on the edge. It's all about alignment of incentives. I also think that there's another benefit, which is it helps the masternode reward predictability. It reduces the range of possible outcomes for masternode rewards. I could imagine a scenario in which miners are not asked to participate in any proposal that gets approved. If that were the case, and masternodes nonetheless approved a large portion of the maximum allocation, it would have the effect of reducing the masternode ROI. A lot of masternodes are passive investors. They don't necessarily participate in the voting, but they're here to gather rewards, etc. If the rewards were to drop substantially, that could cause a flight from masternode operations. That could cause a large number of coins to liquidate on the market. We want to provide stability to as many groups as we can.

Miners already are subject to a huge amount of price fluctuation risk. They buy their mining equipment, and for the next two years the price can swing wildly. I'm not sure there's a lot of benefit in providing them absolute certainty over the number of Dash that they will receive over that two years if the price itself can swing by an order of magnitude over that time in either direction. I don't think it would lead to substantially more efficient acquisition of mining hash rate by providing that level of certainty. I think the benefits, in terms of alignment of incentives and the certainty that it can help provide to masternodes over the range of ROI that they can expect, far outweigh that. So that's the rationale of having them proportionally participate.
Q: I have heard feedback that there shouldn't be any cap on the 20% for the proposal system. I've also heard that the cap should be smaller - maybe increase it to 12% or 15%?

A: I don't think this is one that we're going to get alignment across the community on. I tried to take a middle ground and apply some logic to why I think that that's a wise thing. There's two reasons why I don't think removing a cap entirely is a good idea. One is that it opens up the possibility that we allocate the full budget towards proposals, and that would have a very undesirable effect. We would have no incentives for operating either masternodes or mining. It could leave us very vulnerable security-wise. I don't think the masternodes would ever do that, I don't think that that's a likely outcome. But it does make it possible, and everyone I've spoken to says: "Well, that's not desirable. It would never happen, so why allow it in the protocol in the first place if nobody wants that ever to happen?" So I think some cap is in order.

I also think that opening it up larger than 20% starts to introduce a significant range of potential rewards for miners and masternodes that could become quite small if a high proportion were to be approved for the proposal system. That makes investing a lot more difficult. Given that most people I talk to don't envision the masternodes allocating such a high portion, I feel like it's adequately high enough to allow almost any proposal through that would be within the realm of feasibility. But it is small enough to provide a high degree of certainty to the miners and masternodes. I think that that combination is very attractive. I do think there are periods of time in our past, like in December of 2019 here, where maybe the masternodes would have accessed 20% of the budget proposal in order to preserve some of the teams that got defunded when the price of Dash was very low. I think that's feasible on rare occasions. But I think it provides a lot more flexibility, without starting to enter the realm of introducing new risks that we hadn't really thought about before. We can always change it later if there's a desire on the part of the masternodes to have the flexibility to allocate even more than the 20%. Or we may find that 20% is more than adequate for the type of proposals that get approved by the network. Because we are introducing this trade-off between approving a particular proposal and the income of a masternode, I think that it will put a pretty high bar on the value proposals provide. Therefore I think it brings a level of efficiency to the proposal system we previously didn't have when when prices would go up. Therefore I think that we've got a good combination here that doesn't open us up to new risks. So that was the rationale.
Q: I have say after hearing all your explanations that I think you guys would come up with a really well-thought-out solution. It gets rid of a number of different problems, and I didn't think about the second-order effect of having the masternodes knows no longer think of not funding a proposal as wasting money. That was something that always bothered me - we just lit the money on fire because we didn't use it. That's something that this will change effectively. It encourages more prudent spending of resources.

A: Well, some people have argued: "I don't think that the masternodes would act the same way today as they did back in early 2018 when the price of Dash was quite high, and a high portion of the proposal system was going unused." We saw some million-dollar proposals come through from celebrities and things of that nature, that had no lasting effect. The argument is they wouldn't approve those today. That may be true - there is turnover in the masternodes, they don't necessarily retain that memory as new masternodes operate and old ones go away. Secondly, we haven't had another major bull run. We've had a couple of minor ones since then, and we simply don't know at this point. But nonetheless, I think it's a healthy dynamic to introduce, because I think it solves that issue once and for all. I think masternodes are unlikely to not approve anything, because it would kill the coin. If there's no activities supporting it, they're also not likely to go back to funding celebrities that are endorsing Dash or something in the midst of a bull run. I think it really focuses the value.

strophy · Jun 18, 2020

Zoom AMA, continued...

Q: It always bothered me how the masternodes thought that when they didn't spend the budget that they were basically leaving free money on the table. But this encourages them to think more properly about the situation. It's not free money, it's coming out of the value of their token. It's just such a small amount that people would trivialize it, or they wouldn't even be able to conceptualize it in the first place. So I like the way you've made all these changes. I think this is gonna have a really positive impact on the tokens value long term.

A: Thank you. We put quite a bit of work into evaluating the set of options, narrowing them down and really focusing on a few simple changes that we can make that would be simple to implement, have predictable outcomes and add a great deal of value to the overall economics of the system. We're not talking about tons of changes here. We're talking about subtle ones, but ones that can provide a great deal of impact.

Q: Is proof of state completely off the table for now? Or is it open in the future?

A: For now it's off the table. It's a technology we'll continue to evaluate. It has some attractive properties. But ultimately we don't think it's mature enough yet.

Q: And it just comes down to security right?

A: Yes. I mean there are other reasons why proof of work can be attractive to some people. One argument that I've heard is that it allows you to - in a permissionless way - attain some of the tokens. You don't need to go to a exchange and go through KYC or something like that in order to acquire them. I don't know how much value I place in that argument, because ultimately you could do that in a number of ways even if we were to move to proof of stake. For example, you could be an anonymous contributor to Dash, demonstrate your value to the community and put a proposal up for funding for development work or for marketing or for any number of things, and remain anonymous. You could acquire it through working, go do some freelance work and ask to be paid in Dash. I don't think it would really keep people from being able to access the coin without setting up an exchange account or something like that. I think that's a fringe group to begin with that really values that. I don't know how much I buy into some of the other arguments as being very important attributes. But there are arguments out there for proof of work beyond just security.
Q: I did some math on how much of a percentage drop is the rewards for miners, and depending on whether it's 10% or 20% going to the treasury, it's somewhere between a 20% and a 28-29% reduction of the rewards being sent to the miners. So it looks like it's only 10%, but it's not actually 10%.

A: It doesn't get split evenly, it gets split proportionally with the miners or masternodes. So if 40% percent of the reward by default goes to the miners, if the full 20% were allocated it would mean a 32% allocation (to miners). So it doesn't ever become 28%. The math is 40% of 80%. So if 80% isn't going into the proposal system, at least 80% is to be split between miners and masternodes. And 40% of that goes to the miners. 40% times 80% is 32%.

Q: Right, so what I did was I did 45 minus 32 which is 13...

A: Oh I see what you're saying! You're saying versus today? Yes, so it would drop from 45 to a minimum of 32 and a maximum of 40. If 0% of the proposal system were to be approved, the maximum that they could receive is 40% under the new system. So under the new system they'll receive 32% to 40% instead of 45%.

Q: I was just you know making the assumption that most likely it will fall between 10% and 20%, which means they'll be getting somewhere in the range of 20-29% percent less basically.

A: Under those assumptions. I question whether we would currently at today's price go above 10 percent, because we don't even approve 10% today, even wen there's room in the budget. And that's without the masternodes having it affect their income. What that means is I think we're more likely to fall between you know 6-10% percent still.
Q: I thought that you guys were going to up your budget requests if this system were implemented?

A: If we do, we would put it up as a separate proposal, so the masternodes could decide separately. Just as we do today, when we put up a supplemental core team salary proposal, we put it up as a separate one to allow the network to make a decision: do they consciously want us to expand the team or not? We don't have any concrete plans to expand it. We could put up a temporary supplemental proposal in order to build our reserves without increasing or run rate. That would just make the Dash Core Group more financially sound. We could do something like that, but we didn't have any concrete plans as to expanding our ask from the network. I do think it would be healthy to shore up our reserves over the course of a month or two, but we haven't formally pursued anything like that. And this system would take a while to put into place, so you know if we had a nice bull run here over the second half of the year, maybe triggered by a number of different factors, we may not need it. I think by the time everything gets implemented and the network migrates, we'll see where we're at and whether it would be necessary. But we weren't doing this with the intent of "let's expand the team", that wasn't the plan.

Q: I was thinking let's get everyone on salaries that are "fair". I thought a lot of people are taking pay cuts and some people were working for free, and that obviously isn't sustainable.

A: They have. So I would like to correct for those things. We're very close to being able to do that today, our reserves have been building, and our target is a minimum of three months worth of salary in reserves before we start reinstating everyone. We're down to a handful of people that are volunteering at this point. Some of those people couldn't do it any longer, and we've reinstated some folks, but we've nonetheless gotten closer to being able to reinstate everybody. There might be some proposal that we put up to get us over the hump and finally gets get the last of those people reinstated. And there are other issues. I mean, some of these folks have been with the team for over two years and have never had a salary adjustment, even for inflation. So in essence, they've had their pay reduced over the time period they've been here in real terms. So there's a few things like that that I would like to get taken care of and treat people fairly, but the idea wasn't "let's expand the team". And I'm hoping that we'll get there on our own by the time this even gets implemented.

Q: You're storing your reserves in USD right?

A: Most of it, yes. There's a small amount in Dash, and good reason for it. One example is our legal and tax budget, where it makes sense to hold it in Dash. Because if the price of Dash goes up, more than likely we're socking away reserves that can become taxable if our reserves from year two exceed those of year one. If the price of Dash drops, more than likely we're drawing down our reserves during a period like that. If that is the case, our tax liability would drop. So, by keeping a small portion in Dash, we can hedge out some of that risk, but otherwise we hedge out the risk almost immediately when we receive it. In that way, if the price of Dash drops, the reserve can do its job. If we kept it all in Dash and the price of Dash dropped, our income and reserves would both drop at the same time, and that would be very undesirable.

Q: The best way I think to do it would be to have... ideally, if you're in what you predict to be a healthy next few years, probably a healthy mix of both of them, but in the case of this I think it makes sense to be overweight the dollar right now, because of the uncertainty. We're not really clearly in a bull run yet, so it makes sense to be a little bit more conservative.

A: Yes. To be absolutely clear we don't liquidate it all immediately, we actually spread out the liquidations over the course of the month. Because that way, we take advantage of dollar cost averaging our way out... I should say Dash cost averaging our way into the US dollar. On average, you come out ahead when you do that. We don't hedge out immediately, but we hedge out very quickly.
Q: Did we ever get a ruling from the SEC about being a non-security?

A: No, we never got a ruling. The SEC has only issued one so far, and it was basically for a guy who is issuing digital coupons. Otherwise, they haven't issued a letter. They're being extraordinarily cautious. I would say that the project achieved its stated goals though. This was mid 2018, we were getting inquiries from a number of exchanges all at the same time saying: "Hey, we're getting letters from the SEC asking about Dash and whether it's a security or not, and why we believe it's not. We don't know how we should respond." So we pursued direct interaction with the SEC, rather than trying to support exchanges one at a time on this issue. We put together a legal argument over the summer of 2018 using proposal funding. We approached the SEC through our lawyers and through letters requesting a no-action letter. In reality, the lawyers told us at the beginning they're very unlikely to issue one, but it nonetheless can get you to a place with the SEC where they don't consider you a security. We actually met with the SEC in Washington DC. Glenn and I flew out there and met in person with a number of the SEC's divisions. There was a panel of people on the other side - we were on one set of tables with with our lawyers, and there were more than a dozen people on the other side of the room from various divisions of the SEC. We sat there and got drilled with questions for a couple of hours. There were some follow-on questions, and we responded in a letter to them. And then we couldn't get them to call us back. We were emailing them for a status, for what's going on, and they basically stopped interacting with us. They also stopped interacting with the exchanges regarding our security status. We continued to pursue a response from them well into 2019, at which point I think we determined we're not going to get one. They basically lost interest. I think it achieved what we wanted to, which is we convinced the SEC that Dash is not a security.

Subsequent to that, the Crypto Rating Council rated Dash a 1.0, which is a perfect score for whether or not it has good arguments for not being a security, and a lot of the information we provided to the Crypto Ratings Council was on the basis of the work that we pursued with the SEC. So we had some very compelling arguments, and they agreed with us. At this point, there's no doubt in the industry about whether or not Dash is a security, and nobody's being bothered by the SEC or really anybody else, because because of that Crypto Rating Council rating that we ended up getting. So I think we're at the stage where that issue is completely behind us thanks to that work.

Q: I didn't actually realise that you had met with the SEC at such a formal meeting. That's pretty amazing they took the time to do that. That was in the middle of 2018?

A: That was in October of 2018. Then we had some follow-on communication with them in November to answer some specific questions that they'd asked us in relation to the Hinman factors. We provided that, and we haven't been able to get their engagement ever since, despite our repeated requests for feedback or anything. The SEC is extremely unlikely to issue a no-action letter, because they recognize (especially in crypto) that networks can change. They've recognized that cryptocurrencies can start out as securities and become commodities, and vice versa. So they haven't issued one yet in the cryptocurrency space, other than that one that was essentially digital couponing.

Q: I was just looking at when Coinbase started to trade Dash, and it looks like that was September, which is actually before you had that meeting. So they they made up their mind before that interaction to add Dash?

A: No, Coinbase added us in September of 2019.

Q: Oh okay! So then that meeting likely was kind of one of the things that paved the way for Coinbase to add us, right?

A: Yes. I believe that it is. Coinbase has a very rigorous process. They have listed some things that have attributes of securities. So I don't know how much of the issue was related to that. We also communicated with Coinbase extensively on the issue of PrivateSend and explaining how it worked, and same with ChainLocks. That's one of the reasons they adopted ChainLocks, one of the first major exchanges to do so. That paved the way for a lot of other exchanges to open up to the idea of InstantSend and ChainLocks. We don't know what the factors were that had caused Coinbase to pass over Dash for a long long time. We just kept engaging with them, kept asking for whatever their needs were and we kept trying to provide it. So eventually - apparently - all of their concerns got addressed. I don't know if this was one of them, but it is a portion of their application processes. You know: "are you security? how do you know? what evidence do you have?" So it certainly is a consideration for them.

strophy · Jun 18, 2020

Zoom AMA, continued...

Q: Did you see the article that came out this week saying that Chainalysis can now track Dash and Zcash? Did you have anything to say about that?

A: We've had AML providers already. Coinfirm was the first, BlockchainIntel also supports Dash. So we've had AML providers that provide blockchain analytics for Dash already. What they said - and what is absolutely true - is that Dash has a transparent blockchain. You can provide analytics on the blockchain itself, and therefore you can conduct investigations regarding Dash. I don't think they want to tip their hat too much about what they're able to do, but I would say that it's well known that if you use very few rounds of mixing, and use a large number of inputs, that does open you up to the possibility that your transactions can be linked using PrivateSend. Even if you use a large number of mixing rounds, and very few inputs, the receiver can still identify that you mixed funds. That's transparent on the blockchain, you can see the source is a denominated PrivateSend input that can't be traced anywhere. So you can risk-score those, even if you can't tie those together. But it's already well known that if you use too few mixing rounds and too many outputs (or PrivateSend denominations) as part of your transaction, you can compromise your privacy. The wallet actually warns you of this - if you use greater than 11 inputs to your transaction, it will provide a warning and say "hey, if you haven't sufficiently mixed these, this could open you up to some level of security vulnerability."

So it is true. You can attempt to analyze PrivateSend transactions, and in some cases you are able to link them through to an originator. Nothing they said is false, and these limitations of CoinJoin are well known. I think their post basically said "hey, look these are ultimately CoinJoin transactions, and therefore it's a bit of a misnomer to call Dash a privacy coin, because you can analyze the transactions." They don't guarantee that if somebody uses too many rounds or is sending you a single output from those, that they will be able to tell you where it came from. They can't. But that doesn't stop them from providing those services and attempting to do analysis for investigations and things. You'd be shocked actually, the number of cases that we've seen of masternodes that have had stolen funds or somebody's roommate took all their Dash... Most of these instances they don't even use PrivateSend, they just send it to an exchange and sell it. The investigators end up subpoenaing the exchange and finding out the identity of the person that made the deposit. So you'd be surprised. Criminals are not intelligent people. So if law enforcement is able to use those tools, and they can still carry out successful investigations with Dash.

Q: I've been hearing that Bitcoin has actually increasingly been used on the dark web, to most people's surprise. Everyone thought that they would be sticking with privacy coins primarily, but I think based on the statistics I saw in the latest analysis, it was something like 75+% of all transactions on darknet are just Bitcoin. But they're using the Wasabi Wallet, which is another form of CoinJoin. And now there's a new one that's potentially even less likely to be scrutinized by the government. But they're gonna get on that one soon. So CoinJoin is basically the same method that we're using, so it makes sense why - if they've probably become very adept at analyzing CoinJoin - they're probably come becoming very adept at analyzing our coin.

A: Yeah. One of the differences we don't have transaction fees in those transactions, and the inputs are all denominated. So it's a bit tougher to analyze a Dash transaction. One of the things that the Wasabi Wallet does differently, is they use an enhanced method of CoinJoin called Chaumian CoinJoin. (I don't know if I'm pronouncing that correctly.) But what it does is it shields the IP address to even the coordinating server. In the case of Dash, we've gotten around the problem a different way, which is we do multiple rounds, and so unless a particular masternode owner witnesses all of the rounds of mixing that you go through, they can't link it through. So it doesn't really matter. I would like to get Chaumian CoinJoin on our network as well, so that even the coordinating masternode can't see which addresses belong to which inputs. But I think that the benefits of that are primarily optics, as opposed to providing real benefit. Since you go through multiple rounds on the Dash network. So do I think it's likely - if you use eight rounds or something like that - that one masternode operator sees all of eight of those transactions? No. That's mathematically almost impossible. But Chaumian CoinJoin would be a good thing to add, and that would make it slightly more robust. But I think we have a really strong implementation of CoinJoin. It meets all the the FinCEN guidance requirements. At no point are you handing over your funds to somebody else to mix for you. You're doing transactions from your own wallet to your own wallet whenever you're doing mixing, and the solution provides the privacy without requiring some third party that's charging you fees in order to do it. So I think we've made it very convenient as well, and inexpensive, whereas Bitcoin transactions are very expensive. Transactions on Dash are cheap, so the mixing transactions are cheap. So we've made it cheap, easy and effective. Our solution is very good, and I would hope that more people would use it. We are seeing increased use of it, by the way. If you look at the number of mixing transactions on the network, it's been rising this quarter quite a bit. So if you use it, and you use it properly, it's very effective.

Q: I find it kind of ironic that Dash had been laughed at for its "inferior privacy tech" for a lot of years, and all of a sudden everyone's using Bitcoin's privacy that does exactly the same thing. And you're saying if anything it's worse than ours?

A: Well yeah, but there are advantages to Bitcoin in terms of access and familiarity. They're catering to their customer. When you look at actual behavior of how darknet participants, or people that do ransomware, or people that are running Ponzi schemes and those types of things, whatever the criminal act is... when they try to launder funds, they don't use one technique. They don't just use the Wasabi Wallet and then send it to an exchange. They use Wasabi Wallet then they send it to one exchange with what they call "regulatory arbitrage". That's in a jurisdiction with very limited KYC requirements. Then they change that for - I don't know, some other coin, Litecoin, Monero, Dash, whatever - then they'll transfer that to another exchange with slightly better KYC requirements. But now it's an exchange to exchange transfer; they decoupled themselves from the original one. They might send it through one of these exchangers, where you go to a website and say I want to give you Ethereum and get back Bitcoin... and they go through a number of these different cycles to try to create as much separation as possible between the originating transaction. They switch chains, they go through multiple exchanges, they mix, they do all kinds of things in combination with each other if they're sophisticated actors.

I think for the average person, just trying to maintain their privacy and keep their neighbors from spying on them and maintain their security... you know, if you've got ten grand worth of Bitcoin or crypto on your wallet, and you do a transaction at a merchant, you don't want the merchants seeing that transaction. Or if you transact with someone that's an acquaintance to pay them back for lunch or something like that, you don't want them finding out what your balances are. That can put you in physical risk, or risk of theft that someone might target you. So there's lots of good reasons for privacy. But when you look at people that are actually laundering money for a living, they they use a lot of different techniques and in conjunction with one another. They don't just mix through Wasabi and done.

Q: You'd be surprised. I actually got held up with a bunch of money on HitBTC. I remember when I was selling some Dash on behalf of the Dash Watch project, they ended up asking me to prove where the money came from. And some of my own Dash was part of that as well, and they were asking me for all the history of when, did I buy it... it was an enormous amount of information they kept asking me for. So they're pretty suspicious and HitBTC is what I would call pretty low in terms of rankings as far as following the letter of the law, basically. So the fact that they did all of that tells me that probably exchanges like Coinbase and Binance might even be more likely to scrutinise. Have you heard of anything like that happening?

A: Not personally. Only reports where people have had their funds frozen by an exchange until they can provide evidence of something. But I'm sure criminals aren't the ones who are typically.... you know, they're probably the ones that get targeted more often for that type of thing, and probably aren't going to publicize it when it does happen to them. They probably just write it off as a loss and say OK. They probably opened their account at the exchange under a false name anyway. They probably just take a certain percentage as a loss whenever they get caught. I don't know. I don't know how it works to be honest. I've heard of people having more questions asked of their transactions or having to prove something.
Q: I think when they see someone selling a large amount of a privacy coin without any sort of history before that, they automatically get suspicious more, most likely. The other thing I was wanting to ask is did Binance and Coinbase integrate InstantSend or ChainLocks?

A: Coinbase has ChainLocks. They require two block confirmations. So they require two ChainLocked blocks in a row, and then they credit the account. That's still the fastest deposit method. They could not come up with a reason why one wasn't sufficient, other than: "maybe there's something we didn't think of". Some vulnerability we can't come up with, but exists here, that we can't figure out. I've never been through that level of scrutiny, regarding how the system works, that Coinbase put us through. Their engineers are REALLY intelligent and came up with scenarios I've never even heard of before while trying to figure out how they could break the system. So that was a really good exercise to go through. But in any case, they required two ChainLocks. Binance does not currently support ChainLocks or InstantSend, but I think we're close. I'll leave it at that.

Q: So there are probably no other cryptocurrencies that have InstantSend to exchanges? If we ever were to get that, it would probably make a use case that we haven't able to take advantage of right?

A: Well we've been pursuing this pretty aggressively. Quite a number of exchanges support InstantSend. I think the most recent one was last quarter, we got Whitebit to support it. They're a pretty significant in exchange in Russia. So we're chipping away at it. There's a number of exchanges that have come close that are major. We hope to be announcing more of those over the next two quarters. It's a slow process: getting them to analyze it, getting them to get comfortable with it, getting them to then put it into their roadmap and implement it. It takes a lot of work on our part, but once they integrate it, it stays the same. I mean, you don't have to recertify with Coinbase, for example.

Q: One thing that I've noticed with these exchanges is, let's say even if they only require one InstantSend confirmation, the way their systems work, they only rechecked all the blockchains history every so often. So even if it's sent within one second, if they only refresh once every minute or two, then you're still lagging with that one or two minutes that it takes them to refresh.

A: Yeah, they're not gonna re-engineer their back-end for Dash. It nonetheless speeds it up, even in those cases. One example of this is CoinBene (I think). They refresh every 10 minutes. Which means you could be waiting up to 10 minutes, even if they support InstantSend. So the deposit got recognized in their system immediately as secure, but you have to wait for that next refresh that they go through. But you compare that to another coin that might require six confirmations, say Litecoin for example. Well, you're already talking about around 15 minutes. So you've already got a 10-minute leg up against Litecoin, and maybe even more depending on the timing of those things. If I happen to send my transaction right before the ten minute mark and it does a refresh it could seem almost straight away and Litecoin wouldn't confirm for another twenty minutes. So the advantage is still real, even if it's not experienced by the user immediately, it still provides them benefit. We nonetheless try to take that route with them: that if you recognize this immediately, it still can avoid one to two of your ten minute cycles, and that can provide a better user experience. So they're not going to change their backend, and so we do run into those limitations from time to time. But most exchanges are fairly realtime. Kraken does a batch process where every minute it moves through one stage to the next in the process. So if you can start stage one that much faster, it's beneficial. I think Kraken's process is it's recognized, then it's recognized as incoming, and then in the third minute it's like crediting to your account and the fourth minute it's credited to your account or something. So it goes through through those stages, where it moves from one stage to the next, and checks a different thing every minute. But if you can start that process fifteen minutes sooner, it nonetheless helps. Same when you're sending from Kraken: they say verifying, then the next minute it's verified, the next minute it's preparing transaction, next minute it's batching transactions with others, and then the minute after that they actually send the transaction on the blockchain. So we see different backends with different benefits.

strophy · Jun 18, 2020

Zoom AMA, continued...

Q: Is Kraken the biggest name exchange that's accepting InstantSend?

A: I don't know the answer to that.

Q: What would be another one or two of the other ones that accepted that are well known?

A: It's on our website. If you go to the exchanges section, they're labeled whether they accept ChainLocks or InstantSend. So if you just go to "Buy online", Coinbase is ChainLocks, HitBTC supports ChainLocks, Indodax supports InstantSend, Bibox InstantSend, Whitebit InstantSend, Kucoin InstantSend. So there's a number of them. Uphold supports InstantSend, but in reality acts more like ChainLocks, because they only pull from their server whenever a block is found. So it acts more like ChainLocks from personal experience on that one. Bitbns, CoinCola, Cubobit, Digifinex - all of them support InstantSend. So we kind of got the most traction early on with a number of smaller exchanges, and then we've gotten some of the larger ones recently, like Whitebit. We're in talks with some of the larger ones at this point too. We're trying to prioritize (at this point) BTI-verified exchanges that have real volume, and exchanges that have fiat trading pairs.

Q: Do you have to pay them to integrate InstantSend?

A: No, we don't pay any integration fees. We might run a promotion with them, just as a carrot to try and get them over the line. But those are very low cost. We have a policy from our Business Development team that, if it's over a certain amount, we have to go directly to the network. So we're only allowed to spend a small amount of money with any one partner over a given period of time. So we'll run a promotion or something in parallel to try to get them to agree to do the work. It's a bit of a carrot. If you integrate, not only will you get the benefits of a better user experience, but we'll help you promote it. We'll do some type of contest or something with them. And that's usually pretty effective. They like the idea of getting in front of our community of users and trying to attract more share from the market.

We've kind of gotten off topic quite a bit. I like answering questions and things, and you were asking some good ones, so I don't mind. But just getting back to the topic at hand, are there any questions out there?
Q: I think this meeting is about the decision of on changing the amount of Dash that gets printed either for miners or for masternodes is that correct?

A: I would word it differently. We're not changing the amount of Dash that gets printed, but we are changing the reward allocation between miners, masternodes and the proposal system.

Q: Well that was one part of it, but in the last meeting I heard you said that there was too much inflation of Dash with respect to Bitcoin. And that was probably the cause why Dash was losing ground with respect to those coins, I don't know if I got that right?

A: I made the case that the growth rate in circulating supply was a contributor. Now there's a distinction between total supply and what I'm defining as circulating supply. I don't know if you've seen the presentation from last week, but one of the things I wanted to clarify is that the definition that I was using in those presentations for circulating supply is "supply that is not in a masternode". So this is coins on the open market that are on exchanges or in people's wallets. The idea is that by changing the incentives, or the incentive structure, you can encourage the retention or creation of masternodes by allocating a higher portion of the rewards towards masternode operators. That creates demand for Dash in the form of collateral - 1000 Dash per masternode - and through that mechanism, you can manage the growth rate of the circulating supply. So we're not talking about altering the total supply of Dash, or the emission schedule, or anything like that. This proposal would not change that. What it would change is the behavior of the network, the incentives on the network, in a way that would reduce the growth rate until a point in the future when the growth rate is naturally low.

Q: In these kind of decisions, how do masternodes actually vote on them? Because I've seen the proposal system only votes on proposal allocation. They don't actually have a governance system to decide on this kind of meta-decision.

A: We have used the proposal system in this manner in the past. It's called a decision proposal. Although functionally the same as a funding proposal, we simply ask for 5 Dash - which is the cost of the proposal - back. So it's not truly there as a funding proposal. Basically the masternodes vote, and if the proposal reaches the necessary net 10%, the proposal passes. Now if we make these changes into the code, that doesn't necessarily mean that the network adopts them. The network still has to adopt the changes by downloading the software and installing it.

Q: Well, it's very difficult for the masternodes to kind of decide that "I'm not going to run this code" or something like that.

A: Yes, but it still is a requirement. So it requires a supermajority of the network to approve of the changes through the vote before we will pursue them in the code. There is a precedent for this. The first decision proposal was all the way back in January 2016. It was a proposal to increase the default block size from one megabyte to two megabytes. We've now held several decision proposals in the past on a number of topics. They tend to be rare, we don't do them often. But when a protocol-level change - a significant protocol-level change - is being proposed, we seek formal approval from the network before doing it.

Q: That makes a lot of sense. If I could suggest, it seems to me that one of the biggest critiques that Dash receives (and we've spoken about it in the past) is the role that Dash Core Group has with respect to the rest of the network. Every time there is this kind of decision, we as people who own Dash and people who support Dash, come under crossfire from people saying: "See, Dash is centralized" and so on.

I don't know exactly how to solve this. But it seems to me that the more we are able to, even in the wording, to make it in a way that is the network that suggests the wording of the suggestion. I mean, there is a risk that you suggest one megabyte or two megabytes. Why not 3.5 megabytes, or something like this? It seems to me there is still a risk that people might think this is too centralized, just because of the way in which things are worded and who writes the proposal. But the programmers still need to code it later, and so on.

I'm just raising this point, I don't have a solution at the moment, but I think we should be aware of this. Because every single time there is a change in the Dash platform, we run the risk of being criticised as being unstable. And being unstable is one reason why people think that e.g. the stock-to-flow model applies to Bitcoin and doesn't apply to all the other altcoins or something like that. I don't know if you follow this kind of discussion that went on over there, that's just my thoughts about it.

A: We get criticized for a lot of things. I try to focus on what personally - and I would encourage the community to do the same - is focus on what we think is right for Dash, and focus on what we think is the right thing to do, as opposed to worrying about what other projects are going to criticize us over. And not to discount the criticism - I think that we set our system up in a way to maintain decentralization. Dash Core Group has no special privilege within the protocol. So I think that there's limited validity to the criticisms in the first place. I think we've been very mindful to set it up in a way where there's a high degree of accountability back to the network. I wouldn't advocate for starting to do things that aren't in the best interest of Dash just because somebody associated with Litecoin is going to criticize me for it. I hear you - I think if there are things we can do to avoid criticism, that's probably good.

Q: I was thinking about your last meeting one week ago. I was really impressed by the analysis that you made, where you were able to explain the price going down with respect to basing yourself on the relation between the cost of masternodes and the real return. It was the first time that you actually spoke about the real rate of return of masternodes, which also included how much Dash a masternode would receive, but also how the price would actually go down.

A: Well, it wasn't related to price, it was related to dilution. So it was all ROI denominated in Dash. To be clear, I was talking about the dilution of new coins being created.

Q: So it was not considering the fact that Dash was actually losing value in the last two years?

A: No. Fiat value doesn't matter to ROI, because the the cost of a masternode is denominated in Dash and the rewards are denominated Dash. So whether Dash is $1 or $10,000, the ROI calculation would be identical. So what that is referring to is the dilution that occurs when new coins are created. When a proposal is created, it's not cost-free. It's just that everyone's coins are diluted a little bit, because we all own a slightly lower percentage of the overall circulating supply at that point. So it was taking into account the dilution that occurs from all the coins that are created for miners, masternodes and proposals.

Q: OK, sorry I misunderstood, thank you!

A: I'm glad I could clarify. I think what a lot of people don't realize is that even if you owned a masternode since 2014, kept all of the rewards and reinvested them in masternodes, and covered all of your operating expenses for that masternode out of pocket, you would have a lower percentage of the coins that are in existence today than you had back in 2014. Actually masternodes have have been dilutive. It's certainly less dilutive than if you'd held just the coin without operating a masternode, and so there are in essence a reward there for operating them.

Q: My mathematical intuition would suggest that if masternodes were the only ones receiving Dash from the network, and there were no miners and so on, there would be no dilution. But because there are miners and because there are Dash that are printed a for specific projects, that's where the dilution comes from. Is that right?

A: Exactly. I do project that within the next couple of years, masternode operations will actually turn positive, even on a diluted basis. So that's some good news I guess, that's coming. That still doesn't take into account the expenses of operating a masternode. What it does show, is that real ROI has been steadily improving over time. And I expect that it will continue.

Q: Thank you very much, and thanks for hearing my concerns!

Thanks everybody! I appreciate the questions, appreciate the input. We'll keep going with these events, and hopefully we can move forward with a formal solution at some point in the near future.

mage00000 · Jun 21, 2020

From my DM Conversation on Discord:

Q:
3 issues: 1 fast growing circulating supply, 2 Voting participation, 3 Fixed Treasury.
#1 has been linked to MN ROI, which is correct but MN ROI is not just a percentage of Dash being paid out. It is also the value per Dash. So if we can increase the value of Dash per coin then also the MN ROI would increase. I think that is the preferred way, because all Dash holders benefit in this scenario. Increasing the MN reward allocation ONLY rewards a very small group. I would like to see the MN reward split into two parts: a service reward and a savings account. Then it is but a small step to make savings accounts available to others as well. This would make Dash more desirable as a HODL-coin, thus increase its price and reduce its availability and increase MNO ROI. From savings accounts it is but a small step to allocating voting rights to smaller hodlers. For example a 100 D holder could get a 1/10 vote. This would increase voting participation as many smaller hodlers would like to have a say as is demonstrated in shared MN services.
#2 The current calculation for a proposal to get funded is wrong. People who do not vote should not get included in the calculation. One could vote "abstain" if one insists on being included without actually voting. But non-voters should NOT be included. It is simply wrong. If you do not vote and insist on being included then you are basically against progress in Dash.
#3 The treasury should be variable and be linked to the rewards of those who are entitled to vote (whether they actually vote or not). As indicated above I would like to increase the number of entitled voters by introducing savings accounts with a minimum of 100 D. Perhaps at a later stage when the value of Dash has increased significantly we could give voting rights per 10 D in a savings account.
Those are just my 3 cents/satoshis/duffs

@1: I think it should be considered whether voting rights should be linked to the MN service or the savings account. I think it should be linked to the ownership of a certain Dash amount and thus to the 1000 D. So I can see these steps (taken over the course of a couple of years): - split MN reward into service reward and savings reward - couple voting rights to the 1000 D savings account - reward non-MN 1000D savings accounts - reward non-MN 100D savings accounts
@2: the calculation should be adjusted [yes-votes]/[nr of MNs] (which makes no sense) should become [yes-votes]/[total nr of votes] (which is how every voting is done)
@3: I believe that matches with what has been suggested. I trust you'll do the right thing.

A:
Regarding #1, the ROI does NOT change with the price of Dash. Remember that ROI is expressed in Dash, so a changing USD value doesn't affect the ROI. Even if the price of Dash increases, the ROI does not. Why? Because the cost of starting an MNO has also increased proportionally. Likewise, someone that already owns a masternode would also face the same decision, get a return of say 6% on the current value invested, or cash out that investment. Increasing the allocation to MNOs does not only affect the MNOs, and in fact it doesn't even benefit MNOs more than general users. Your assertion would be true only if the market didn't react in any way. However, the market does react to changes in the network. Specifically, the number of masternodes operating would be expected to increase if the MNO allocation increased. If there are more MNOs, each MNO would get paid more PER PAYMENT but would also be paid LESS FREQUENTLY. The overall effect is that the expected ROI to an individual masternode would remain unchanged net of these two effects. The only way to earn more MN rewards would be to invest in more MNO collateral. So this would not be expected to directly benefit MNOs, at least not due to higher ROI (in fact ROI is expected to continue dropping even under my proposed reallocation). The primary benefit is that the reallocation incentivizes demand for collateral to operate additional MNs. This demand benefits EVERYONE EQUALLY. The increased demand for collateral leads to 1) A higher price for anyone holding dash (including MNOs who hold a significant amount in the form of collateral), 2) a proposal system that supports more proposals with the same amount of Dash (since the price of dash would be higher than it would without the reallocation), and slightly higher miner rewards in fiat value terms (the expected price impact is projected to be slightly higher than the loss of dash-denominated revenue for about 2 years).

I do understand the value of shared MNs. I don't disagree with your arguments on the benefits. I tried to explain the rationale for not pursuing those at this time. The main ones are:
1) There are a set of security vulnerabilities they introduce that are very difficult to mitigate.
2) They are exponentially more difficult to code, so the costs of pursuing that path are much higher and we wouldn't be able to address the issue for a much longer period of time.
3) The benefit would be quite limited, because shared masternodes are now arriving from exchanges (Huobi just announced, Kraken has announced "coming soon" on their staking page, and another major exchange is rolling out service next week). These services are insured and highly secure.
4) the result is difficult to predict. If greater access leads to primarily existing Dash holders to spin up new nodes, it would cause the ROI of all MNs to drop. If that happened, it might actually cause a proportion of existing MNs to decide to sell if they determine the rewards are no longer worthwhile. So there are feasible scenarios in which demand for Dash actually DROPS due to shared MNs being introduced. No one knows what would happen, so that path carries extra risks. The security vulnerabilities are very difficult to mitigate, by the way, and that would require its own discussion as the issues we uncovered are really hard to solve and very complex.

Thanks for feedback on #2. I agree. If you want to vote abstain, fine. But if you don't participate at all, that's just preventing decent proposals from passing.

Shared voting would be great and expanded access would be great. The main issue with expansion of the voting system is that we require a completely new architecture. The current architecture actually crashed mainnet when we first launched it. It doesn't scale and barely can handle the votes being cast today. We had to slow down the propogation of votes to even get it working on mainnet. That is something that will be much easier to rearchitect on Platform. So I think that's something we can look at in the future once Platform is on mainnet. Thank you for the comments and input. I hope my answers helped clarify a few things and in particular why we decided to put forward the proposal we did. Not sure if any of those answers address any of your concerns. Let me know your thoughts.

Q:
Thanks a lot for taking the time to respond. I think I will post this conversation in a more public place so others can read it too. That is of course, assuming that you're OK with that. There is one part in your answer that I find puzzling, maybe you can elaborate/explain. If I take your response and replace the word Dash with say Tesla shares it would read as follows: I buy 1000 shares and after 1 year I get paid a dividend of 6%. This dividend is paid out in shares (Elon has his strange ways). In that year the shares have gone up 10%. So if I sell after that year, I can sell 1060 shares for 1.1 times the initial price, so I will get 1.166 times the money I had put in. Would you then say that my ROI is 6% because I get paid in shares? I would say my ROI is 16.6% and I thought that is how it is commonly calculated, am I wrong?

A:
Yes, sharing with anyone interested would be fine. I think there is a ton of overlap with Q&A I've already done, so I don't think there's anything new in there, though.

Regarding ROI, you are technically correct about the definition in USD terms. However, there are many issues with attempting to use a USD ROI in our context.
1) We are unable to make price predictions about the future with any accuracy.
2) The ROI as you describe it is backward looking, yet the ROI measured by investors in a masternode wouldn't be affected by past price movement. They are deciding whether to sell their 1,000 Dash or keep their 1,000 Dash and earn a return of x Dash over the next year. That ROI is not affected by price historically. Decisions are typically made looking forward. And you can't make decisions in 2016 based on information about price movements in 2017. Those those decisions are always made in Dash, not USD.
However, this is obviously oversimplification. You would never invest in 1,000 Dash if you suspected a 50% decline in price was coming, even if it paid 10% annually. So stabilizing the price is important to give the market the confidence to invest.

An individual investor could include an expected price change in their personal ROI calculation for expected returns. We just would have no way of knowing what the average person's expectations are as they make their decisions. The data strongly suggests that it isn't a major consideration, probably because it's impossible to predict. People seem to make their decision based on what is known... that I'll earn about 60 Dash per MN over the next year. There is further complication with using other currencies, too. For example, the ROI would be wildly different for bolivars vs. USD or EUR. The only consistent ROI is denominated in Dash.

Q:
OK, I don't want to take up much more of your time. Just two more thoughts:
1 - Cryptocurrencies are introduced as a safeguard against the failing current system. When major SHTF "insured" may not mean so much as many insurance companies will go bankrupt. So the preferred way to have shared MNs would be one that is included in the Dash protocol. I don't see that many risks in savings accounts that others then can combine into a MN as all the Dash can remain under control of "the network". Yet, I can see that it will probably be much easier to implement once platform is out.

2 - Back to voting. Seen from a logic perspective there is no difference between not voting, voting "abstain" or voting "no". Since only the "yes" votes are counted and divided by the nr of MNs. So there are two issues to fix here. (a) non-voting MNs should be excluded as well as "abstain" votes and then we should calculate "yes"-votes / ("yes" and "no" votes). (b) If the effect of an "abstain" vote remains equal to the effect of a "no" vote then the "abstain" option has to be removed as it is misleading the voter.

A:
I agree with you on all points on 1. It's mainly the investment of time and money that dissuades us from wanting to pursue the decentralized version. It's a huge undertaking that is the equivalent of core team for 6 months. We need that team to support the changes needed for Platform, still a couple versions behind Bitcoin backports, etc. So it's just not a feasible solution to a more immediate problem, and would put us behind on other priorities. The benefits are very clear to all of us.

On 2. There is a difference between a "no" and "abstain". A no vote lowers the net vote. So voting yes is a vote of support. A vote of no actively prevents something from passing.
Abstain can signal several things and has a different effect on outcomes. It could signal "I'm not sure yet. I've read your proposal, and while I'm not against it, I'm also not convinced. You need to address the outstanding questions." or it could signal "I've decided that your proposal would not be the worst possible use of funds. You've been a good contributor to the community and I generally like the direction you're headed, and I don't want to discourage you with a no vote because its not that bad. However, this is a tight budget cycle and I'd rather see the money go elsewhere." or any number of other thoughts that could lead to an "abstain". The effect on the proposal is also different. A no vote negates a yes vote. An abstain does not. Even under an opt-in or opt-out proposal system, an abstain would have less negative effect than no (as it would add to the denominator, but unlike a no, would not subtract from the numerator). I'm not saying the ideal system should have "abstain" as an option, I'm just pointing out that its not true that there is no difference between a no and an abstain. A vote for abstain would help ensure the net yes votes a proposal would need to collect would be maintained while not actively voting against the proposal.

Q:
OK. I understand. Thanks again for taking the time to answer!

mage00000 · Jun 23, 2020

UjinK said:
That is, the total return will be 16.6%, regardless of when the shares were purchased, and when they are sold, depending on the initial price?

You can see your investment as a black box. At one time you put a certain amount of money in, at some other time you look how much you can get out of that box. You subtract the initial investment and what is left is "return on investment" (ROI). You can then express that in USD or in a percentage of the initial investment or a percentage per year.

Store of Value Community AMAs - June 2020

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

strophy

Administrator

mage00000

Member

mage00000

Member