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.

read more

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.

read more

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.

read more

Lightning Network (“LN” for short) is a recently-proposed, and even more recently implemented, low-latency off-chain micropayment system that can work with Bitcoin or other similar cryptocurrencies, such as Decred. Since LN makes liberal use of smart contracts, the details of how it works are, unsurprisingly, complex. To make LN more tangible from a non-technical perspective, we will view it through the lens of practical engineering considerations and the concepts that drive those considerations.

The utility of LN is driven by several major considerations in the context of cryptocurrencies:

• low-latency payments - Many potential use cases for a modern system of transmitting value require a low latency, e.g. point-of-sale purchases. Waiting for an on-chain transaction places unreasonable constraints on both the time between blocks in a blockchain and what is considered an acceptable delay for payment to confirm.
• deferred settlement - In order to minimize the number of transactions that flow between banks, banks make use of a net settlement process wherein multiple transactions between a given pair of banks are consolidated into a single transaction at the end of each day. Since cryptocurrencies effectively allow you to “be your own bank”, having a similar deferred settlement process substantially reduces transaction load on the blockchain and reduces transaction fees, allowing it to scale much better as the transaction rate increases.
• privacy enhancement - A blockchain for any publicly available cryptocurrency is necessarily a public ledger, even when the details of ledger entries are obfuscated by cryptography. By taking transactions off-chain, those transactions have their privacy enhanced simply by merit of not being in the public ledger.
• cross chain atomic swaps - Reliance on centralized exchanges is a major weak point of cryptocurrencies, whether we are talking about exchanges that handle fiat currencies or that handle cryptocurrencies exclusively. Cross chain atomic swaps will create liquidity between Decred and other cryptocurrencies without the counterparty risk that exists between users and centralized exchanges.

The benefits of LN are clearly quite substantial, per the considerations above. However, there are some notable weaknesses with LN that users need to be aware of:

• counterparty theft - Since LN transactions occur off-chain, it is possible for a counterparty in a payment channel to attempt to steal the funds in the channel, but this can only succeed under certain conditions and is preventable. Conventional on-chain transactions do not suffer from this problem because they are written directly to a blockchain, an immutable ledger.
• centralization of nodes - LN transactions are handled by a network of nodes that is separate from the underlying blockchain, and there is potential for these nodes to become centralized, despite them not having custody over coins. Operating a busy LN node is a potentially expensive operation, creating a barrier to entry for operating such a node and correspondingly increasing centralization.

Despite these weaknesses, I believe that the benefits of LN far outweigh the potential downsides. Each of these considerations is addressed in greater detail below.

read more

The 1.0.0 release of Decred will include the Decred Change Proposal, DCP-0001, the replacement of the existing stake difficulty, i.e. ticket price, algorithm as the first hard fork voting issue on mainnet. This is a major change and is being proposed to address the various issues that have come up with the stake difficulty (“sdiff” for short) since launch in February 2016. Decred launched with a sdiff algorithm that accomplished its basic design goal, which was to keep the ticket pool near its target size, but we have come to recognize several shortcomings and problems with the existing algorithm that were not apparent until it went into production use. The main problem is that a single interval where all the tickets are purchased leads to a persistent resonant mode, where very limited price exploration occurs, prices swing wildly and stakeholders compete on ticket fees. Replacing the existing sdiff algorithm with a new algorithm will lead to less wild variation in the ticket price and avoid the various problems associated with the existing algorithm. The properties of an ideal sdiff algorithm are related to:

• pool size stability
• price exploration
• simplicity
• relaxation time
• steady state behavior

which are explained in detail below. Currently, there are a few proposed sdiff algorithms from project developers and participants (raedah, animedow, and others) that we will be evaluating using a simulation harness developed by Dave Collins, dcrstakesim.

read more