After years of concept and development the first Lightning implementations are now in beta.
As a direct result, more nodes are appearing online every day and a growing number of users are opening channels with one another, and several merchants even started to accept Lightning payments.
Of course, these are still the early days of the Lightning Network. While the main implementations are usable and some wallets and other applications are available Bitcoin’s overlay payment network is projected to improve over the next several years in areas ranging from network architecture to security and usability.
These are some of the more important Lightning projects currently in development:
In order to make a Lightning Network payment people must deposit funds in a Lightning channel. Once in a channel, these funds cant be sent to regular Bitcoin addresses. This means that bitcoin in a Lightning channel is separated from bitcoin in a regular wallet, similar to how money in a checking account is separated from money in a savings account.
There are solutions to make switching between Lightning and on-chain payments more accessible.
One solution are Submarine Swaps. Developed by Alex Bosworth Submarine Swaps basically let users send Lightning Network payments to a middleman on the Lightning Network; that middleman will send a corresponding amount of bitcoin to a regular Bitcoin address.
It also works the other way around: folks can send regular on-chain payments to the middleman; that middleman will in turn send a corresponding amount of bitcoin to a receiving Lightning node on the Lightning Network.
With Submarine Swaps this conversion is done “atomically.” Using a trick that is already embedded in the Lightning Network, the Lightning payment and the on-chain payment can be linked to each other. This makes it impossible for the middleman to hijack funds by not forwarding the payment.
The Lightning Network consists of a series of payment channels. Each payment channel exists between two users, allowing funds to be sent back and forth between them.
In this early stage of development payment channels can only be funded by one of the two parties. The funding party must first make a transaction to the counterparty; only then can that counterparty return a payment within the same payment channel.
The Lightning Network white paper proposed dual-funded channels for which a specification proposal has now also been made by ACINQ, the company behind eclair. As the name suggests, dual-funded channels will let both users partly fund a payment channel by each depositing bitcoin. This could bring more flexibility to the user experience, as users can immediately send as well as receive payment after having opened a channel.
Another solution to make the Lightning user experience more seamless is known as “splicing.” In essence, splicing would let a user “top up” funds in an existing Lightning Network channel, or “drain” funds from it, potentially while keeping that channel open.
Any Lightning Network channel starts with an opening transaction, which ensures that both users consent to moving those funds in the channel. The rest of the Lightning Network channel consists of a series of subsequent transactions exchanged between the users, which aren’t usually broadcast to the Bitcoin network. The funds in the opening transaction don’t move until the channel is closed.
When splicing in users take the opening transaction to instead send funds to a replacement opening transaction, which includes more bitcoin, from one or both users.
Once this new opening transaction confirms on the blockchain, the channel is thus topped up. Until the new opening transaction is confirmed, the two users can update both the old and the new channel at the same time to avoid any “channel downtime.”
Further, when they splice out users take the opening transaction to send funds to a regular (aka on-chain) address, and potentially keep some of it in the channel using the same method. In this way, users can make on-chain transactions straight out of a Lightning Network channel.
Each time a new payment is made, Lightning channels between users are updated to reflect their mutual balances. The method used to accomplish this currently includes a penalty for users who try to cheat by broadcasting an older balance. Cheating users can lose all the funds they have in a channel.
The problem is that the broadcasting of old balances is not always a cheating attempt. There are a number of scenarios in which users can accidentally broadcast an older balance; for instance, because of a software bug or a backup that went wrong. In such instances, a complete loss of channel funds is quite a heavy punishment.
Published on April 30, 2018, eltoo is the newest proposal featured in this article. Developed by Blockstream’s c-lightning dev team — Dr. Christian Decker and Rusty Russell — and Lightning Labs’ Osuntokun, eltoo updates a channel by building a chain of time-locked transactions whereby each transaction spends funds from the previous one to reflect the latest channel balance.
If one user broadcasts an older transaction (representing an older balance), the counterparty has some time to broadcast the latest transaction.
A solution like this could work but it isn’t practical in cases of failure. It would require that the entire chain of transactions be broadcast and recorded on the Bitcoin blockchain, defeating the purpose of the Lightning Network. Decker therefore proposed a soft-fork change to the Bitcoin protocol to introduce a type of hierarchy in these types of transactions. Any newer transaction can override any older transaction without requiring that all transactions in the entire chain be broadcast.
If this soft-fork is adopted and activated on the Bitcoin network Lightning Network users could create channels in both the current style and by using eltoo.
Compact Client-Side Block Filtering:
While the Lightning Network is a second-layer protocol, the Bitcoin blockchain itself is still relevant for Lightning Network users for security purposes. Specifically, Lightning users must keep an eye on the blockchain to see if specific transactions are included. This can be resource intensive particularly for the mobile users.
A solution for this is called Simplified Payment Verification (SPV) and was described in the Bitcoin white paper. Current Simplified Payment Verification wallets use a trick called “Bloom filters” to find out whether any relevant transactions happened.
Bloom filters are rather privacy-unfriendly, as wallets essentially reveal all of their addresses to nodes on the Bitcoin network. They also have some scaling and usability issues, as each individual Simplified Payment Verification wallet takes up resources from at least one full Bitcoin node.
To tackle these issues, Lightning Labs’ Osuntokun and Alex Akselrod, along with Coinbase dev Jim Posen, designed a new solution called compact client-side block filtering which they are implementing in the Neutrino wallet.
Compact client-side block filtering essentially inverts the trick that current Simplified Payment Verification wallets use. Instead of wallets requesting transactions relevant to them by creating and sending out a Bloom filter to full nodes, full nodes create a filter for virtually all Neutrino wallets. The Neutrino wallet then uses this filter to establish that the relevant transaction did not happen.
While this was designed with the Lightning experience in mind it could be utilized to benefit regular light wallets as well.
While compact client-side block filtering should make things easier, users do need to check in once in a while to make sure they’re not being cheated. If they forget to check, it certainly creates a security risk.
Watchtowers are a potential solution that can be traced back to the Lightning Network white paper and has since been improved by Lightning Network white paper co-author and lit dev Tadge Dryja and others. As the name suggests, Watchtowers could allow users to outsource blockchain monitoring to independent third parties.
Current Watchtower designs aren’t set but would roughly work like this: Whenever users update a channel they send a small data package to a Watchtower. The first part of this package is a hint of a transaction they should look out for, as if it were a piece of a puzzle. This hint alone doesn’t reveal anything about the content of the transaction that the Watchtower must look out for; users do not give up any privacy in this sense.
If the relevant transaction shows up in the Bitcoin blockchain, the Watchtower may use the hint to recognize it. Therefore, with the transaction data on the blockchain itself, the Watchtower can use the second part of the package they’ve received to reconstruct the penalty transaction.
This penalty transaction sends all funds in the channel to the user that is being cheated. The penalty transaction may also be designed to let the Watchtower claim part of the funds as a reward, as an incentive to do its job.
Users could outsource channel monitoring to multiple Watchtowers. Even if one fails, another might not, limiting the risk for Lightning users to the point where it’s arguably negligible.
Atomic Multi-Path Payments:
What makes the Lightning Network a network is that the payment channels between users are in fact interconnected. Users can pay across payment channels through peers on the network that act as “middlemen,” to users they don’t have a direct channel open with.
Right now a single payment must be routed over a single route. If one user wants to pay five mBTC to another, not only must they have five mBTC in a single channel, all the middlemen on the route must also have five mBTC ready in a channel to forward.
Atomic Multi-Path Payments (AMPs) could go a long way of solving this limitation. First proposed by Lightning Labs’ Conner Fromknecht, the idea is simple: Larger payments can be “cut up” into smaller pieces, all of which have their own route from the payer to the payee, through different middlemen.
A challenge to realize this solution is that Lightning Network payments can fail, which would in this case mean that a payment is made partially. Partial payments can easily be a bigger problem than no payment at all, however: a merchant won’t be satisfied with a partial payment, while a customer won’t be happy spending any money for nothing.
The solution to this problem is that the Atomic Multi-Path Payments use an extension to the hash time-locked contracts, which are already used along Lightning Network routes and involve passing secret data along a network. Using a trick similar to the one used by deterministic wallets the smaller pieces of a larger payment can only be redeemed by the payee if all of them are: thus if some secret data doesn’t make it through the route whole, the entire payment fails to execute.
The Lightning Network is designed essentially as a scaling layer for Bitcoin. Since many altcoins are software forks of Bitcoin’s codebase, it is often not difficult to create similar scaling layers for these altcoins. Already, a small Litecoin Lightning Network exists, and more Lightning Networks are likely to follow.
Tellingly, these networks don’t need to remain separated in the future.
Using a fundamental building block of the Lightning Network called atomic swaps payment channels can be linked across different blockchains. A user can send bitcoin and as long as a node on the network is willing to make the exchange, another user could receive the payment as litecoin.
This also means that users can send such payments to themselves: they can send bitcoin and receive litecoin. In essence, the Lightning Network could establish a network of trustless cryptocurrency exchanges.
The main benefit of the Lightning Network is arguably its potential to increase the upper limit of bitcoin transactions without weighing down the Bitcoin network. As long as two users both have funds in their channel they can pay each other a virtually unlimited number of times, while only requiring two on-chain transactions: one to open a payment channel and one to close it.
Still, two transactions per payment channel could add up if Bitcoin and the Lightning Network gain more adoption over time.
A proposal by ETH Zurich researchers Christian Decker (also of Blockstream), Roger Wattenhofer and Conrad Burchert called “Channel Factories” could further decrease the average number of on-chain transactions required per payment channel, perhaps significantly.
Loosely based on an earlier Lightning-like proposal by Decker and Wattenhofer from 2015, Channel Factories are a type of payment channel that can exist among many users. Meanwhile, like any payment channel, a Channel Factory only ever requires two on-chain transactions.
The Channel Factories can, in turn, act sort of like “sub-channels” for the Lightning Network. Participants within a Channel Factory can open and close a virtually unlimited number of Lightning channels with each other, without requiring any additional on-chain transactions. By doing so, they could bring the number of required on-chain transactions for the Lightning Network down by a large magnitude.