Payment Channels

Payment Channels constitute the backbone of the Lightning Network, because they make it possible to combine many off-chain transactions into only a few blockchain transactions. With off-chain transactions we mean transactions done on the Lightning Network without letting Bitcoin’s blockchain know anything about them. When heard for the first time, this would of course provoke a question regarding the security of funds, because we are used to think about transactions as entries in the immutable ledger that must be present, in any blockchain copy on every full node, without exceptions.

How is it then possible to have a consistent chain of transactions when Lightning Network explicitly allows to “ignore” some of them? The solution of this paradox lies in the clever utilization of multi-signature addresses we spoke about in the previous chapter. Before any transaction is being made off-chain, the two parties willing to use the Lightning Network would first have to create a 2-of-2 multisig address to send their funds to. This initial or funding transaction would land on Bitcoin’s blockchain just like any other (Figure 9-1).

After having waited for the usual six blocks to confirm the funding transaction, the participants will become able to create new transactions to send funds back and forth, which would each time be changing the amounts of their respective funds. However, unlike the funding transaction, these off-chain or commitment transactions will never be finalized on the blockchain as they’d only exist in the Lightning Network, or more precisely, in the channel that the two participants created. What these transactions do is basically generating lots of “double spends”, because each time participants update their funds by creating a new commitment transaction they’ll point at the funding transaction again. However, they’d actually never try to double spend anything on the blockchain itself as they’ll never touch it directly. And because they don’t exist on the blockchain, they also don’t have to follow its rigid rules like waiting for six blocks to confirm or to pay high fees to miners as there is no mining in Lightning Network at all.

Transactions of this type can transfer money at the speed of the Internet protocol while at the same time remaining completely trustless and without any need for trusted intermediaries, who would be taking care of funds. But if all transactions are created in Lightning Network’s channels only, how can participants ever get their bitcoins back? Traveling at the speed of light is a nice property, but bitcoins only exist in Bitcoin’s blockchain. And they never leave it. The answer lies in the closing or settlement transaction that must be finalized in the blockchain to make funds available to participants. This transaction informs the blockchain about the final state of funds (Figure 9-2).

However, as there is no way for the blockchain to know that a certain transaction represents the “real” state of funds, we need a way to keep both parties honest. What if Bob decides to cheat and sends a closing transaction that gives him more bitcoins than he should own? How is Alice supposed to protect herself? As the blockchain is not here to help her out, because it doesn’t know how many commitment transactions happened in between, we need a trustless mechanism that would prevent old commitment transactions to land on the blockchain. Indeed, such a mechanism exists and is embedded in the Lightning Network’s protocol. It is called Transaction Revocation , and we will soon see it at work. But before we look at this security mechanism, actually a very weird trick, we should first describe in detail the actual mechanism of value transmission, the commitment transactions.

Commitment Transactions

After having opened a channel, each party can now alter the state of funds by creating commitment transactions without forwarding them to the blockchain. Every commitment transaction will be spending the original outputs from the funding transaction and indirectly invalidating previous transactions and states.

In Figure 9-3 we see three commitment transactions have been created and signed by Alice. Each time she changed the original state by assigning certain amounts to Bob and to herself. However, instead of forwarding any of those transactions to the blockchain, she is sending them to Bob, who could then use any of them to finalize it on the blockchain, if he wanted to close the payment channel. Bob too can create as many transactions as he wants and send them to Alice. It is also important to know that these transactions are only “half-valid”, because neither party can include the recipient’s signature in advance.

This can only be done by the recipient itself, if he or she decides to send a transaction to the blockchain. Therefore, the participants only declare themselves willing to spend the written amounts of bitcoins by providing their own signatures, which also have been used to create the multisig address, when the channel got opened. It is up to their counterparties to add their own signatures as well, thus making the transactions “completely valid” for the finalization in the blockchain.

As shown in Figure 9-4, transactions created in the Lightning Network contain two outputs that can be used for different purposes, depending on the use-case. Whenever a transaction is created in the channel, the two parties create mirrored transactions and exchange them. In the preceding example the transaction was created by Alice, which she signed and sent to Bob. There she declared,that Bob could get 6BTC sent to an address he previously communicated to her but only after having waited for 144 blocks, which is roughly a day. This delay is for a reason that we will discover shortly. Also, Alice assigned herself the remaining 4BTC in the first output above. The mirror transaction that Bob created at the same time and sent to Alice contains equal inputs and outputs, only differently organized (Figure 9-5).

