The Lightning Network can’t exactly fork like Bitcoin itself can, but it is starting to branch out. The bare minimum viable protocol was initially specified in the BOLT documents early on before anything actually went live on the main Bitcoin network, but that was just the starting point. There are still many extensions to build out in the protocol and areas with unsolved scaling issues. In general, the Lightning protocol itself still has a long way to go in terms of solving existing issues and becoming robust and scalable enough to serve as a global transactional network on top of Bitcoin.
Part of the rationale for second layer systems as a scaling solution to Bitcoin, aside from the obvious reality that blockchains do not scale, is to make room for easier experimentation. When it comes to second layers like Lightning, there is no need to get everyone to agree to a change in order to try something new. As long as what you are doing works with the base layer functionality supported by Bitcoin, as few as two people can break away and play around with new features without needing to care about everyone else supporting it. Different implementations are starting to take advantage of this greater freedom than the base layer of Bitcoin, and some members of the Core Lightning (CLN), Lightning Network Daemon (LND) and Lightning Dev Kit (LDK) teams participated in a very interesting panel at Bitcoin 2022 to discuss some of the different priorities each team is taking in terms of expanding the feature set of their Lightning clients.
LND
LND, run by Lightning Labs, is the most widely adopted Lightning implementation on the network, currently the backend to popular wallets like Breez, Blixt, Zap and Lightning Lab’s own Lightning App before it ceased development on it. It also powers major businesses like Bitrefill and Hodl Hodl. One of the biggest shortcomings of LND has been the massive growth rate of its channel state database (which is being optimized in its next release), but it is still the current pack leader on the network.
The Lightning Labs team has generally focused on providing its own monetized services to help address shortcomings inherent to the Lightning protocol as the core of its business model. In terms of the current roadmap in the near term, LND prioritized two different things as the main priority of its development efforts.
First is the implementation of Taproot to enable a new transaction structure for channels (remember, all that a channel is is a set of pre-signed transactions) to lay the foundation for future privacy improvements. One of those is the shift from hash timelock contracts (HTLC) to point timelock contracts (PTLC). Currently, HTLCs are what guarantee that a payment either succeeds or fails for every hop along a payment route; the preimage to the hashlock is released and guarantees the payment goes through for everyone or it doesn’t and is refunded for everyone. PTLCs accomplish the same thing using adapter signatures instead of hashes, which means that every hop along the path does not have the same hash which could identify a single payment across multiple hops if one person is running multiple nodes along the payment path. While this by no means is a magic privacy solution for the network, it is a building block toward comprehensive privacy once other solutions are implemented.
The next step after implementing Taproot channels for Lightning is updating the channels live on the network to use them. There are 82,697 public Lightning channels as of this writing. With close to the most efficient use of blockspace containing around 3,300 transactions, it would take 25 blocks of just channel closures to close them all out, and another 25 to reopen them as Taproot channels.
Let’s assume that there are twice as many private channels as there are public ones. This would bring the total to around 150 blocks to close out and reopen all existing Lightning channels as Taproot channels, assuming the blocks are filled with no other transactions. In reality though, those blocks are not going to be full of just Lightning transactions, so this process could take a week or more for the entire network to cycle through and upgrade. LND is planning to implement a feature called “on the fly channel updates,” where instead of closing existing channels and opening new ones, you simply spend the existing channel state (pre-signed transaction) into a new one instead of into outputs that would close the channel on chain. This comes at the cost of an extra transaction for non-cooperative closes, but would allow node operators to take advantage of new Taproot-based features without having to close existing channels.
Obviously, the implementation of Taro will likely take a front seat at some point after these developments, but the implementation of a brand new top-layer token protocol will likely take some significant amount of time. Given other features that might be a good idea to implement, as well as the day-to-day work of optimizing the node’s existing functionality, I don’t think there’s any telling how long until that sees the light of day.=
CLN
CLN (formerly c-lightning), was, despite much reporting to the contrary at the time, the first Lightning implementation to go live on mainnet in 2018. The entire architecture of CLN was built around the idea of modularity, so that different pieces of the node (such as the piece handling keys and signing) could be easily swapped out and customized. There is even a plugin system designed for users to be able to write their own customized behavior to interface with CLN and alter how the node operates in certain situations or in response to specific events.
A prime example of this is the payment functionality, which is even implemented as a plugin for the default payment behavior shipped with CLN. This is the part of the node that handles figuring out payment routes and sending them. There are a large catalog of plugins available, from automated node management with CLBOSS, watchtower plugins and automated probing logic, to dynamic pruning of Bitcoin Core to ensure CLN always has the blocks it needs to stay synced. A large list of plugins can be found here.
The core goal of CLN has always been modularity and flexibility, and the team is planning on taking this to the next level with its Greenlight software stack. Greenlight will further separate the functionality of different parts of the node to the point that users will be able to store and manage their keys and signing operations on different (and even multiple) devices from where the actual node backend handling channels and other data can run somewhere else, either in the cloud or even a device hosted at home. Breez Wallet is even planning to shift to using CLN/Greenlight and break up the different functions of its wallet into separate applications to take advantage of the freedom enabled by this architecture. Separate apps for podcast streaming, general wallet use, PoS systems, all connected to the same node. This even opens the door for receiving payments when your mobile wallet is offline, a major issue in many use cases with Lightning. A separate signing device could be left at home online all the time, and programmed to only sign channel updates when they are increasing your channel balance. Problem solved, you no longer have to worry about having your phone open all the time in order to receive funds.
CLN’s next priority is going to be building on the work of Niftynei on dual-funded channels. Currently, when opening a Lightning channel, only one side of the channel provides a funding UTXO, leaving all of the liquidity in the channel on that party’s side. CLN currently supports dual-funding where both sides of the channel can contribute UTXOs in the funding transaction, allowing the channel to start off in a balanced state where both sides have funds. Building on this functionality, it is currently working on implementing splicing, a long-discussed feature for the protocol.
Splicing would allow you to open and close a channel in a single transaction to add more funds or remove some but not all of the funds in the channel. This would be a huge win for channel liquidity. Imagine opening a channel with someone so they can receive funds, and realizing you allocated ten times the amount they needed. Splicing would allow you to remove the excess without disrupting your peer’s ability to receive funds and allocate your bitcoin somewhere more productive. This is a huge win for both average users, Lightning service providers (LSPs) and routing nodes. It would enable all of them to utilize their liquidity more efficiently without shutting down the channel for the other party.
LDK
Lightning Dev Kit is not so much a Lightning node implementation and more of a library that can be used to construct a Lightning node. It provides code for every isolated piece of a Lightning node, the routing logic, the channel management, the logic for monitoring the state of the blockchain to verify whether channels are open, the whole shebang.
Blue Wallet is working on a LDK-based implementation, and a brand new Lightning implementation Sensei is also being built out around LDK. Cash App even built a node entirely from scratch. When it began looking at Lightning integration, it wanted to deeply integrate the behavior of its Lightning nodes with the backend handling Cash App’s user balances. No existing implementation would allow for easy integration to that degree, so they customized their own using LDK.
The LDK team is taking on a much different endeavor compared to other Lightning implementations. As noted earlier, it isn’t really an implementation, but rather a tool kit that can be used to build one yourself with the customized behavior you want. As such, it isn’t really prioritizing any specific feature sets over any others. LDK’s goal is to widely support all standard functionality of the Lightning protocol and allow builders to make use of any standardized features in whatever way they choose to in their own applications, or not.
The Road Ahead
A large part of the pitch for Lightning was facilitating native payments on the internet for digital services, but the user experience of that goal has not really materialized in a slick and easy way.
Work has been done by LND, CLN and LDK to address this issue. Web Assembly (WASM) is a new language and binary format to facilitate more efficient and lightweight programs to run in the web browser. LND and LDK both have WASM binaries for their nodes, and CLN is planning on implementing key management tools to run in WASM that can connect to a Lightning node remotely, building on its Greenlight work. While there are security issues to consider when managing keys in a web browser, the days of seamless Lightning integration on the web are approaching.
Lightning as a protocol and network still has a long road ahead in terms of solving open problems and figuring out how to craft applications that are easy and intuitive for end users, but work is moving forward. It will undoubtedly get messier as different teams diverge and focus on solving different problems, and extending functionality in different directions, but progress is undoubtedly happening. We can only hope that things don’t diverge to the point of fragmenting the network and software compatibility. The road ahead will be very interesting indeed.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
Ecosystem
Research
News Network
About