The Lightning Network peer-to-peer payment protocol promises to deliver the scalability, privacy and speed needed to spur crypto’s mass adoption. At the end of 2017, Decred activated the on-chain consensus rules required to develop DCR Lightning Network. The approval of this change was nearly unanimous at 99.50%, and developers began working on building the foundation for LN features.

Today, the Decred development team is proud to unveil this pivotal work: the official testnet release for dcrlnd - our Lightning Network wallet and node software!

After months of hard work and several changes across the whole software stack (including the recent on-chain vote) we’re finally ready to present the software for the wider Decred community so we can start to seriously grow our LN infrastructure. We need your help to make this happen. The more participants we have that are actively improving the testnet, the faster we’ll get to the mainnet.

To test our LN network, follow these three easy steps:

1. Access the main project repository on GitHub
2. Download the code
3. Compile it, and start testing!

This post will highlight what we accomplished, summarize what was required to get to this stage and point out the short- and long- term directions we’ll aim to take the software.

Before we begin, we’d like to thank the lnd contributors, of which there are too many to individually name (seriously - go look at their contributors page) but without whose work we certainly wouldn’t be here. We look forward to collaborating in improving the whole Lightning Network ecosystem as a whole!

TL;DR

• The decred lnd daemon (dcrlnd for short) is ready for testnet usage. It includes its own version of an on-chain wallet, so do not use the same seeds as your regular wallet.
• Decrediton can connect to it, and present a basic UI for interacting with the LN network.
• The branch point from upstream lnd was January 10th, 2019 (around v0.5.1).
• All code, tests and auxiliary packages were ported into decred-specific repos.
• All unit and integration tests of the upstream project plus our internal manual testing are passing.
• Expect rapid flux of changes as the wider community starts to use the software and we start to get feedback on it.
• We plan to make the LN software more Decred-friendly and implement many exciting improvements (such as schnorr signatures which are already available in Decred).
• Cross-chain channels are not possible yet.

Current State of Affairs

I’ll talk about both the current state of the LN node (dcrlnd) and Decrediton integration for end-user support.

LN Node

The main accomplishment of this release is the port of the original lnd daemon to use the Decred ecosystem, which is now called dcrlnd.

This daemon is responsible for

• Connecting to the P2P lightning network;
• Discovering the existing topology of peers and channels;
• Managing its own channels;
• Creating invoices (payment requests);
• Sending payments across the network to any reachable peer.

While there are many details involved in exactly how LN works and explaining all of it would take quite a while, all of the existing material for the Bitcoin LN is currently also applicable to Decred’s version, so all the existing tutorials and explanations can be used (with the minor changes noted throughout this article).

The dcrlnd daemon currently instantiates an internal dcrwallet to perform its functions. For the moment, we recommend that you do not use any seeds from existing decred wallets. The seed format for the regular dcrwallet and dcrlnd are different anyway, but you could use a corresponding hex seed, which would most certainly cause inconsistencies between the wallets.

In order to perform its duties, the LN daemon requires a functioning dcrd node with the transaction index enabled (that is, dcrd must be initiated with --txindex argument). Also note that SPV mode (also referred as neutrino in the original lnd) is not supported at the moment.

After startup, the daemon will attempt to bootstrap itself but it’s likely that in these first few weeks it will be unable to do so. Users will have to manually connect to other peers in the network to open channels, and we’ll provide faucets and public testnet nodes for that. Once we have a big enough network, we’ll setup the proper bootstrapping facilities as defined by BOLT #10.

After a dcrlnd node is online and unlocked, it can be interacted with using almost the exact same api as the original lnd software. The main difference in the api is the change from weight/kiloweight/sats/millisats to the respective Decred units (bytes/kilobytes/atoms/milliatoms).

For command line users, the interface tool is named dcrlncli (after the original lncli). We have internally tested some of the existing LN tools (UIs, graph explorers, etc) that integrate via the lnrpc interface (that is, the grpc api offered by the LN daemon) and most of them could be used as-is with the small appropriate corrections.

The existing unit and integration tests of lnd were also ported and are all passing. We’d like to point out the excellent work the lnd developers have done on this front; without these extensive set of tests to ensure compatibility it would be much harder to detect all regression points and to assert that the daemon is working correctly.

Decrediton Integration

We have already done an initial integration between Decrediton and dcrlnd. This integration exposes the basic functionality needed to operate an end-user oriented LN wallet; chiefly:

• Adding/withdrawing funds to the on-chain side of the LN wallet;
• Opening/closing channels;
• Creating/sending payments.

Due to its nature of being an independent wallet, in order to open funded channels users need to first fund the LN wallet with coins from their original wallet. From the point of view of the original wallet, this appears as a sent transaction (or fund withdrawal). This is a limitation of the current architecture of the dcrlnd node which we hope to address in the near future.

