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

The time for a new Decred roadmap has finally arrived. While many users have been keen to know where the project is headed in detail, we have intentionally avoided laying out our longer term plans in order to prevent other projects from implementing these ideas before they make it into Decred. I recognize that our approach with Decred runs counter to most other cryptocurrency projects, which often focus much more on hype and marketing than on development and sound engineering. Instead of hyping future work in advance of its completion, we have quietly completed our work and will hype it as it goes into production. Now that we are close to our first major post-launch milestone, hard fork voting, it is a good time to share where Decred will go from here. Here is a summary of what we have planned for Decred in 2017:

• Convert Decred into a stakeholder-directed DAO - While other projects have attempted to create a DAO via a monolithic smart contract, Decred will build a DAO in several steps, ensuring each component works independently before putting it into production.
  • Hard fork voting - Stakeholders will be able to vote on all hard fork changes to Decred, with only those changes obtaining greater than 75% support being activated.
  • Public proposal system - After hard fork voting is in production, we will create an off-chain system where Decred users can submit proposals for future work to be performed by the development organization, Decred Holdings Group (“dev org” or “DHG”).
  • Decentralized control of DHG funds - Currently, the control of DHG funds is centralized, and this will be resolved by creating a system whereby control of these funds is decentralized, e.g. based on stakeholder voting.
• Lightning Network support - The lightning network is the most directly useful application of smart contracts to date since it allows for off-chain transactions that optionally settle on-chain. This infrastructure has clear benefits for both scaling and privacy.
• Improved GUI wallets - We have made substantial progress with GUIs, Paymetheus (Windows) and decrediton (Windows, OS X, and Linux), and will continue to improve the user experience.
• RFP process change - To date, the RFP process has involved giving quotes on deliverable sets, and this system is cumbersome to administrate and maintain. The RFP process will change to one where individuals and businesses will be contracted on a longer term basis to work for the project. As part of the RFP changes, we will be looking for contractors to do marketing, advertising, documentation and community management work.
• Presence at events - With hard fork voting nearly ready for production, we have some legitimately interesting content to discuss at events. Our presence at events will ramp up starting in late Q1 2017.
• Enhanced privacy - Starting in late Q2 or early Q3 2017, we will propose a new initiative to enhance user privacy.
• Payment integration support - Instead of only focusing on Decred from a speculative position, we will support efforts to integrate Decred as a payment method for businesses starting in Q1 2017.

Each of these roadmap items is discussed in greater detail below.

read more

As part of our ongoing effort to “decentralize all the things”, we have developed secure communications software that we are open sourcing today, called zkc. While zkc is not part of the Decred project proper, it is being released as part of our wider effort to increase individual liberty through technology. zkc stands for “zero knowledge communications” and is intended to provide the highest level of communications security balanced with minimal complexity in its code, configuration and usage. The various cryptographic protocols used in zkc draw from other existing secure communications tools, such as Signal and Pond. zkc is a blending of what we consider to be the best parts of both of these projects, and with its initial release, it functions as an asynchronous instant messenger with the ability to push files. It makes use of conventional ECDH TLS, Double Ratchet Algorithm using ed25519, salsa20 and poly1305 primitives, scrypt key derivation function, and SIGMA key exchange. The server and client components, zkserver and zkclient, are designed such that they can both be setup in a matter of a few minutes, and require minimal effort to maintain. For this initial release, zkc builds and runs on most platforms supported by golang, and is entirely text-based. zkc should be considered alpha software as of this initial release.

read more