Bitcoin Magazine
Bitcoin Layer 2: Lightning Network
The Lightning Network is a routed network of payment channels originally proposed by Thaddeus Dryja and Joseph Poon in 2015, with major implementations having been built by Blockstream (CLN), Lightning Labs (LND), ACINQ (Eclair), and Spiral (LDK).
Payment channels are an old concept in Bitcoin, where a user deposited funds into a 2-of-2 multisig address, and a payer can pre-sign transactions allocating more and more funds to a receiver. Original payment channels were one way, and had expiry times before which the receiver must close the channel before a pre-signed refund transaction would allow the payer to reclaim 100% of the funds they had allocated to the payment channel.
The two major innovations of the Lightning Network are a type of payment channel that isn’t limited to being unidirectional and having a hard expiration date, and the concept of using Hash-timelock Contracts (HTLCs) in order to atomically route payments across multiple payment channels.
The major drawback of Lightning, and payment channels in general, is the liquidity dynamics inherent to them. In order to receive money, users must already have a payment channel open to them with enough funds allocated to facilitate that payment. In order for payments to be routed across the network, every channel must have the appropriate amount of funds on the appropriate side of the channel in order to forward that payment.
Despite these drawbacks, Lightning has seen major success in use and growth since 2018 when it first went live on the Bitcoin network.
Poon-Dryja Channels
The key problem in going from a time-limited, unidirectional payment channel to one that is not time limited and bidirectional boils down to one problem: once you create a transaction and sign it there is no way to unmake it, or take it back. That transaction exists, and until the coin(s) it spends are spent by some other transaction, it remains valid and can be used at any time.
The solution to this problem lies at the heart of the Poon-Dryja channel. You might not be able to undo a pre-signed transaction, but you can create a very strong incentive to never use older ones, and even a benefit for the party that someone is attempting to cheat if they try. What facilitates this is the concept of a revocation key.
In a Poon-Dryja channel, each counterparty in a channel has their own mirrored set of pre-signed transactions, called commitment transactions. Each channel update or change of balances is simply each channel peer signing a new set of these commitment transactions. Each party’s commitment transaction gives the other party’s funds back immediately, but they must wait for a timelock to expire before they can claim their funds back. This is to allow the introduction of the revocation key.
Whenever a channel state update occurs, before it is considered finalized, both parties must exchange revocation keys for their most recent past commitment transactions. If either party were to ever try submitting an old transaction to the blockchain, claiming funds that are currently owned by the other party in the current state, then the victim can use the penalty key to confiscate 100% of the funds the cheating party has in that old channel state.
Hash-timelock Contracts (HTLCs)
Routing payments across multiple payment channels in a network, in a safe and secure way, is possible thanks to HTLCs. This is the same mechanism used to facilitate atomic swapping of different assets on a single or across multiple blockchains.
An HTLC establishes an output that can be spent in one of two ways, either by the receiving party if they can provide the preimage to a hash that creates a hashlock, or by the sending party after a timelock has expired. This allows someone trying to pay another person across the network to pass along HTLC proposals from themselves all the way to the receiver, locked to the same hashlock generated by the receiver. When the receiver’s channel party passes the HTLC to them, they can release the preimage.
Each party then, going backwards towards the sender, reveals the preimage. At each hop the channel is updated, moving the funds in the HTLC to the appropriate side of the channel. From the receiver backwards to the sender the timelock for the refund path gets longer each hop. This is to ensure if something goes wrong and someone must close their channel and settle the HTLC on-chain that the preceding parties can detect the preimage there and update their channels appropriately.
Gossip Protocol
To successfully route payments across the network, Lightning nodes need to have some general idea of what the network looks like. This is what the gossip protocol accomplishes. It broadcasts information about different Lightning nodes and the channels they have open so wallets can have an idea of what the network looks like in order to pick routes to try to pass payments through.
This is a very simple protocol that consists of three messages, a channel announcement, a node announcement, and a channel update. Each of these messages has a specific dependency with the others, and each plays a role in propagating information about the payment channel network that users can use in order to find viable routes for their payments.
The channel announcement message propagates the information needed to prove a Lightning channel actually exists. The UTXO that is funding it, signatures from both keys involved in the multisignature address holding it. Signatures from the Lightning node identity keys, which every Lightning node has, on the UTXO proofs and signatures. Everything to prove this is a real Lightning channel, backed by real bitcoin on the blockchain, and not a fake message spamming the network.
Only after making a channel announcement broadcast to the network can a node propagate a node announcement message. This announcement includes the nodes identity key, a network address they can be reached at, any nickname they choose to assign, and a few other pieces of metadata.
The channel update message facilitates information about fees and conditions for routing payments a specific channel is subject to. This includes the minimum and maximum value being transmitted a node will accept for an HTLC, the base and percentage fee rate charged (Lightning payments must pay a base absolute fee and then a second fee calculated as a percentage of the payment value), and the time difference between them and the previous hop in a payment they require for HTLCs.
This allows every Lightning node to construct a view of the overall network they can use to inform payment routes they attempt in order to route their own payments across the network.
Onion Routing
Every message passed between nodes across the Lightning Network related to routing a payment is onion routed. Every message is wrapped in a layer of encryption so that every participant in a payment route can only decrypt and read the message for it. This message is the instructions on which channel peer to forward the payment and payment information to next.
That’s it.
This provides some degree of privacy for payments across the network, as each individual party involved in routing is only capable of seeing their single hop in the overall path. They can see which partner forwarded it to them, and which partner they forwarded it to. They don’t see the ultimate destination or source.
This is why the gossip protocol exists, and why the sender of a payment is the one who constructs the payment routes they attempt to try. By having the sender construct the route, the payment is guaranteed a degree of privacy, but for the sender to construct the route they must know what the network looks like roughly speaking, so they can choose a route without leaking to anyone which route they are choosing.
Liquidity Dynamics
No one can receive a payment over the Lightning Network without someone else choosing to open a Lightning channel to them, and allocate some real bitcoin to that specific route and person. The channel peer must essentially make a bet on that person that they will have people willing to pay them for things regularly, and in enough volume, for that peer to charge fees and earn a satisfactory amount of money.
This creates a bottleneck, and a need for participants to earn each other’s trust in some way or fashion. People on the network willing to provide this “receiving liquidity” for others need some way to gauge someone’s reputation in terms of coming through and actually providing them an opportunity to earn money.
This has created the need for what people call “Lightning Service Providers” (LSPs). Service providers who specialize in running infrastructure to target end users and provide them the liquidity needed for them to receive payments. In addition to centralized solutions like this, protocol level solutions like gossip protocol extensions that broadcast offers and fees for opening channels to people with liquidity exist.
Wrapping Up
Lightning clearly has its limitations, such as barriers to entry created by the need to preallocate funds for a user to receive payments. But in spite of such barriers it has achieved a huge degree of success.
It hasn’t exactly panned out as a purely self custodial payment solution, but it has definitely been made to work self custodially, even if drudgingly. In addition to that, it has definitively demonstrated its usefulness as a general purpose settlement layer for more industrial scale or centralized uses.
Lightning is, whether it becomes a fully functioning end user payment system or not, an undeniably effective settlement solution for those who can deal with its complexities. This guarantees it some functionality in the long term Bitcoin ecosystem, regardless of whether it was its intended purpose or not.
This post Bitcoin Layer 2: Lightning Network first appeared on Bitcoin Magazine and is written by Shinobi.
from Bitcoin Magazine
Shinobi
0 Comments