The Lightning Network Daemon (lnd) has released vo.1-alpha, calling it a milestone as Lightning’s most feature-complete implementation, ready for public testing, the Lightning Network Community blog announced.
The implementation is able to open and close channels with peers, maintain a fully authenticated and validated channel graph, fully handle all cooperative and non-cooperative channel states, conduct pathfinding within the network, passively forward incoming payments, and send outgoing onion-encrypted payments through the network.
The lnd code base was built using Go, a systems programming language that allows for simple, efficient and reliable software. The team selected Go on account of its first-class language-level support of concurrency, extensive standard library, simple language design and memory safety.
Above all concerns, the code base has been developed with readability in mind. The goal is to make it easy to dive into the code to learn about the protocol at a deeper level or to begin contributing pull requests to the project.
The code base includes extensive internal documentation through literate-inspired comment blocks and a solid testing infrastructure as the team optimizes developer time rather than machine time.
A major bitcoin code base needs easy-to-use and well-tested underlying libraries to work with the network and conduct routine tasks like script generation, transaction generation and signing, observing the chain for relevant transactions and more.
The bitcoin library of choice is btcsuite, which powers btcd, the full node implementation that is also written in pure-golang.
lnd depends on btcd as a direct blockchain source to completely manage channels and to respond to significant on-chain events. There is a new Lightning compatible lite-client node being developed for bitcoin to make the dependency optional.
Several developers including roasbeef contribute to the project in addition to the utilizing the btcsuite libraries.
An efficient, high performance and flexile RPC layer powered by gRPC is exposed. This is a cross platform, open-source RPC framework that is based on protobufs and HTTP/2. gRPC can generate language-specific, client-side libraries enabling application developers to drive lnd from their programming lingua franca.
By using these client libraries, interacting with lnd is as easy as manipulating objects in their chosen language. Supported languages include Python, Ruby, Go, Java, C++, Objective-C, Node.js and PHP.
lnd, along with providing a native language client accessible layer, exposes an HTTP-REST interface containing the capabilities of the gRPC interface without the bi-directional streaming RPC calls that gRPC provides.
The Lightning Network is made possible by individual payment channels composed as a series of interconnected links.
The channel design of lnd utilizes Segwit, the upcoming bitcoin upgrade. While less-ideal constructions are possible without Segwit, it allows deployment of the safest, most flexible and efficient channel design. The script upgrade capabilities that Segwit creates offer a path for bitcoin upgrades to improve Lightning’s efficiency and privacy. Such improvements include Elliptic-Curve Schnorr Signatures, as well as unlocking new op-codes allowing more private end-to-end payments by randomizing the payment hash over Lightning along the route.
Important Lightning features that Segwit enables include infinite channel life time, unlinkable outsourced channel monitoring, and the two-stage HTLC scheme that Mats Jerratsch proposed (which Tadge Dryja later modified). Fully-automatic channel outsourcing including the broadcast of a transaction claiming all funds in a contested channel by the outsourcer is not possible without Segwit. Without a malleability fix, it is not possible to know the transaction ID for the commitment transaction ahead of time. In addition, the two-stage HTLC scheme improves Lightning’s usability by enabling a long revocation delay with a short payment delay, which isn’t safe to deploy without Segwit.
The lnd internal wallet is fully Segwit aware. It is capable of Segwit nested p2sh addresses that look like regular p2sh addresses, as well as native Segwit addresses that provide a greater level of scalability and are more efficient.
lnd deploys BIP 142 that defines an address format for native Segwit addresses that can send money between lnd instances or software supporting the BIP like bcoin. A native BIP 142 p2wpkh address on testnet looks like this:
The Lightning Network allows end-to-end secure micropayments which use the HTLC (hash-time-locked-contract) technique. All outgoing payments within lnd get dispatched using a modified Sphinx version that allows encrypted end-to-end payments to be sent across the network. With plaintext routes, there is no support for sending payments, meaning privacy is the default as it should be.
Lightning’s payment flow is like the flow on a traditional financial infrastructure like Stripe or PayPal. The payee creates an invoice they send to the payer, who fulfills the payment by sending it through the network. lnd offers a preliminary payment request encoding scheme allowing users to relay payment conditions out of band. A fully-encoded request includes the payment’s hash, the destination’s public key and the payment’s value. A sample such request looks like this:
Also read: Without Segwit there is no Lightning Network
Communication between lnd nodes are end-to-end encrypted by default with a modern cryptographic messaging transport based on the Noise Protocol framework. No information, including the initial version handshake, transmits in plain text among the lnd nodes. When nodes connect, they exchange authenticated channel and node data that are gossiped periodically throughout the network.
Advertised channels all carry a channel authentication proof that verifies the channel is anchored in an unspent output. The proof also binds the multi-sig keys that are embedded in the bitcoin blockchain to the peers’ public key identities in the Lightning Network layer.
When a note has a full view of the channel graph, it can passively forward incoming HTLCs based on the forwarding instructions embedded in the onion-encrypted routing data. Pathfinding for outgoing payments uses a set of heuristics to choose a path with sufficient payment flow capacity to send the payment and minimizes the necessary cumulative time lock and necessary fees in that order.
The authenticated gossip network specification deployed within lnd is available within the Lightning Network specifications.
Documents defining the Lightning Network are called BOLTS (Basis of Lighting Technologies). lnd does not presently fully deploy all the behavior outlined in the specifications. The most recent state of deployment can be tracked within the network’s README.
The team plans to achieve full BOLT compliance as a preliminary step in an upcoming release with interoperability, with more implementations to come.
Image from Shutterstock.