2017 Decred Roadmap Update 1

A lot has happened since we announced our 2017 Roadmap on January 9th, so we figure a progress update is in order. We expect to complete the majority of what was laid out in the roadmap before the end of 2017.

2017 Decred Roadmap Update 1
BY JAKE YOCOM-PIATT ON AUGUST 2, 2017

BY JAKE YOCOM-PIATT ON AUGUST 2, 2017

BY JAKE YOCOM-PIATT ON AUGUST 2, 2017

A lot has happened since we announced our 2017 Roadmap on January 9th, so we figure a progress update is in order. We expect to complete the majority of what was laid out in the roadmap before the end of 2017. Here is a very brief summary of our progress on the roadmap:

  • Convert Decred into a stakeholder-directed DAO
  • Hard fork voting - Complete, In production
  • Public proposal system - Work-in-progress, ETA late Q3 2017
  • Decentralized control of DHG funds - Work-in-progress, ETA early Q1 2018
  • Lightning Network support - Work-in-progress, ETA Q4 2017
  • Improved GUI wallets - Work-in-progress, ETA early Q4 2017
  • RFP process change - Complete, In production
  • Presence at events - Work-in-progress, talks in Q3 and Q4 2017
  • Enhanced privacy - Delayed, ETA Q4 2017
  • Payment integration support - Work-in-progress, ETA Q4 2017 Each of these roadmap items is discussed in greater detail below.

Hard fork voting

Hard fork voting is our first major feature since Decred was released in February 2016. Further, it is a cryptocurrency first, in that it is the first “user-activated hard fork” to occur in a production setting. Hard fork voting was made available in our April 26 release of version 1.0.0, voting on the 2 agendas (sdiff algo and LN support) began on May 14, voting completed on the agendas on June 11, and the hard fork consensus change (sdiff algo) activated on July 9. While some cryptocurrencies have used a variation on voting to get feedback from their users on future changes, Decred is the first to deliver a consensus change that comes “pre-wired”, such that the change activates on its own, based on stakeholder voting.

Beyond being the first project to have successfully voted on a hard fork, we have fixed one of our major outstanding problems: a very volatile ticket price algorithm (“sdiff algo” for short). Prior to the change, the sdiff algo would oscillate in a resonant manner, forcing users to purchase tickets during a single 12-hour interval out of each 48 hours, which drove up ticket fees and created a bad user experience for new stakeholders. With the new sdiff algo, these problems have been resolved: fees have fallen back to the minimum levels and users can buy tickets whenever they want since the ticket price is relatively static now.

Now that hard fork voting has been verified to work in production, Decred can continue to make improvements to its consensus code by making episodic changes and allowing stakeholders to vote on whether or not to implement those changes. We will make regular use of this mechanism to fix bugs, optimize and extend our consensus code, but only with explicit stakeholder approval. The next planned hard fork voting agenda is the changes required to support LN.

Public proposal system

The proposal system is a work-in-progress, with a more substantive public announcement coming in the near future. Currently, the backend tools needed for the proposal system are nearly done, but the frontend remains unfinished. Once the backend tools have been tested and verified to work properly, we will release them as part of our next release.

We have published an article about dcrtime, the timestamping component of the system, and the part being worked on currently is the public version-controlled repository. This repository tool will be generic and allow anyone, even people who are not Decred users, to create a time-ordered store of data. We expect that many parties outside Decred can benefit from using such a tool since it is extremely helpful to have a verifiable time-ordering to certain data sets, e.g. internal financial records, corporate entity minutes, property title records, various government documents.

Work will begin on the frontend parts, i.e. website, of the proposal system in the next few weeks, and we will likely have a draft system up and running by end of Q3 2017 for public use.

Decentralized control of DHG funds

