The Lightning Network Is Like the Ship Of Theseus

Bitcoin Magazine

The Lightning Network Is Like the Ship Of Theseus

What is the Lightning Network? It is generally spoken about in analogies, metaphors or direct explanations of purpose. 

• “It’s the checking account, versus on-chain as the savings account.”
• “It’s a series of tubes like the internet, with bitcoin flowing through them.”
• “It’s a quick, instant-settlement layer of bitcoin.”

What it really is is a network of payment channels, where people lock bitcoin into a multisignature address, and update the state of balance distributions off-chain. It’s how we are going to scale Bitcoin — or at least part of how we are going to scale Bitcoin. 

In the short “Explainer” series in this magazine, I explain the mechanics of how Lightning works: how the pre-signed transactions that make up a Lightning channel work, how payments are routed across the network, ways that liquidity is managed, etc. Read those, and you should have a solid understanding of the underlying mechanisms that make the Lightning Network work. 

The problem is, when it comes to asking what the Lightning Network is, all of those individual pieces are modular and replaceable. What if we structured the pre-signed transactions differently? Or what if we used a different mechanism to route payments across the network? What about totally rethinking the way we even select routes for payments in the first place? 

What if we replaced all of them over time, so that none of the individual pieces of the protocol or network are the same? Is that still the Lightning Network? Like the Ship of Theseus, is the ship still Theseus’ ship after every plank and screw has been replaced? 

Is the Lightning Network still the Lightning Network if we change how all the individual pieces work? 

Channel Designs

Lightning channels are sets of pre-signed transactions. The purpose of these transactions is to commit to, and give users a mechanism to enforce, a balance distribution of a shared UTXO that neither party has unilateral control over. 

Those channels, or transactions, currently take the form of a Poon-Dryja channel. These transactions use the revocation key mechanism invented by Tadge Dryja in the original Lightning Network white paper. This is a very specific transaction structure for a payment channel, but it is by no means the only one. 

Let’s look at a concept called “timeout trees” to look at something with minimal differences from the way channels currently work. 

A timeout tree is one of the most basic possible forms of multiparty channels (a channel with more than two members in it). A Lightning service provider (LSP) creates a tree of transactions branching out from a single on-chain UTXO, and ending along each branch with a Lightning channel between the LSP and some user. Each tree has an expiry time, after which the on-chain UTXO (or any of the intermediary ones between it and the Lightning channels) can be spent unilaterally by the LSP. The idea is that users can simply swap their funds from channels in the expiring tree to a new one before that point, and let the LSP reclaim the liquidity it locked up with its users after expiry. 

This was proposed as a use case for CHECKTEMPLATEVERIFY (CTV), an opcode that prevents a UTXO from being spent any way other than the transaction that matches a predefined hash; in principle, it could be done without it using pre-signed transactions with the trade-off of introducing more coordination complexity and risk of failure to initialize a tree. 

The Lightning channels would essentially work just the same as Poon-Dryja channels, but also need to include all the extra pre-signed transactions involved in unfurling the tree, and subject to the expiry time of the tree as a whole. 

Is this Lightning? Or is this something else? 

What about LN-Symmetry? That is a proposal using CTV and CHECKSIGFROMSTACK (CSFS), an opcode that lets you check a signature against arbitrary data in a transaction to completely replace the revocation key and revocation mechanism. 

Instead of the revocation system, LN-Symmetry creates the concept of a floating signature or floating transaction. The LN-Symmetry script has two ways to spend it, either a CTV branch locking the spend to the transaction representing the balance distribution for that channel state, or a CTV + CSFS branch that lets any transaction matching a CTV template signed by a specific key set in the script spend it. This, in combination with the use of different timelock values, allows any commitment transaction to spend the output of any prior commitment transaction, i.e., to replace older states with more recent ones. 

Rather than penalizing a party who used an old transaction, LN-Symmetry “corrects” the old transaction to distribute balances based on the current state instead. Is this still Lightning? Or is this too different? 

Payment Forwarding Protocols

