Lightning Network in Practice

Lightning Network in Practice

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

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