LND - version 0.1-alpha
We’re very excited to announce the release of v0.1-alpha of the
Lightning Network Daemon (lnd)! This release marks a major milestone for the
Lightning Network as well as Bitcoin as a whole. With this release, lnd stands
as the most feature-complete implementation of Lightning yet and is now ready
for public testing by developers!
The signed release itself can be found in our Github repo.
The daemon is a full implementation of Lightning, capable of: opening channels with peers, closing channels, completely handling all cooperative and non-cooperative channel states, maintaining a fully authenticated and validated channel graph, performing pathfinding within the network, passively forwarding incoming payments, and sending outgoing onion-encrypted payments through the network.
In this post, we’ll take a brief tour of some of lnd’s high-level
architecture, the exposed developer APIs, lnd’s usage of the upcoming segwit
upgrade to Bitcoin, and finally lnd’s network capabilities.
Golang
The entirety of the lnd codebase has been built from scratch using
Go, a new systems programming language that makes it
easy to build simple, reliable, and efficient software. We chose Go due to its
first-class language-level support for concurrency, expansive standard library,
memory safety, and simple language design. The last point holds significance as
we’ve developed the codebase for lnd with readability in mind above all.
Our goal is to make it as easy as possible to dive into the code either just to learn about the Lightning Network protocol at a deeper level, or to start contributing pull requests to the project. The codebase has extensive internal documentation in the form of literate programming-inspired comment blocks and an established testing infrastructure as we optimize for developer-time rather than machine-time.
Any major Bitcoin codebase requires a solid, easy to use, and well-tested set
of underlying libraries to interact with the network to perform routine tasks
such as transaction generation and signing, script generation, watching the chain
for relevant transactions, etc. Our Bitcoin library of choice is
btcsuite, the very set of libraries that powers
btcd, the full-node implementation which
is also written in pure-golang.
With this initial release, lnd is dependent on btcd as a direct source to
the blockchain in order to fully manage channels and respond to relevant
on-chain events. We have a new Lightning compatible lite-client node for
Bitcoin in the works that will make the dependency optional in a future
release. In addition to utilizing the set of btcsuite libraries, several of our
developers such as roasbeef also contribute back
to the project as it’s a critical piece of Bitcoin infrastructure.
Developer APIs
lnd exposes a high-performance, efficient, and flexible RPC layer which is
powered by gRPC: a cross-platform open-source RPC
framework based on HTTP/2 and
protobufs. gRPC is able to
generate language-specific client-side libraries that allow for application
developers to seamlessly drive lnd from the comfort of their programming
lingua franca. Using this set of client libraries, interacting with lnd is as
easy as manipulating objects in their chosen language. At the time of this
release, the supported languages are: C++, Java, Python, Go, Ruby, G#, Node.js,
Objective-C and PHP.
In addition to providing a native-language client accessibility layer, lnd
also exposes an HTTP-REST interface that has the same capabilities as the gRPC
interface minus the bi-directional streaming RPC calls that gRPC provides.
Lightning Channels – Segwit Inside
Individual payment channels composed as a series of interconnected links are
what make the Lightning Network possible. lnd’s channel design currently
utilizes the upcoming Bitcoin upgrade: segwit. Although alternative less-ideal channel
constructions are possible without segwit, by utilizing segwit we’re able to
deploy the most efficient, flexible, and safe channel design. Additionally, the
script upgrade capabilities created by segwit provide a path for upgrades to
Bitcoin that will improve the privacy and efficiency of Lightning. Examples of
such improvements include Elliptic-Curve Schnorr Signatures and unlocking new
op-codes that allow for more private end-to-end payments over Lightning by
randomizing the payment hash along the route.
Three very important features of Lightning enabled by segwit include: Unlinkable Outsourced Channel Monitoring, infinite channel life time, and the two-stage HTLC scheme proposed by Mats Jerratsch (later modified by Tadge Dryja). Without segwit, fully-automatic channel outsourcing that includes the broadcast of a transaction that claims all funds in a contested channel by the outsourcer isn’t possible. This is because without a malleability fix, the transaction ID of the commitment transaction can’t be known ahead of time. Similarly, the two-stage HTLC scheme greatly improves the usability of Lightning by allowing a long revocation delay with a short payment delay isn’t safe to deploy without segwit.
lnd’s internal wallet is fully segwit-aware. The wallet is capable of segwit
nested
p2sh
addresses, which look like regular p2sh addresses, and also native segwit
addresses, which are more efficient and provide a greater degree of
scalability. lnd implements BIP
142, which
defines an address format for native segwit addresses. These addresses can be
used to send money between instances of lnd or software that supports the BIP
such as bcoin. On testnet, a native BIP
142 p2wpkh address looks like:
QWyzAWWPYUgdc6j6HxQpgvqKtyBo4xYjBkwr
Onion-Routed Micropayments
The Lightning Network enables instant, end-to-end secure micropayments that
leverage a technique called the HTLC, or Hash-Time-Locked-Contract. Within
lnd, all outgoing payments are dispatched using a modified version of
Sphinx,
which allows us to send payments across the network that are encrypted
end-to-end. There is no support for sending payments with plaintext routes,
meaning privacy is the default, as it should be.
The payment flow on Lighting is very similar to the flow on traditional
financial infrastructure such as PayPal or Stripe: the payee creates an
Invoice and sends that to the payer, who then fulfills the payment by sending a
payment through the network. lnd provides a preliminary payment request
encoding scheme
that allows users to easily communicate payment conditions out-of-band. A
fully encoded payment request includes: the destination’s public key, the
payment hash, and the value of the payment. A sample encoded payment request
looks like:
ycyr8brdjic6oak3bemztc5nupo56y3itq4z5q4qxwb35orf7fmj5phw8bx148zzipg3rh6t1btadpnxf7z1mnfd76hsw1eaoca3ot4uyyyyyyyyydbibt79jo1o
Peer-to-Peer Network
All communications between lnd nodes are end-to-end encrypted by default using a
modern cryptographic messaging
transport
derived from the Noise Protocol
framework. As a result, no information,
not even the initial version handshake, is transmitted in plain-text amongst
lnd nodes. Once nodes connect, they begin to exchange authenticated node
and channel data which are periodically gossiped throughout the network. All
advertised channels carry a channel authentication proof which proves that the
channel is anchored in an unspent output, and also binds the multi-sig keys
embedded within the Bitcoin blockchain to the public key identities of the
peers in the Lightning Network layer.
Once a node has a complete view of the channel graph, it’s able to passively forward incoming HTLCs according to the forwarding instructions embedded within the onion-encrypted routing information. Path finding for outgoing payments uses a set of heuristics to select a path with sufficient payment flow capacity to carry the payment and which minimizes the required cumulative time-lock and then required fees in that order.
The specification for the authenticated gossip network implemented within lnd
can be found
here
within the Lighting Network
specifications.
Lightning Network Specifications
The set of documents defining the Lighting
Network are called BOLTs:
Basis of Lightning Technologies. lnd doesn’t yet fully implement all of the
behavior outlined within the specifications. The latest state of our
implementation of the BOLT’s can be tracked within our
README.
In an upcoming release we aim to achieve full BOLT compliance as a preliminary
step, with interoperability with the other Lightning implementations coming at
a later date.
Contributors
This release of lnd is the combined work of developers from around the world
and includes contributors from Lightning Labs, Bitfury, Blockchain Lab,
Chaincode Labs, and MIT DCI. The full list of contributors (in alphabetical
order by first name) is:
- Aleksei Ostrovskiy
- Alex Akselrod
- Andrew Samokhvalov (andrew.shvv)
- Bryan Bishop (kanzure)
- Bryan Vu
- Christopher Jämthagen
- Evgeniy Scherbina
- John Newbery
- Joseph Poon
- Mykola Sakhno
- Olaoluwa Osuntokun (roasbeef)
- Riccardo Casatta
- Paul Capestany
- Slava Zhigulin
- Tadge Dryja
Developers, Developers, Developers!
We look forward to engaging new developers as they tinker with lnd to create
novel Layer-2 application on top of the Lightning Network and also get a feel
for what’s possible with this new technology. We’ve secured the #lnd channel
on freenode as a place dedicated to discussing lnd-related development and
support.
If you’re also fascinated by the intersection of distributed systems, peer-to-peer networks and applied cryptography we’re exploring with Lightning, then Lightning Labs is hiring for full-time positions. If interested, email laolu32 at gmail.com!