The Lightning Network is a Layer 2 solution that allows you to create micropayment channels with other Bitcoiners. It allows instant and trustless peer-to-peer transacting while limiting the amount of data needed on-chain.In this post, I break down exactly how it works, as well as a newly proposed update protocol within it called Unidirectional payment channels are the simplest to implement in the Lightning Network because money only flows in one direction. The most common use case is streaming money; for example, a micropayment for each minute of a video you watch.Say you want to start such a channel with Netflix. First, you create a Say you fund this transaction with 10 Bitcoin and publish it on the Bitcoin blockchain. After being mined, this funding transaction can be spent by a 2-of-2 multisig consisting of your’s and Netflix’s keys.As Netflix starts streaming you bytes of video, you start streaming them money — say .000001 Bitcoin per minute of video — via partially signed transactions that spend this funding transaction.Using the funding transaction as input, you create two new outputs: one sending .000001 to Netflix, and the other 9.999999 to you. You sign this transaction and share it with Netflix off-chain (that is, without attempting to publish it to the Bitcoin blockchain). This transaction is considered “partially signed” because it only contains one of the two signatures necessary to spend.When Netflix receives this partially-signed transaction, they are in control. Netflix can choose to claim that .000001 Bitcoin immediately, and in the process send the remaining 9.999999 Bitcoin back to you, by adding their signature to the partially signed transaction and publishing it. This is considered Instead, Netflix will continue streaming you video so long as you keep providing larger partially signed transactions every minute. With unidirectional payment channels, there’s no possibility of cheating. If you stop sending Netflix partially signed transactions every minute for higher amounts each time, Netflix will stop streaming you video. They will sign the most recent partially signed transaction you sent them (which entitles them to the most Bitcoin), publish it, and thus close the channel.Furthermore, there’s no risk of anyone publishing an “outdated” transaction. Netflix is the only one capable of spending any of the partially signed transactions (since Netflix has your signatures, but you don’t have any of theirs), and every newer partially signed transaction you send Netflix is strictly better for them than any older one. Netflix can only cheat When money flows in both directions, this gets trickier. Both parties can publish transactions, so incentives exist to publish an outdated transaction.Say Alice and Bob open up a payment channel and each lock up .5 Bitcoin in the funding transaction. Now, Alice agrees to pay Bob .1 BTC for a carwash. She sends Bob a partially signed transaction that uses the funding transaction as its input with two outputs: one that sends .4 BTC to her, and one that sends .6 BTC for Bob.By not publishing this transaction, Bob keeps their channel open. He later agrees to pay Alice .3 BTC for a painting.If Bob sends Alice a partially signed transaction that uses the funding transaction as its input, they will each be in possession of a different, yet valid, spend of the same funding transaction. Transactions have no expiration date in Bitcoin, so their transactions will be valid forever.It doesn’t matter if they keep sending partially signed transactions back and forth for other goods and services. Either of them can act maliciously by publishing any earlier transaction that entitled them to more Bitcoin, thereby closing the channel, and making all other signed transactions invalid.Bidirectional channels need a way to Bidirectional payment channels in the Lightning Network work out-of-the-box today because the Though LN-Penalty works today, it has problems. Besides its complexity, edge cases exist where it risks accidentally penalizing an honest user. In eltoo, the two parties create the funding transaction denoted by Before signing the funding transaction, Alice and Bob first sign a After they sign the first settlement transaction, the parties can safely sign the funding transaction. The locking script for the funding transaction looks as follows:There are two ways to spend the funding transaction: one in the You’ll notice that the settlement branch of this locking script contains Instead of publishing the settlement transaction, Alice and Bob keep the channel open. Say Alice wants to send 1 Bitcoin to Bob, so their new balances are 4 Bitcoin for Alice, and 6 Bitcoin for Bob.The first thing Alice and Bob do is exchange signatures for a Here’s the key point of eltoo: this new settlement transaction does not spend from the same funding transaction. Instead, it spends the output of a transaction Alice and Bob have yet to make: an An update transaction’s purpose is effectively to double-spend the funding transaction, so that the original settlement transaction (that Alice and Bob both signed, which had a block delay of 10 blocks), becomes unusable.Recall the locking script of the funding transaction:While the settlement branch has a 10 block delay, the After Alice and Bob sign the new settlement transaction that sends 4 Bitcoin to Alice and 6 to Bob with their settlement keys, they exchange signatures from their update keys to create the update transaction. With that, the old settlement transaction that refunded their initial balances becomes irrelevant, and the new settlement transaction — which spends the update transaction — is the only one that can issue payouts.This process of creating update transactions and settlement transactions can continue like this indefinitely, as the image from earlier showed. The most recent settlement transaction You’ll notice that while this proposed model works, it requires every intermediary update transaction to be published on-chain. This defeats the purpose of the Lightning Network, which transacts off-chain to keep on-chain data light.That’s where Though an output’s locking script can dictate that a With As in the diagram above, using the Thus, only three transactions must be published by the end of the channel: the funding transaction, the last update transaction, and the last settlement transaction which distributes the final balances to each party by spending that last update transaction.You might notice that free floating update transactions present an issue. If the last update transaction can bind to to any earlier update transaction (including the funding transaction), then the opposite is true: any of the earlier update transactions can bind to the last update transaction as well. This would nullify the last settlement transaction!To address this, eltoo cleverly invokes the concept of The But there’s a clever trick here! If you make Say the funding transaction specified an Now, if Alice and Bob tried to bind the first update transaction to a later output — say, the third output — the Bitcoin blockchain would reject it, because the first update transaction’s nLockTime is 1, while the third output has a locking script requiring an nLockTime of at least 3.Although all of the update transactions are signed with Settlement transactions must also use However, you’ll notice the settlement branch of the locking script does not contain any concept of state numbers like the update branch does.At first glance, it would seem this would cause the same problem we described earlier: old settlement transactions could be applied to future update transactions, producing a race condition to see which settlement transaction would be mined on-chain.Instead of using state numbers, the solution here is that each settlement transaction uses a Bidirectional state channels can be complex, but eltoo provides a simple, innovative way to implement them. I hope you enjoyed this view into the Lightning Network — stay tuned for similar posts!Written by