Rather than settling for governance infrastructure that is just good enough to get the job done, we opted to create what we consider to be the ideal infrastructure for self-governance of a cryptocurrency. We call our system for storing governance data Politeia, which is based on the ancient Greek term, meaning “a system of government”. Politeia is a system for storing off-chain data that is both versioned and timestamped, essentially “git, a popular revision control system, plus timestamping”. Instead of attempting to store all the data related to Decred’s governance on-chain, we have opted to create an off-chain store of data that is anchored into Decred’s blockchain, minimizing its on-chain footprint. While we will use it first as the basis for our proposal system, it has been developed as a generic tool that allows its users to create and maintain arbitrary data in a version-controlled and timestamped environment. Politeia can be used without holding any decred, although it does depend on using a dcrtime server for creating timestamps. In addition to making the initial release of Politeia, we are excited to announce a competition for projects based on Politeia, with winners announced at an event in Austin, Texas on December 1st, 2017. The prizes for 1st, 2nd and 3rd place will be the equivalent of USD 10,000, USD 5,000 and USD 2,000, respectively, paid in decred.
As many of you know, yesterday marked the first cross-chain atomic swap between Decred and Litecoin. This is an important step in a direction that allows users to conduct trustless, cross-chain, over-the-counter (“OTC”) trades without a third party. This disintermediates the exchange process between cryptocurrencies that support these swap transactions. We have created some simple prototype tools under the atomicswap repository, dcratomicswap, btcatomicswap and ltcatomicswap, to allow Decred, Bitcoin and Litecoin users to swap between DCR, BTC and LTC using on-chain atomic swaps. These tools were built for those who we have the means at hand to disintermediate the exchange process: transaction script and OP_CLTV support. It is worth noting that these tools do not address the issue of order book management that is typically performed with full-featured exchanges. There are some privacy and transparency consequences related to on-chain atomic swaps that are not present with centralized exchanges. As of this announcement, the tools are text-based, but we will be integrating this into the Decrediton GUI wallet in a future release. The process for on-chain atomic swaps is described in more detail below.
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.
Over the past several months, we have seen Decred contractors grow from a group of 10 to a group of over 25 individuals. This growth has been entirely organic, and while the growth has been significant, we are looking to further grow our ranks in the immediate future. Since Decred has a steadily accumulating development subsidy at a rate of DCR 21,456 per month, as of June 2017, this means there is roughly USD 430,000 available per month for project-related expenditures. Currently, we are spending approximately USD 100,000 per month on development, marketing and design, which is less than 25% of the current development subsidy rate. In order to accelerate the development of Decred infrastructure, we are aiming to spend most or all of the monthly development subsidy on an ongoing basis.
While a conventional business might take this as an opportunity to go on a hiring spree, Decred is not a conventional business and will take a different approach. The scope of a cryptocurrency project is far larger than that of most conventional businesses, which leads to a wide variety of tasks that need to be performed as part of building it out. Beyond having a large scope, a cryptocurrency project that funds its own development must necessarily do so by paying its various contractors using its own tokens, which complicates the typical process of hiring employees that occurs with conventional corporate entities. To date, Decred has been operating more as a collective than a corporate entity, where interested parties show up and pitch in, helping out where there is a need using whatever skills they have. Since most Decred workflows are public, people or corporate entities who are interested in becoming paid contractors can show up, do a bit of work, see if they like doing it, and then get paid for their work, assuming the existing contractors approve of their work product. Rather than focusing on resumes, credentials and interviews, we are far more interested in what a prospective contractor can and will do for the project, which can only really be evaluated after it occurs. In what follows, I will go into greater detail about the caveats of becoming and being a contractor for Decred.
Per the 2017 Decred Roadmap, one of the major deliverables is a proposal system that allows users to participate in the governance of Decred. The proposal system will have 2 main components: a blockchain-based timestamping service and a public version-controlled repository for proposal data. The subject of this entry is dcrtime, the timestamping component. Dcrtime was written by Marco Peereboom over the past couple months and is the result of collaboration between Marco, Jake Yocom-Piatt and Dave Collins. The primary motivation for dcrtime is the desire for the proposal system to have maximum transparency and accountability, while having a minimal onchain footprint. In terms of its onchain footprint and overall design, dcrtime draws on the work of Peter Todd’s opentimestamps, which allows a nearly unlimited number of hashes to be timestamped onchain with the inclusion of a single merkle root in a transaction. The process used by dcrtime can be summarized as follows:
- allow users to submit 32-byte hashes, which are accumulated, organized into a merkle tree and hashed down to a merkle root
- create an episodic onchain transaction that includes that merkle root
- allow users to verify their data is timestamped by responding to queries by hash with the corresponding merkle root, transaction hash and a merkle path for that hash once the transaction is mined
Although dcrtime has been designed as a component of the proposal system, it is expected to have generic utility as a public timestamping service. Any third party that is interested in using dcrtime to generate externally verifiable timestamps can do so free of charge by using our public mainnet server. We expect this to be particularly useful in scenarios where transparency, accountability and time-ordering are of key importance, in either a public or a private context, e.g. computer security, data integrity and various compliance contexts. A more detailed discussion of dcrtime can be found below.