Lightning on the horizon : Three Implementations, more APIs & a Growing World of LApps

The last few months of downside Bitcoin price-action have arguably proved something of a boon in the development activity pushing towards full mainnet Lightning Network deployment. After years of work from many talented developers and computer scientists, the Lightning network has made the transition from a great idea to a fascinating active project, with multiple implementations of Lightning network clients now live on the Bitcoin mainnet, and all conforming to the same agreed protocol. In the three years since Joseph Poon and Thaddeus Dryja released their Lightning Network white paper, there has been much development behind the scenes, which has rapidly come to fruition over the last eight months, since the requisite, yet controversial, segregated witness (segwit) transaction malleability fix finally became active on the Bitcoin network in late August 2017.

Innovation continues apace, with application developers now building upon the solid foundations provided by the three primary Lightning clients. As outlined by Blockstream last month, there are an increasing number of Lightning Applications, or LApps, built upon their c-lightning client and Lightning Charge API. Acinq have recently unveiled their Eclair wallet for Android, which functions as a lightweight, outbound-only Lightning app which can send payments but isn’t able to receive or forward them.

A Lightning Network node is needed to properly manage all channels, deal with routing payment messages and fully utilise the impressive capabilities of Lightning. The three main open-source Lightning node implementations are as follows:

Elements Project – c-lightning (C)

Acinq – eclair (Scala)

Lightning Labs – Lightning Network Daemon (Go)

The teams behind the three different implementations have been collaborating for some time in developing their clients, such that they all conform to an agreed set of standards, compiled in a set of documents known as BOLTs or the Basis of Lightning Technology. This has been vital in allowing for interoperability between the different clients, whilst also enabling each to be created and developed independently. The agreed collection of BOLTs should make it significantly easier for new developers to work with Lightning in future, whilst ensuring their creations maintain compatibility with the existing network. The three Lightning teams all announced their combined work on the specification documents just after segwit activation last August, and also released a suite of more in-depth cross-integration tests to ensure the clients function as intended. It is upon this solid groundwork that has been established, that a wave of useful applications can now be built.

San Francisco based Lightning Labs, headed by CEO Elizabeth Stark and CTO Olaoluwa Osuntokun (Roasbeef), are responsible for the LND software, which is written in a programming language called Go (Golang). LND can use either the Bitcoin Core wallet (bitcoind), or a Go implementation known as btcd, to provide a Bitcoin full-node with an up-to-date blockchain. The LND package provides all of the essential functions of a Lightning Network node such as handling the opening and closing of payment channels, and managing transaction routing across the network. The mainnet beta version of this client was released in mid-March and is now being tested live with real funds. The team have also been working on a new experimental form of light client known as neutrino, which is a novel approach to working with Bitcoin without storing a full copy of the growing blockchain and tackles some of the drawbacks of the existing Bitcoin light clients. This has great potential for next generation, lightning-enabled mobile and light desktop wallets, such as Jack Mallers’ Zap.

Parisian operation Acinq are one of a number of successful Bitcoin-focussed enterprises in the French capital, and their Lightning client known as eclair (French for Lightning) is also now in a beta phase. The eclair client uses bitcoind, the Bitcoin Core full-node wallet daemon, for wallet operations. This means eclair accesses the local bitcoind addresses to fund new Lightning payment channels, and pays out funds to them upon the closing of a channel. The company also set up the Starblocks store as a test application using eclair, allowing more technical users and developers to try out sending Lightning payments in a realistic scenario. Acinq have also developed a managed lightning payment API solution called Strike, as a simple way for merchants to accept lightning payments, with Acinq acting as an intermediary to collect funds and handle the technicalities.

Rusty Russell and Christian Decker lead development on the Blockstream-associated c-lightning implementation, which is itself approaching a mainnet beta. As a long-time Linux kernel developer, Russell brings a wealth of open-source development experience to the challenge of the Layer 2 scalability for Bitcoin, and is joined by Decker, who worked on duplex micropayment channels as a Bitcoin scaling solution during his time with Distributed Computing group at ETH Zurich university. C-lightning again requires bitcoind, and alongside the Lightning Charge payment app, it offers exciting capabilities even beyond the handful of exciting use-cases highlighted by the “week of LApps”.

There is arguably much to gain from having three alternative implementations of the core Lightning Network protocol from the outset. The early establishment of a standard for protocol fundamentals that all groups can comply with, appears to have facilitated a great pace of development, and cross-compatibility tests indicate that the main clients are already working correctly with one another across a handful of expected test cases. This growing development activity on the layer-two scaling solution that Bitcoin has needed for some time, should now serve as inspiration for more and more developers to craft innovative platforms built upon all of the different Lightning Network node software implementations.