Here Bob declares in his second output that 6BTC belong to him, which corresponds to second output entry from Alice’s transaction. However, he would get them immediately if Alice ever decided to send this transaction variant to the blockchain. As we already know, as long as neither party decides to close the channel, no transaction will ever be sent. But if either of them sends it, the counterparty would immediately get those bitcoins declared in it. This is how parties ensure that at the closing of the channel they will get their coins back as soon as possible, while those who have initiated the closure would have to wait for 144 blocks (or any other period that can be negotiated at the channel opening). This waiting time, of course, is for a reason that we will talk about shortly. If we recall the first transaction that Alice sent to Bob (Figure 9-4), we see in its second output some additional logic that’s indicated with the Boolean OR (Figure 9-6).

This part is an option that could be executed immediately, which also means before Bob could get those 6BTC after his waiting period of 144 blocks. But the catch is that this could only happen if the party using this option is in possession of Alice’s Revocation Key and Bob’s Key. In Bob’s case this wouldn’t be true, because Alice would not send her revocation key without a valid reason. When she created the above transaction and declared that Bob should own 6BTC, she also created a new key pair. Her revocation key is this private key.

This step in the whole transaction sequence is of crucial importance, because each time parties create a new “half-valid” transaction, they also generate new key pairs. Now the question is, why do they need them? To answer it, we have first to describe their purpose by looking at how a transaction invalidates a previous one. When Alice creates a new commitment transaction, she not only creates new inputs, outputs, and addresses. She also sends to Bob the revocation key that was used in the previous commitment transaction.

The second transaction in Figure 9-7 creates a new state in the payment channel which also invalidates the previous transaction.

Alice has created a new key pair a new address. Here she sends 3BTC to herself, that is, 1BTC less than in the previous, now invalidated, commitment transaction. Bob should now get 7BTC, which is 1BTC more. The rules regarding channel closure and blockchain finalization are the same; only the monetary values have changed. Bob can either close the channel (any party could do this anytime), but he would, again, have to wait for 144 blocks, before he can take those 7BTC. Or he can simply keep the channel open, because there is no need for either party to immediately send a transaction for finalization. And of course, there is still the option to immediately sweep those 7BTC if Bob somehow gets Alice current revocation key. But this, again, wouldn’t be possible, because Alice only revealed her last revocation key to Bob so he could only immediately get 6BTC from previous transactions, if he ever wanted.

This of course is something Bob wouldn’t want. He’d rather finalize the current transaction that gives him 7BTC after 144 blocks. The previous revocation key seems to be of no real use to Bob. However, what would happen when Alice suddenly decided to send the previous commitment transaction to the blockchain? This transaction would bring her back 1BTC, effectively taking it back from Bob, who’s still hoping to get his 7BTC as declared in the current transaction. What could Bob now do to prevent Alice from executing the invalidated transaction on the blockchain? For the blockchain itself, all transactions are valid. Commitment transactions can only be invalid in their respective payment channels.

In such a situation, the revocation key of the previous transaction would come in handy, because Bob can now immediately execute the second option from the old transaction (Figure 9-4) and get all of the bitcoins. The second half of its output script demands possession of Alice’s Private Key and Bob’s Key, which Bob now can provide. Ultimately, Alice would lose all of her bitcoins she initially used to fund the channel. This is the reason revocation keys exist and have to be shared between parties each time they update the channel state by creating new transactions.

As long as both parties are honest, the only reasonable way to close the channel and get the bitcoins out is by executing the first part of the script. If a party is honest, then there should be no problems for he or she to wait for a predefined number of blocks. Otherwise, the cheater should be punished by waiting, while the cheated party would immediately grab all of the remaining bitcoins. All the cheater would get is an input transaction with a spent output.

The punishment in Lightning Network is a severe one, because it leaves the cheating side without any funds. This way both parties are incentivized to behave honestly at all times as there is no way to prevent the automatic revocation, when one party tries to cheat on the other. As Alice has already signed every transaction, all Bob would have to do is provide his own signature and send it to the blockchain. And it’s obvious that Bob would have an interest in forwarding the last transaction to the blockchain as it promises him the greatest payment. Although there wouldn’t be anything preventing him from finalizing any of the older transactions, we can assume that a party would be interested in maximizing own profits.

Multihop Payments

But Lightning Network doesn’t end at bidirectional payments. In fact, such payments are not happening very often as we mostly buy products and services from people or entities, we know nothing about, or simply don’t care who they are. Although very promising, the whole setup process is still cumbersome, because it requires that somehow two parties find each other, agree upon a certain amount of initial funds, and then be sending funds back and forth. This would work for payments among friends maybe, but it’s not very helpful when acting on a more global scale. Did we lose our social scalability by onboarding the Lightning Network? The answer is “no”, and it has to do with a more complex payment channel setups called Multihop Payments.

