As of a couple of weeks ago, the first Lightning implementation — lnd — is officially in beta. The second implementation — eclair — followed last week, while the third — c-lightning — is expected to do so soon. As such, theLightningNetwork, the long-awaited Bitcoin overlay network for cheap and instant transactions, is by many of its developers considered safe enough to use on Bitcoin’s mainnet: a major milestone for the technology that has been years in the making.
This is the story so far.
The First Musings
The earliest origins of the Lightning Network can be traced back as far as Bitcoin itself.
The first piece of the Lightning puzzle is a concept called “payment channels.” Payment channels are essentially bitcoin balances between two Bitcoin users, and only two users: the rest of the world does not need to know or care about their mutual balances. Importantly, these balances can be updated without requiring any on-chain Bitcoin transactions; where the balance of one user increases, the balance of the other decreases by the same amount. In effect, this allows both participants to transact between each other, without burdening the entire network with their transaction data.
Once the users are done transacting, they can settle their payment channel by transmitting only one transaction to the network: that transaction pays out to each what they should receive based on their channel balances. To these users’ benefit, this should also mean that the channel updates (“off-chain transactions”) are cheaper because they don’t require mining fees, and are faster because they don’t require blockchain confirmations.
This general idea is arguably as old as the very first Bitcoin software released by Satoshi Nakamoto in 2009. Bitcoin 0.1 included a raw draft of code that would let users update a transaction before it was confirmed:
A rough draft of payment channel code included in Bitcoin 0.1. Source: GitHub
While this code was a rough draft, Satoshi Nakamoto went into more detail about how payment channels could work in private communication with then-bitcoinj developer Mike Hearn.
Several years later, in 2013, Hearn published Satoshi Nakamoto’s explanation of payment channels on the Bitcoin-development mailing list:
Satoshi Nakamoto’s explanation of how payment channels could work, described by Mike Hearn. Source: Bitcoin-dev mailing list
The First Payment Channels
Although the general concept of payment channels has existed for as long as Bitcoin itself, Satoshi Nakamoto’s design was not entirely secure. Most importantly, a user in a payment channel could collude with miners to have an older transaction confirmed, claiming more bitcoin than the channel balance should let him.
A solution to this problem was proposed for the first time in the summer of 2011, after Satoshi Nakamoto had left the Bitcoin project. Bitcointalk forum user “hashcoin” outlined a two-tier payment channel that required users to exchange several partially signed multisignature transactions and transactions with timelocks that depended on one another to be valid. If one participant should disappear, the other could claim all the funds in the payment channel after some time had passed. A downside of this design, however, was that hashcoin's channels could only work in one direction. "Alice" could pay "Bob" an arbitrary number of times, but Bob could not pay Alice through the same channel.
An idea similar to hashcoin’s resurfaced in early 2013, and this time it escaped the theoretical realm. In April of that year, a payment channel concept was described by Jeremy Spilman on the Bitcoin-development mailing list. He had even coded up a proof of concept. This design was, in turn, tweaked by Mike Hearn, after which future Bitcoin Core contributor, Blockstream co-founder and Chaincode Labs developer Matt Corallo turned the concept into working code for bitcoinj by mid-2013.
Another year later, in 2014, Alex Akselrod (now an engineer at Lightning Labs) was the first to propose a bi-directional payment channel. Alice could pay Bob an arbitrary number of times, while, using decreasing timelocks, Bob could pay Alice within the same channel — albeit a limited number of times. As opposed to one-directional payment channels, however, this solution was never actually implemented in code.
The First Payment Network Concepts
Around the same time that the first payment channels were proposed, others — including for example Bitcoin Core developers Peter Todd and Gavin Andresen — were thinking about off-chain payment networks. If Alice could pay Bob through an off-chain transaction, and Bob could pay Carol through an off-chain transaction, then Alice should be able to pay Carol through Bob without requiring any on-chain transactions.
Corné Plooy (now a Lightning developer at Dutch Bitcoin exchange BL3P) had also been working on a payment layer for Bitcoin, which he first proposed as a rough idea in 2011.
An early illustration of Plooy’s payment layer design, which would evolve into Lightning Network precursor Amiko Pay. Source: Corné Plooy
With suggestions added by Bitcoin Core developer and future Blockstream CTO Gregory Maxwell, and Ripple inventor Ryan Fugger (among others), this idea evolved throughouttheyears into a merger of Bitcoin and the original Ripple technology, resulting in the system Plooy called “Amiko Pay.” Earlier drafts of Amiko Pay did not utilize payment channels and therefore injected trust in the system, however: should one user refuse to settle a balance with another user, the latter would have no recourse.
An early payment network proposal that utilized payment channels was proposed by mathematician and future Bitcoin emBassy TLV co-founder Meni Rosenfeld in the summer of 2012. On the Bitcointalk forum, Rosenfeld described a system in which Bob (from the above example) is replaced by a payment processor, with both Alice and Carol as its customers. The payment processor could, in turn, also have channels with other payment processors, with more customers, turning the payment channel network into a hub-and-spoke system.
While such a system did introduce a little bit of trust in the payment processors — they could refuse to forward a payment and keep the money instead — this risk was considered small: the trick would only work for one payment before a customer would notice and stop using the channel. Additionally, bigger payments could be cut into smaller increments so that if one payment processor proved to be unreliable, only a small portion of the payment would be lost.
This solution resurfaced a couple of times throughout the years. Bitcoin Core contributor Peter Todd, for example, published the concept to the Bitcoin-development mailing list in 2014. Payment processor BitPay, meanwhile, published a white paper on similar inter-channel payments (“Impulse”) in early 2015. And a solution like this would actually be implemented by the Swedish startup Strawpay, called Stroem (or Ström), at around the same time — but none of these iterations ever took off in a meaningful way.
The logo of the now-defunct Strawpay micropayment startup. Source: The Internet Archive
A relatively early attempt at establishing a trustless payment channel network was made by Alex Akselrod. First described in a wiki draft in 2013, to be implemented as a proof of concept throughout 2014, Akselrod’s solution went a long way toward solving the problem on a theoretical level. The main problem was that it would still be rather clunky in practice. If a payment were to fail anywhere along the route of a transaction, for example, a user would have no recourse but to wait until the funds were freed through the payment channel timelocks, which could potentially take months.
Meanwhile, by 2015, Plooy’s Amiko Pay had evolved to the point where it could potentially work trustlessly, too. However, his design would have required relatively far-reaching changes to the Bitcoin protocol, to the point where rolling back certain types of transactions would be necessary. While technically possible, it was not obvious whether such changes to the Bitcoin protocol would be adopted.
Later that same year, researchers from the technical university in Zurich (ETH Zurich), Dr. Christian Decker (now at Blockstream) and Roger Wattenhofer, proposed yet another overlay network design in their white paper “A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels.” Their solution relied strongly on timelocks as a sort of “countdown ticker” for payment channel validity, which was combined with a cryptographic trick called an “invalidation tree” for expired channel balances.
Akselrod’s solution, the later drafts of Amiko Pay, and Duplex Micropayment Channels (DMCs) were all similar to the Lightning Network in some ways, and could have worked in their own right by making different trade-offs. If the Lightning Network had not been invented, any of these solutions might have become (the basis of) Bitcoin’s go-to scaling layer instead.
But of course, the Lightning Network was invented.
The Lightning Network
After years of payment channel and network design evolution, all the pieces of the puzzle finally fell together in early 2015.
Thaddeus “Tadge” Dryja — the CTO of smart contract trading platform Mirror — and Joseph Poon wrote a white paper titled “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments,” first published in February of that year.
It proved to be a game-changer.
The Lightning Network white paper, as this publication came to be referred to, proposed several solutions to realize a payment channel network completely trustlessly: no participants could cheat without risking all the money they put up in their channel, while middlemen forwarding transactions would be unable to steal even a tiny bit of it. Additionally, the solution required relatively few changes to the Bitcoin protocol and promised to be more flexible and user-friendly than the alternatives proposed so far.
The key innovation described in the white paper are “Poon-Dryja channels”. Like earlier payment channel designs, Poon-Dryja channels depend on the exchange of partially signed and non-broadcasted transactions. But compared to previous payment channels, these new channels take an additional step involving the exchange of secret numbers, which allow payment channels to be updated in either “direction.” Alice can pay Bob an arbitrary number of times, and Bob can pay Alice within the same channel an equally arbitrary number of times.
Additionally, the Lightning Network leverages Hashed Timelock Contracts (HTLCs). This concept is usually attributed to Tier Nolan and was originally designed for cross-blockchain transactions; for example, to exchange bitcoin and litecoin trustlessly. In the Lightning Network, this solution is instead used to link payments across payment channels.
Poon and Dryja first presented their idea publicly at the San Francisco Bitcoin Devs Seminar in February 2015:
In the months thereafter, during the spring and summer of 2015, Bitcoin’s scaling issue and the block-size-limit dispute turned into a public feud. In the midst of this crisis atmosphere, a series of two conferences was organized for late 2015: Scaling Bitcoin Montreal in September and Scaling Bitcoin Hong Kong in December. In Montreal, Poon and Dryja presented their proposal once again, then both Poon and Dryja gave a second, more in-depth presentation in Hong Kong as well.
Right after this second edition of the conference in Hong Kong, Gregory Maxwell proposed a scaling road map on the Bitcoin-development mailing list. This road map prominently included the Lightning Network. It gained support from the majority of Bitcoin’s technical community and became the de facto road map for the Bitcoin Core project.
If anticipation for the Lightning Network wasn’t big enough already, it certainly was now.
The Implementations
The Lightning Network white paper is a long and complex document, covering highly technical concepts; in 2015, few people had the time and skill to read through and understand it. But general understanding increased significantly when long-time Linux kernel developer Rusty Russell learned about the white paper. In a series of blog posts published in early 2015, Russell “translated” the proposal for a more general (but still quite technical) audience.
Then, in May of 2015, Russell was hired by blockchain development company Blockstream to develop an actual implementation of Lightning in the C programming language: c-lightning. This major step toward implementation proved pivotal. A concept that had only been proposed a couple of months prior was now in the process of being realized by a world-class developer. Russell was later joined by Christian Decker at Blockstream, while other developers — including Corné Plooy — would, over the next couple of years, contribute to the open-source project as well.
Soon after Russell started working on c-lightning, Blockstream was no longer the only company to realize a Lightning implementation. By the summer of 2015, ACINQ, a smaller Bitcoin technology company that had originally planned to develop smart-card-based hardware wallets, decided to try their hand at the promising technology as well. The Paris-based startup would later announce that it had developed its own implementation of the Lightning protocol in the Scala programming language, named eclair.
From ACINQ's eclair announcement. Source: medium.com
Another couple of months down the road, a third implementation was in the works. By January 2016, both of the Lightning Network white paper authors, Poon and Dryja, together with Elizabeth Stark and Olaoluwa “Laolu” Osuntokun, founded a whole new company to develop Lightning: Lightning Labs. Lightning Labs would spearhead development on lnd, an implementation of Lightning in Google’s Go programming language (also known as “golang”), which they had already started developing before founding the company.
About one year after founding the company, in late 2016, Dryja left Lightning Labs to instead join MIT Media Lab’s Digital Currency Initiative, the same organization that employs Bitcoin Core lead developer Wladimir van der Laan and several other Bitcoin Core contributors. At MIT, Dryja continued to work on the Lightning implementation he bootstrapped at Lightning Labs, which he renamed lit; both lnd and lit exist today. Lit differentiates itself from lnd and other implementations by being a wallet and a node wrapped into one; today, it also supports multiple coins simultaneously through a configuration option.
Additionally, blockchain company Bitfury, best known for its mining pool and mining hardware, forked the lnd implementation to yet another version of the software. Unique to this fork is that it made trade-offs in the design so as not to require a malleability fix on the Bitcoin network — more on that later. Bitfury also made contributions in the realm of transaction routing, most notably in the form of a protocol called “Flare.” (Development of the Bitfury fork of lnd appears to have stalled for now, however.)
Further, in 2016, major wallet provider Blockchain announced that it developed a simplified version of the Lightning Network called thunder. This implementation made relatively big trade-offs compared to typical Lightning implementations, most notably because it required trust in counterparties on the network. By making this trade-off, it was able to launch an alpha release of its implementation as early as spring of 2016, long before any other development team. (While thunder might also be made compatible with the Lightning Network in the future, development of this implementation appears to have stalled for now, as well.)
In the days right after Scaling Bitcoin Milan, the third edition of the conference organized in late 2016, contributors to most Lightning implementations gathered for what came to be referred to as the first Lightning Summit. Here, they discussed how to make all of the different implementations interoperable, resulting in a Lightning Network protocol specification dubbed “BOLT” (an acronym for Basis of Lightning Technology). Where the Lightning Network white paper was a theoretical proposal, BOLT became the basis of the actual Lightning Network as we know it today.
The Protocol Changes
When the Lightning Network white paper was first published, the idea described was actually not compatible with the Bitcoin protocol — at least not securely. To enable the Lightning Network as described, Bitcoin required several protocol changes.
The first of these were new timelocks that would make payment channels resistant to Bitcoin’s malleability bug. This problem was already in the process of being solved even before the publication of the Lightning Network white paper, however, and was conclusively solved in 2015, when a new type of timelock designed and proposed by Peter Todd was implemented in the Bitcoin protocol: CheckLockTimeVerify (CLTV).
Later, Bitcoin Core developers realized that the Lightning Network would function even better with relative timelocks. These allow users to lock bitcoins up for a specific point of time after another transaction has been confirmed. In the context of Lightning, users can keep their payment channels open indefinitely, whereas CLTV timelocks require them to close their channels periodically. A soft fork upgrade to realize relative timelocks, called CheckSequenceVerify (CSV), was designed by Bitcoin Core contributors BtcDrak, Eric Lombrozo and Mark Friedenbach, and activated on the Bitcoin network by the summer of 2016.
But the biggest protocol change that the Lightning Network required (at least assuming a decent user experience), was a malleability fix for any Bitcoin transaction.
At the time of the publication of the Lightning Network white paper, malleability was considered a big challenge. While a soft fork draft to fix it was in progress at the time, developers weren’t sure this could work and thought it might require a hard fork instead. Then, by late 2015, Bitcoin Core contributors realized that SegregatedWitness (SegWit), a malleability fix that was part of Blockstream’s Elements Project, could be deployed on Bitcoin as a backward-compatible soft fork.
After a long struggle, the Segregated Witness soft fork finally activated in the summer of 2017, paving the way for the Lightning Network on Bitcoin as well.
(For more on the history of Segregated Witness, also see “The Long Road to SegWit: How Bitcoin’s Biggest Protocol Upgrade Became Reality.”)
The Alpha
Even while Segregated Witness had yet to be deployed on the Bitcoin protocol (and it was not completely certain that it ever would), development of the Lightning Network was well under way.
This started on testnet, the Bitcoin copy specifically designed for testing purposes. Or more accurately, in this case, the Lightning Network started on a dedicated version of testnet, dubbed “SegNet 4” (it was the fourth SegWit-specific testnet), launched in May of 2016.
Less than six months after the deployment of SegNet 4, in October 2016, the Blockstream development team had advanced its c-lightning prototype to the point where it was usable. In what was referred to as “Lightning First Strike,” Decker had “bought” a cat picture from Russell using testnet bitcoins over an early iteration of the Lightning Network.
The cat picture Christian Decker “bought” from Rusty Russell. Source: Blockstream.com
By January 2017, the first Lightning implementation — lnd — was released in alpha. With that, the Lightning Network itself had “officially” entered into its “alpha stage”: developers from around the world were, for the first time, invited to experiment with the technology, while Lightning Labs would continue to help test and improve the code.
This alpha phase, in turn, led to a growing number of developers building applications on top of lnd and other Lightning implementations. These “Lapps,” as Lightning implementations have come to be called, ranged from desktop and mobile wallets, to micropayment blogging platforms, to gambling sites, to explorers, and much more — though, in most cases, still designed for Bitcoin’s testnet.
During the summer of 2017, Segregated Witness finally activated, and the groundwork for the Lightning Network on Bitcoin was completed. From then, it took Blockstream about three months to announce its first transaction on Bitcoin’s mainnet. A little later, in November, Lightning Labs made its first Lightning transaction across blockchains: from Bitcoin to Litecoin. And in December, development teams from Blockstream, Lightning Labs and ACINQ announced that they had performed successful interoperability tests.
Moreover, by the end of the year, others started to actually use the alpha Lightning implementations on Bitcoin’s mainnet with real money — in some cases even against recommendations of its developers. A growing number of Lightning channels were opened, and by December developer Alex Bosworth had paid his phone bill through a Lightning channel he had set up with payment processor Bitrefill: one of the first real-money purchases over the Lightning Network ever.
Another month later, Blockstream — while the c-lightning implementation was still in beta — opened a webshop where real products could be bought with real bitcoins, albeit with a clear warning of the risks involved. And in February 2018, in an almost poetic closure of Lightning’s alpha stage, Bitcoin’s legendary Lazlo Hanyecz of “Bitcoin pizza” fame announced that he’d bought pizzas (of course!) through the Lightning Network.
Lazlo Hanyecz enjoying his pizzas. Source: http://eclipse.heliacal.net/~solar/bitcoin/lightning-pizza/
The Beta
After years of development, and even more years of conceptualization, perhaps the biggest milestone of all was reached several weeks ago.
Midway through March 2018, Lightning Labs’ lnd was the first Lightning implementation to be released in beta. Announced simultaneously with a $2.5 million seed investment round, which included big-name investors like Twitter CEO Jack Dorsey, Lightning Labs deemed the Lightning implementation it had been spearheading ready for use on Bitcoin’s mainnet — though primarily for technical users.
This announcement was followed by a tweet from ACINQ on March 28, announcing that eclair had also been released in beta and was thus deemed ready for mainnet use, as well. The startup added that their Android Lightning wallet would be released the following week. (At the time of publication of this article, that is this week.)
Blockstream’s c-lightning implementation has not yet been released in beta, though its development team indicated to Bitcoin Magazine this may follow shortly, too. Adding to a still-growing list, the blockchain development company did, however, introduce seven brand-new Lapps in the last week of March, highlighting the company’s progress on the Lightning front.
While people were already using Lightning software even in alpha, the beta phase has only further stimulated this growth. At the time of publication of this article, well over 1,000 Lightning nodes have opened up almost 5,000 payment channels, holding over 10 bitcoin (some $70,000 at the time of writing) in aggregate. Hundreds of new nodes are coming online every day, and even a Litecoin-specific Lightning Network is taking shape, which could, in the future, be made interoperable with Bitcoin’s.
A graph of the Lightning Network at time of publication. Source: lnmainnet.gaben.win
Yet, even with all this progress, it’s still early days for the Lightning Network. Most users of the network today are still very technical (often developers), and use cases are mostly experimental. While the beta software release(s) are major milestones, development and improvement of the network is an ongoing process, and much still needs to be done, while open questions on routing, privacy and otherrisks remain.
Most likely, only further adoption will answer them.
Author’s note: While doing research for this article, I came to realize that the full (pre)history of the Lightning Network is even more extensive than I already knew it was. Outlining it into a single piece required cutting corners and leaving out details, which does not do justice to all the people, projects and concepts that help(ed) realize this technology. This article is an attempt at outlining the story so far, but it is best understood as a rough summary — not an exhaustive historic or technical account. Thanks to everyone who provided information and other input.