Once the proposal system is up and running, it will be straightforward to add “soft” voting to it. By “soft”, we mean that votes can be tallied and DCR from the development organization will flow according to stakeholder voting, albeit without decentralized control of those funds. In principle, this process is straightforward: take a snapshot of the ticket pool as of the proposal going up for vote, then let those tickets vote on this new proposal for a week. While a process like this can work in terms of an off-chain tally for voting in the proposal system, it means that a ton of data would need to be stored on-chain for each outbound payment.

We will be working to explore our options in terms of what can be done to reduce the on-chain footprint of proposal voting over the next few months. The soft voting described above will likely be available before the end of Q3 2017, but the step where we formally decentralize control of the funds needs additional study from both a blockchain efficiency and security perspective. We estimate we will have a solution developed by early Q1 2018.

Lightning network support

As part of our first hard fork vote, stakeholders voted on whether or not to start working on LN integration, which was a “soft” signaling issue. Similar to the sdiff algo change, there was roughly a 98% vote in favor of this agenda. In the future, we will assess stakeholder sentiment via the proposal system, so we can avoid on-chain voting for non-consensus issues.

Since btcd, the upstream project from dcrd, has almost all the code needed to support LN, it is a matter of syncing commits from btcd to dcrd to support LN. That said, this process is rather involved, due to the changes that were made to create dcrd. We estimate that these changes will be integrated and ready for stakeholder vote in Q4 2017.

Improved GUI wallets

A lot of progress has been made with GUI wallets since January. Both Decrediton and Paymetheus support all basic staking and voting functions, and Decrediton supports automatic ticket purchasing. Most dcrwallet features are now available in Decrediton and Paymetheus, with the exception of solo staking support. Lack of solo staking support from the GUIs is intentional because of the user experience problems that come with missing votes due to misconfiguration.

A number of stakeholders have requested more visibility into their history of their ticket purchases and voting, so we will be adding a view for that. Once LN integration is further along, we will need to add support to the GUI wallets for opening and closing channels. We estimate to have a GUI wallet that is feature-complete in early Q4 2017.

RFP process change

The cutover to a contractor-based versus project-based system for paying project contributors has been a serious success. We have found it much easier to work with contractors who have an ongoing role than with contractors who sign up to perform a narrow task or project. As of the original roadmap announcement, there were 8 of us at Company 0 working on Decred, and now we have roughly 30 people actively working on Decred in a given month. We still have quite a bit of development organization funds to spend on more contractors, over USD 300,000 a month, so we have a lot more growing to do.

Since January, we have made substantial improvements on the marketing, design and documentation fronts. From a strategy perspective, we will be intensifying our focus on marketing throughout the remainder of 2017.

Presence at events

We have steadily increased our presence online, at meetups and conferences over the past 7 months. I gave a talk at Coinbase in March and a couple of local blockchain meetups in Illinois, and have talks at a couple larger events planned in Q3 and Q4 2017. Dave Collins, other contractors and I have given interviews online to various cryptocurrency podcasts. Decred contractors attended Consensus and Defcon conferences and did some guerilla marketing.

Enhanced privacy

While the original roadmap targeted 2017 late Q2 or early Q3 for starting work on privacy enhancements, we will be delaying the start of this work to Q4 2017. We are fully occupied with developing other parts of Decred, and in order to make meaningful progress on the privacy front, we need to free up developer time. We will publish a series of articles explaining our approach in the run-up to announcing our privacy enhancement plan.

Payment integration support

The internal work we can do to get Decred integrated as a payment method has started only recently. However, we expect that we can deliver plugins to allow most online merchants to accept decred directly as a payment method by the end of Q4 2017. Both CoinPayments and Wirexsupport Decred, but this support depends on your jurisdiction and local fiat currency. We will be seeking to get additional payment processors added throughout the rest of 2017.

Conclusion

We are making steady progress towards completing the majority of the 2017 roadmap items this year. As an organization, we’ve come a long way in a short time and we’ve got a lot more growing to do. If you have any questions, ideas or comments about this roadmap update, I encourage you to comment in the forum thread.