Lightning Network wouldn’t be a network if it didn’t provide a way to transfer money over multiple “hops”. Just like the Internet would be of no use as information network if there was no way to forward packets over multiple computers, the same applies to Lightning Network, with the difference that it’s a network of value as it transfers scarce digital assets that can’t be replicated. The capability of forwarding the payments throughout the whole network without having to trust any node along the way is what makes the Lightning Network a true network of value. Indeed, we keep the social scalability from Bitcoin without sacrificing the speed we get from our new network.

Additionally, we also win in terms of anonymity, because when nodes don’t have to trust their neighbors, they also don’t need to know who they really are. While Bitcoin, due to its transparency, merely offers pseudonymity with addresses, the Lightning Network is a completely opaque place, where nodes operate in total anonymity. This is achieved by utilizing the Onion routing we know from networks like Tor. In Lightning Network a node only knows about its predecessor and successor. It has no option to assemble more detailed information about the nodes surrounding it except by doing it by itself, also called Source Routing.⁵ Nodes can also act as routers for forwarding of payments between nodes that don’t know each other and also don’t care where a payment is coming from or is going to. Given enough liquidity, a node could participate is such a network and also earn fees for offering routing services to other nodes. One can even operate a node that itself isn’t executing any direct business operations (buying or selling) but instead acting solely as “money transmitter” for other nodes. Imagine a following scenario involving three nodes, Alice, Bob, and Reginald.

In Figure 9-8 we see that Alice has no knowledge of Reginald as only two payment channels are open, one between Alice and Bob and the other between Bob and Reginald. How is Reginald supposed to receive money from Alice, when there is no open payment channel between them? The solution is the creation of forwarding networks of point to point channels with Hash Time-Lock Contracts.

Hash Time-Lock Contracts

The first output is easy to understand as we simply check if Alice’s key corresponds to her signature. The second output, however, is a bit more complicated. There we have first to check if the number of blocks after this transaction got into the blockchain has crossed the threshold of 144 blocks, before we then DROP this number and then check Bob’s key for correspondence with his public key.

Why are we doing it that way? The reason for this small confusion lies in the fact that nodes running older versions of Bitcoin, that is, those that know nothing about the two new opcodes, CSV and CLTV,⁷ will see one of the unused No-OP-Codes instead. In this case it’s the NOP3. And because NOP-Codes never pop any data from the stack, we have to issue an extra DROP command to remove the checked delay of 144 blocks, because this value is irrelevant to older nodes. Therefore, soft-forked nodes would read the script as 144 + CSV + DROP, while older nodes would still be seeing 144 + NOP + DROP. This is a small trick that helps updating the Bitcoin network without forcing a hard fork, which is always an extremely risky and potentially value-damaging operation. By executing soft forks, we make sure that older nodes can still participate in the updated network without being forced to update immediately.

However, we have two new Op-Codes, and the second one hasn’t been used so far. This will change shortly, when we try to send money not to our counterparty in the payment channel but to someone unrelated to us. In such cases we have to expand transactions with additional scripts that would have the CLTV Op-Code included.

If Alice wanted to send money to Reginald, she would need something that only Reginald knows to prevent any other party from stealing funds being sent from her to Reginald. Indeed, such a value exists and must be generated by Reginald. It is basically a long string of bytes that he keeps for himself and gives Alice a hash of it.

After Alice has received the hash, H, of Reginald’s preimage, R, as it’s usually being called, she can create a new type of script that uses the CTLV Op-Code to execute multihop payments (Figure 9-9).

In our case, Alice wants to send 1BTC to Reginald by using Bob’s node to forward her payment. Of course, she doesn’t want to put her trust in Bob to be honest and forward 1BTC to Reginald and therefore creates an output that would give 1BTC to Bob only if he can provide R, which nobody knows except Reginald. However, she also puts an additional constraint into it. If Bob can’t provide R until block height 600,000, the funds will go back to Alice.

With this script (Figure 9-10), Alice creates an incentive for Bob to try to find R. But because she tells Bob only about H, there is only one way for Bob to learn about R: he must forward the transaction to Reginald. The HTLC scripts are more dynamic, but also more rigid, because they use the CLTV Op-Code that isn’t using relative block heights as CSV does. Instead, it compares the current block height with the predefined (and unchangeable) height included in their script code. In previous transactions, the block heights were calculated by using the height of the block the transaction got included at. In HTLCs we don’t have such a luxury and must also expect that sometimes a script might fail, if it got included in a block that was “too late”.