Hash-time lock contracts (HTLCs) are used to route payments across the Lightning Network. Each HTLC either finalizes the payment moving forward with the revealing of a preimage to a hash, or allows it to be refunded backward if that preimage is not revealed in time. This is the mechanism safely enforcing that every hop of a payment either moves forward to the receiver, or backward to the sender (if it could not be completed). 

This is not the only way to accomplish that goal. 

Point timelock contracts (PTLCs) are another mechanism that could be used in place of HTLCs. PTLCs make use of adapter signatures as opposed to preimages and hashes to provide atomic guarantees between all the hops in a payment. Adapter signatures are cryptographic signatures that have had a data value added to them — or removed from them — in order to render them invalid. The signature can now only be made valid again by adding (or removing) the “adapter value” that was used in the first place. 

Payments along a route are signed with adapter signatures, with the recipient of the payment releasing the information needed to render them valid again. But this isn’t that radically different from an HTLC; it just uses a different mechanism for facilitation. 

Let’s look at something wildly different: packetized payments. This is an old proposal to completely do away with HTLCs in order to forward payments. The idea is to break up a single payment into numerous payments of very small value, say 100 satoshis, and then just blindly forward them to a peer with routing instructions. 

The recipient can tell the sender every time a “payment packet” arrives successfully, and if one does not arrive, the sender knows that one hop along the route is not honestly forwarding the money. They can stop using that route and try another one, only losing 100 satoshis in the process. 

Is this still Lightning, or something completely different? The channel transactions would work the same way and the routing protocol would be identical, but is it still Lightning? 

Routing Protocols

What if we completely replace the routing protocol? Lightning currently uses the gossip protocol in order to ensure that all Lightning nodes on the network have a relatively good map of the different channels across the network, how much bitcoin is in them, and the fees they charge — all the information necessary for each node to fully select the routing path for its payments on its own. 

Ant Routing is a proposal to do away with all of that entirely: to route payments across the network without any gossip protocol, without any map of the network, and without the sender picking the path that their payment takes. 

The design to accomplish that is built around “pheromone trails” and “pheromone seeds,” special messages that are broadcast out across the entire network in order to facilitate payments. Together, the sender and receiver generate a large random number, and create a partial hash of that (the pheromone seed). Both parties then broadcast the seed to all of their immediate peers with a counter that increases by +1 every time the seed is passed along. 

Eventually, one node in the network will receive both seeds, and know that they are the connecting point for a complete path between sender and receiver. At this point, that node will send a response message back in both directions, and when the sender and receiver both confirm the response they can coordinate the payment. 

It will be passed back along the route to the connection point, and from there to the receiver, all without anyone along the path, including the sender and receiver, having to construct the route themselves or having any idea what the complete route is. 

Is this still the Lightning Network? Or is this too radically different? 

What Is It?!

The Lightning Network is a series of pre-signed transactions to enforce a balance distribution between users, plus the other mechanisms involved in updating that distribution and synchronizing those updates between users all across the network. 

But doesn’t that also describe Ark? Or statechains? Yes. That’s my point. 

The core idea of Lightning is just updating agreements about how to distribute funds off-chain, while ensuring that the most recent version of that agreement can be enforced on-chain if needed, without room for an involved party to “cheat the system” and enforce a more favorable past agreement. 

There are many different ways to achieve that goal. The way used currently is simply the first concrete way that was specified. There are, and can be, more and different ways to do that. Over time the methods and tools for accomplishing that goal will change. 

Maybe some new way will completely obsolete an older way. Maybe some new way works better in a certain scenario or situation. But new ways will definitely come, and that’s okay. 

Some things will completely change, others will only be slight variations of what came before, but Lightning will shapeshift over time. It needs to in order to continue scaling in the long term, to solve its own problems, to help bitcoin function as a money. 

Lightning will evolve. 

Don’t miss your chance to own The Lightning Issue — featuring an exclusive interview with Lightning co-creator Tadge Dryja. It dives deep into Bitcoin’s most powerful scaling layer. Limited run. Only available while supplies last.

This piece is an article featured in the latest Print edition of Bitcoin Magazine, The Lightning Issue. We’re sharing it here to show the ideas explored throughout the full issue.

This post The Lightning Network Is Like the Ship Of Theseus first appeared on Bitcoin Magazine and is written by Shinobi.