A New Ticket Price Algorithm

A New Ticket Price Algorithm

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

2017 Decred Roadmap

2017 Decred Roadmap

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

zkc: Secure Communications

zkc: Secure Communications

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

Upgrading Consensus

Upgrading Consensus

Over the next few releases, Decred will enable Proof-of-Stake (“PoS”) miners to vote on proposed consensus changes. This voting will allow Decred users to exercise sovereignty over whether or not to accept hard fork changes, in addition to making other important decisions. Enabling this decision making requires versioning several subsystems: block headers, vote transactions and transaction scripts. Versioning these subsystems allows for reliable and relatively smooth hard forking on an ongoing basis, meaning Decred can continuously upgrade its consensus code provided the PoS miners agree with each of the changes. Further, we have added a series of full-block consensus tests that are automatically run on every pull request to the consensus daemon, dcrd. Before this process can commence, we must implement a soft fork to add and enforce vote transaction versioning, and enforcement will occur as part of the next release, 0.7.0. Decentralizing the larger-scale decision making is the first step of several towards making Decred into a robust and fully operational decentralized autonomous organization (“DAO”).

read more

Clearing the Route

Clearing the Route

The most difficult groundwork required to clear the route to distributed decision making via Proof-of-Stake (“PoS”) in Decred is nearing completion. While many users and interested outsiders are understandably keen to see a steady stream of new features, we decided to instead focus on making important structural upgrades before beginning work on the more substantive features that make use of Decred’s hybrid PoW/PoS consensus system. The major hurdle of upgrading Decred’s chain database format and related code is almost behind us, and it is accompanied by a substantial performance increase when both doing the initial chain sync (roughly 5x faster, depending on hardware) and handling many concurrent RPCs to the chain daemon. With the database hurdle cleared, the process of steady incremental decentralization can continue without further significant detours.

read more