After Alice has sent this new “half-signed” transaction, and Bob also generated the mirror variant of it, our Lightning Network would now look like in Figure 9-11.

As Bob has no other option to learn about R but to ask Reginald, he then creates his own transaction that includes an HTLC script. However, this transaction is unknown to Alice, and she also doesn’t care. All she cares about is that Bob can’t get R and steal 1BTC she is sending to Reginald. Bob’s transaction would include Reginald and a decreased block height, because he doesn’t want to be too late with the other script he got from Alice. Therefore, he chooses 599,856 block height that is 144 blocks less (Figure 9-12).

The network state looks now like in Figure 9-13.

Reginald of course can provide R and therefore fulfill the requirement imposed by Alice’s HTLC script that got forwarded by Bob. At the same time, Bob learns about R, because Reginald must publish it to the blockchain to finalize the transaction. Bob then uses R in its own HTLC script he previously got from Alice. And he also hopes of not being too late, because block times are rigid. He solves his own HTLC and informs everyone about it in the blockchain.

But the 1BTC has been already spent by Reginald, and therefore Bob can’t access them anymore. Alice learns about R as well and would also try to get back her 1BTC, but again, Reginald has already spent them. And this was also her goal, actually. The advantage of this approach is not only the technique done with HTLC Smart Contracts but also the fact that there is no limit regarding available connections. In our example, Alice could also have received her HTLC from someone else, and Reginald could also be forwarding it to someone else. The only requirement for participation in multi-hop payments is the liquidity of a node. For example, if a node has funded a channel with 1BTC, then future payments it can forward can be up to 1BTC. If a node operator wishes to earn more fees, he should then think about opening more channels and especially more liquid ones. The more liquid channels a node operates, the greater the chance that it will be selected in future multi-hop payment transactions.

Pathfinding

As channels can be opened and closed anytime, the Lightning Network behaves differently from the usual networks we know. When we surf the Internet, our computer automatically takes one of the available routes (Figure 9-14).

Not so with the Lightning Network. Here a node has first to get enough information about the liquidity of other payment channels, which could forward the value it wants to send to its target. We say that a node has to find a path. And because payment channel balances can change anytime, the pathfinding process becomes a very dynamic task (Figure 9-15). This of course is exactly the opposite of what happens in the Internet, where routes are much more stable. The importance of Payment Channels for Pathfinding lies in their liquidity. In Lightning Network, the Payment Channels constitute the edges of this network, while nodes are continuously searching for the best possible path between them. In Figure 9-15 a node wants to send 1BTC, and the payment channels with lower balances cannot participate.

Also, the Internet transfers information that can be replicated easily, while Lightning Network always transfers money that must not (and cannot) be replicated. When a route in the Internet goes down, our data packets get rerouted automatically over alternative ones (Figure 9-14). Would this happen to us in the Lightning Network, there would be no way for us to “restore” our money. And because liquidities of nodes can change without warning, the routes in Lightning Network are not guaranteed to be long-lived. Nodes can come and go anytime, as we have already seen in our scripts, where parties can decide to take their funds at will.

Fees

However, one important factor is still missing from our example with Alice, Bob, and Reginald (Figure 9-13): the monetary incentive for Bob to forward any transactions is missing. It is true that he got incentivized by Alice to learn about R, but so far there was no reward for money transmission service he provided to Alice and Reginald. If this was always the case, the Lightning Network would very much depend on the altruism of other people.

Therefore, the multi-hop operations we described in our example would always include fees to be paid for services offered by other onodes. Alice would first learn about fees Bob is expecting to get from others and increase the amounts she’s sending so that it would include those fees. Instead of sending 1BTC to Reginald, she would be sending 1.00000001BTC, for example, so that Bob can chip away 0.00000001BTC. However, when we say fees in Lightning Network, we don’t mean the ones from the mining business. As here is no mining activity at all and electricity costs are more or less negligible, nodes can only charge extremely small values, usually sub-satoshi values. This also affects the values being forwarded. Mostly, multi-hop payments are very small and actually never contain whole bitcoins.

In general, the Lightning Network should be used for micropayments or when payments should be done on demand and very quickly, for example, when the consumption of services depends on a continuous incoming stream of money. A popular example is watching a channel that is streaming videos as long as money is coming in. In such cases the customer running a Lightning Node would open a channel and continuously be creating new transactions that are sending sub-satoshi denominated values to recipient’s address.