Development Update – June 2, 2015 (Explained)

We are talking about the June 2, 2015 Development Update provided by Evan Duffield today. Link is below if you’d like to have a read.

https://dashtalk.org/threads/development-update-june-2-2015.5070/

In this post I will attempt to dissect this update and provide a bit of a breakdown as to what it means for the average user of Dash. I hope you’re wearing your learning shirt. Let’s first look at what we are talking about. The stuff in italics is from Evan Duffield. The stuff after is my overview. Please reach out to me on tha twitter if anything needs updating or adjusting.

We’re just starting to wind down active development of version 12, which is gearing up to be the largest release we’ve ever done. At this point it includes:

  • The removal of the reference node – The reference node is something that came about to attempt to normalize the payment distribution of the masternode network. In the early beginning there became an issue of choosing which masternode should be used to sign each block. Since Dash utilizes a unique Two Tier system to extend the ability of the blockchain network. The reference node filled the void during the development of the new masternode consensus system. Was it centralized? Yes. Did it do the job to normalize masternode payment’s throughout the network? Yes. Was it the best solution? No. In my opinion it was a means to an end. We are now at that end so I’ll leave you to judge whether it was worth it or not.
  • A new quorum based masternode payment consensus system. This means masternodes will be elected each block to “vote” on who gets paid. – This is what allows for the removal of the reference node. Now the masternode tier of the network is able to come to a decentralized resolution to the problem of which masternode to pick to sign each block. Here is a quote from the release today, “In the new model, each block a random selection of 10 masternodes are elected to tell the network who should get paid. This is computed using the masternode input hashes for the first payment, then after a last payment is known a valid masternode with the longest wait time is selected.“. Slow down and just think about that for a second. A completely decentralized way to come to a voting consensus? How long have they been working on e-voting in the US? How much money has been spent? I don’t even want to think. Now we have exactly that. Go figure.
  • New budgeting protocol and a whole new list of commands for interacting with the budgeting system – It is so amazing how innovation builds innovation. In this case the need to solve the issue of the reference node lead to the need to develop a decentralized voting system. The development of a decentralized voting system has now lead to the ability for the people running this second tier of the Dash network to democratically be involved in the direction of their tier of the network. This is ground breaking stuff. I’m literally getting goose bumps while I type. At this current point we are sitting at 2650 masternodes. This means we have a caucus of 2650 members each with one vote. Some of the caucus members have already formed into parties. I know of one party named the Moocowmoo party. I know of another party named the Otoh party. There are also a lot of incumbents running for themselves on their own platform. Sorry I forgot which political system I was talking about there for a second. Dash or Governments. At least with our system everything is actually out in the open and publicly immutable. Powerful concept when combined with a finite money supply. Now this whole budgetting thing is going to have it’s own set of hurdles. Just like the reference node this budgeting system might bring on some of it’s own challenges.  It’s a similar take to the Neucoin.org model (due to be launched prior to September) but rather then given every coin a vote this model gives the people inside the class direct control over their class.  So how is this all going to come together. It requires a hard fork and a few soft forks. Again we don’t mind cause we have the Spork to rely on. A hardfork will be done in conjunction with the release of the 0.12.x of the code. There will be a short update period where both versions of code 0.11.x and 0.12.x will be allowed to run on the network. Once sufficient numbers of masternodes have updated then a series of sporks will be activated to reduce the block reward by 10%. REDUCED BY 10% YOU SCREAM! SCAM!. Let me finish. In order to catch up the emission rate of coin’s and also to creatively fund the project proposals each month will end with a Superblock. This superblock will contain more coins in coinbase then the regular blocks and it will essentially include the missing 10% that stopped being emitted after the spork and before the end of the first month.Ok so we have talked about how the budgeting is going to work but we should also talk about how much money we are talking about budgeting and using for highering block chain contractors (the winners of these proposals). The masternode network operators essentially become stewards of the funds. Voting on which proposals to implement and pay for. The basic breakdown for this if you look at the mining reward of 1 Dash per block is as follows: 45% to the miner, 45% to the masternode for PoS, 10% left behind which will be paid to the Masternode network development budget proposals as voted by the masternodes and funded by the Superblock. So how do we calculate the amount of coins left behind by this 10% not being emitted during the month. I needed some help from Moocowmoo as usual on this one.

    5 * 576 * 30 * .1
    min block reward * blocks per day * days * 10%

    Remember how your parent’s always used to tell you to save at least 10% of what you made for a rainy day? Look at us growing up and listening to our parents

  • Updated to Bitcoin v10 with headers first blocks – Keeping up with Bitcoin upstream is what shows we aren’t fsck’ing around. Our dev’s know their stuff and they don’t hesitate to either blaze the trail or merge it upstream. Bring it.
  • New improved masternode broadcast/ping architecture – The faster the second tier can talk and communicate the better they work for the users on the first tier. I don’t know the in’s and out’s of these changes but my gut say’s its making the PoS changes that allow the masternode network to self regulate that all their members are properly behaving is just getting better and more robust.
  • New wallet repair buttons – I hate it when my wallet is broken. So having a fix my wallet button only seems logical. Again not exactly sure what these specific repair functions do yet but I bet you they fix stuff.
  • New website for submitting proposals – Now that the masternode network part of the blockchain can higher contractors and pay them with collected funds it was important to have a website and infrastructure to allow for the submission of proposals. This website works in conjunction with the masternodes budget funds. The funds are put aside so that the blockchain can accept proposals and vote on which ones get implemented and pushed out to the network.
  • Improvements to DS – Can fungibility ever go to far? Nope. We will always continue to improve this area of Dash. Dash Dev UdijinM6 talking about some of the DS improvements this release: https://dashtalk.org/threads/development-update-june-2-2015.5070/page-3#post-55758