Note that the Decrediton side is not able to initialize LN wallets for the moment; it can only connect to an existing created and unlocked wallet. It also does not expose all the information available via the command line client, so operating hubs with it will be tricky. The GUI should be quickly iterated and the design team will certainly have improvements to present in the next few weeks.

For the moment, you can get a glimpse of how the integration is working by watching the following clip:

Starting in January, we doubled down the porting effort to get dcrlnd ready for a testnet release. This is a sample of the major things that required changing and fixing:

• Fix every single import to point to Decred repos.
• Integration to dcrwallet completely rewritten (btcwallet and dcrwallet already diverged significantly).
• Integration to dcrd significantly rewritten (dcrd and btcd already diverged in many ways).
• Many api tweaks due to evolution of btcd/dcrd and btcwallet/dcrwallet diverging.
• Update to latest bbolt package.
• Complete rewrite of how transaction witness data is handled. Segwit-enabled Bitcoin uses witness stack, witness program and signature script vs Decred only using signature script.
• Complete rewrite of address handling. lnd in segwit-enabled Bitcoin mostly uses np2wkh and p2wkh vs Decred’s standard p2pkh/p2sh script types.
• Tweak of size calculations (due to small changes in how scripts behave in the different networks).
• Move from weight to byte for size calculation.
• Adapt the zpay32/bech32 library to Decred’s needs.
• Rename some structures in the lnrpc package to their Decred counterparts.
• Introduce and use a simulated voting wallet for integration tests.
• Make every single unit and integration test pass.

After all this, we’ve finally reached the point of diminishing returns while working in private and are reasonably confident that Decred’s Lightning Network can work alongside the regular Decred chain.

Future Work

Now that we’ve released a testnet capable dcrlnd daemon, the next major milestone is getting it mainnetworthy.

Right now (as this post is written) it’s not yet possible to run the daemon in mainnet due to the required activation of the fixlnseqlock agenda (which will happen in block 342784, around May 9).

Even after that, it’s worth taking it easy before committing significant funds to a wallet associated with an dcrlnd instance. While the original lnd software has received significant attention over the past few years, any porting effort of the extent we’ve had to make is bound to surface bugs. And while the set of tests provided by lnd is extensive and exercises both positive and negative settlement paths, we still suffer from some testing instability and must work towards ensuring additional test cases relevant to Decred are written.

In terms of the most immediate work to be done, we can include:

• Modify the dcrwallet integration to allow using remote wallets instead of ones embedded in lnd. This would allow a more seamless integration to the existing Decred tools.
• Bring in (some of) the changes made to lnd since the branching point. There’s some really exciting work upstream that we’re eager merge.
• Improve integration test stability so that it consistently passes in the CI server without having to resort to re-running tests.
• Work with the design team to iterate the GUI’s UX.
• Allow use of SPV mode wallets.

And on a longer term horizon, some of the exciting new things we want to bring to our LN infrastructure include:

• Use of schnorr sigs for the multisigs in the commitment and redeeming transactions.
• Implementation of eltoo (possibly introducing the new required signature hash type alongside this).
• Design and implement cross-chain integration to the Bitcoin LN.
• Work with the upstream lnd team to abstract and generalize code to be more chain agnostic.

Backstory: How we Got Here

This is by no means an exhausting review of every single thing done to get to the current stage, but should suffice as a quick overview of all the necessary pieces that had to fall in place.

While the major coding effort to complete the port was done in the past few months (mostly starting in January 2019), earlier changes in dcrd and dcrwallet were required to get to this stage.

A quick bullet-point list of the most important events of the Decred ecosystem as a whole, regarding LN (vote info from voting.decred.org):

• March 6, 2017: On-chain signaling vote for LN support starts.
• June 11, 2017: On-chain signaling vote for LN support locked-in. Since this vote didn’t actually contain any consensus rule changes, we consider this as the time the stakeholders (with 98.61% approval rating) signaled their intent in supporting the development of LN features.
• November 26, 2017: On-chain consensus rules necessary for LN to work were activated, after approval by stakeholders (with 99.50% approval rating).
• May 18, 2018: Initial checkpoint for the dcrlnd port. While this was only the date of the commit, work had already started prior to this.
• December 6, 2018: First version of the fee estimator package merged.
• January 14, 2019: First commit of the major coding effort.
• January 26, 2019: DCP0004 (fixlnseqlocks) agenda introduced to fix a consensus rule implementation issue.
• February 23, 2019: Testnet rules for the fixlnseqlocks agenda activated.
• March 14, 2019: Voting for mainnet fixlnseqlocks started (agenda passed; activation still pending as of this writing).

Testing & Contributing

For those that want to start testing our LN network, you can access the main project repository on GitHub, download the code, compile it and start to test it. The readme file of the repository contains some quickstart directions.

To test Decrediton you can also download the latest LN test branch and build it as usual or use one of the test binaries. Please bear in mind that this is a work in progress therefore do not use in production or with your mainnet wallet seeds.

If you’ve been inspired to contribute in any capacity, please also read our initial documents on contributing to the project and becoming a paid contractor.