Now that we've followed Alice as she's set up a Lightning Wallet and purchased a coffee from Bob, we'll look under the hood and unpack the different components of the Lightning Network involved in that process.
The goal is rather to help you to become aware of the most important concepts and building blocks of the Lightning Network.
If you have experience in computer science, cryptography, Bitcoin, and protocol development, then this chapter should be enough for you to be able to fill out the connecting details by yourself.
If you are less experienced, this chapter shall give you a good enough overview so that you will have an easier time reading through the formal protocol specifications, known as BOLTs (Basis of Lightning Technology).
In case you are a beginner, this chapter will help you better understand the technical chapters of the book.
However, we are aware that some readers may have a hard time following high level descriptions without explaining all the details.
If you are one of those readers you may want to skip this chapter.
We'll start with a one sentence definition of what the Lightning Network (LN) is and break it down in the remainder of this chapter.
**The Lightning Network (LN) is both a peer-to-peer network of _payment channels_ on top of the _Bitcoin protocol_ as well as a communication protocol that defines how participants set up and execute the smart contracts on the Bitcoin network**
We will see that a payment channel is simply a 2-out-of-2 multisignature address on the Bitcoin network for which you hold one key and your channel partner holds the other key.
This multisignature address comes with a cryptographic protocol that is established by creating a sequence of transactions that spend from this address.
The latest transaction in the sequence encodes the balance of the channel and defines how the funds locked into the multisignature address are to be divided between you and your channel partner.
Thus adding a new transaction to this sequence is equivalent to moving ownership of funds in the channel, without the Bitcoin network being aware of it.
Each transaction in the sequence makes use of Bitcoin's scripting language, and thus the negotiation of funds between you and your channel partner is managed by a Bitcoin smart contract.
The contract is set up such as to penalize a channel member if it tries to steal funds by submitting an earlier invalidated state of the channel.
When someone says they 'own' bitcoin they typically mean that they know the private key of a bitcoin address that has some unspent transaction outputs (UTXOs).
If you have an unpublished but signed transaction from a 2-out-of-2 multisignature address, where some outputs are sent to an address you own, and additionally you own one of the private keys of the multisignature address, then you effectively own the bitcoin of that output.
Without your help no other transaction from the 2-out-of-2 multisignature address can be produced.
However, without the help of anybody else you can transfer the funds to an address which you control.
On the Lightning Network ownership of your funds is almost always encoded with you having a pre-signed transaction spending from a 2-out-of-2 multisignature address.
For example, Alice can send money to Bob if Alice had a channel with Mallory and Mallory had a channel with Bob.
By the design of the Lightning Network, it is possible to extend the smart contracts which operate the channel so that Mallory has no way of stealing the funds that are being routed through her.
Not only does the construction of the payment channel work for the partners without the necessity to trust each other but the entire network works without the necessity to trust any other participant.
Since the channels are funds on multisignature addresses and as the contracts are unpublished but presigned Bitcoin transactions, all the trust that is needed to operate the Lightning Network comes from the trust in the decentralized Bitcoin network!
This information is needed for Alice to be aware of the fact that Mallory has a channel with Bob so that she can decide to send a payment indirectly via Mallory to Bob.
Last but not least, it is important to understand that the Lightning Network is nothing but Bitcoin.
We emphasize this as you might find people who will try to spread misinformation and create a false barrier between the "real" Bitcoin and the Lightning Network or even use terms like the Lightning Network coin. At any point in time, any value held in the Lightning Network is exclusively held as bitcoin and exclusively secured by the Bitcoin network.
We rather hope that this book enables you to critically do your own research to understand and verify the following (instead of trusting us):
Besides all the technical primitives, the Lightning Network protocol is a creative way to get more benefits out of Bitcoin by allowing an arbitrary amount of instant payments with instant settlements without the necessity to trust anyone else but the Bitcoin network.
As you have seen in the last chapter, in order to use the Lightning Network, Alice had to use her wallet software to create a payment channel with another Lightning Network participant.
* If the channel is open, making a payment does not require the confirmation of Bitcoin blocks. In fact - as long as you and your channel partner follow the protocol - it does not require any interaction with the Bitcoin network or anyone else other than with your channel partner.
* The cryptographic protocol is constructed in a way that there is little to no trust involved between you and your channel partner. If your partner becomes unresponsive or tries to cheat you, you can ask the Bitcoin network to act as a court system resolving the conflict according to the rules that you and your partner have previously agreed upon.
* The capacity of the channel will be split between you and your partner. In that sense at that level you already will have gained privacy compared to the Bitcoin network where every transaction is public. Within payment channels the amounts and values of payments are only known to you and your partner. Only the final balance which is the aggregate of all payments in that channel will become visible on the Bitcoin blockchain if and when the payment channel is closed.
* As the time to update the channel is primarily bound by the communication speed of the internet, making a payment on a payment channel is almost instant.
Bitcoin was about 5 years old when talented developers first figured out how payment channels could be constructed and by now there are at least 3 different methods known.
This chapter will only focus on the channel construction method proposed by Joseph Poon and Thaddeus Dryja in 2015 since it is actually being used in the Lightning Network and was first described in the Lightning Network whitepaper.
The two other proposed methods are the "Duplex Micropayment" channels which have been introduced by Christian Decker around the same time as the "Poon and Dryja" channels and the "eltoo" channels which have been introduced in 2018 by Christian Decker, Rusty Russel and our co-author Olaoluwa Osuntokun.
However, these "eltoo" channels require a new OP_CODE in the Bitcoin scripting language and can therefore currently not be implemented on top of the Bitcoin mainnet.
A deep dive into the topic discussed here is presented in chapter 7 of Mastering Bitcoin which can be found at: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc.
Also, in case you are not familiar with P2PKH addresses and the basic format and scripting language of Bitcoin we encourage you to study chapter 6 of Mastering Bitcoin which can be found at: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc.
There is also a video on Rene's YouTube channel which dissects the bits and bytes of a transaction spending from a P2PKH output at: https://youtu.be/1n4g3eYX1UI
To allow escrow services and complex ownership configurations between several stakeholders, the Bitcoin scripting language provides multisignature addresses.
The Bitcoin transaction that sends bitcoin to that 2-out-of-2 multisignature address is called the funding transaction.
It is included in the Bitcoin blockchain.
While the payment channel opened by two participants of the Lightning Network can be private, the funding transaction will always be publicly visible to the Bitcoin network.
The amount of bitcoin sent to the multisignature address forms an upper limit on how much Bitcoin can be transacted using the channel, and is called the capacity of the channel.
While the Bitcoin network can see that funds have been committed to a channel using a funding transaction, it is unable to determine how those funds are distributed between the two channel partners.
If a channel partner should not respond, one will always have the chance to fall back to the on-chain transactions without the necessity for the channel partner to help to do so.
On-chain fees and Bitcoin confirmation times make moving bitcoin on the Bitcoin network more expensive and slower than moving bitcoin on the Lightning Network.
As Alice wasn't aware of the protocol to open the channel she now has to trust that Mallory will provide her signature if Alice wants to spend from the multisignature address.
Mallory on the other side has the chance to execute a blackmail attack on Alice by holding back her signature and denying Alice access to her funds.
In order to prevent Mallory from performing such an attack Alice will need to create a spend transaction from the funding transaction and have that transaction signed by Mallory before she broadcasts her funding transaction to the Bitcoin network.
This transaction that protects Alice is called Commitment transaction and we will study it now.
You have just learnt that a payment channel needs to be opened by preparing a funding transaction which sends the funds of the payment channel to a 2-out-of-2 multisignature address.
From the example in the last section you learnt that more ingredients are necessary to open and operate a payment channel that does not rely on trusting the channel partner.
They are used to make sure that everyone connected to a channel is able to get its own funds back in case the channel partner becomes unresponsive or, even worse, if the channel partner deliberately or by accident tries to cheat during the execution of the protocol.
. Bob also creates a new private / public key pair and agrees to accept a channel from Alice while sending his public key to Alice via the `accept_channel` message.
. Alice now creates a funding transaction from her wallet that sends 10 mBTC to the multisignature address with a locking script `2 <Public Key A> <Public Key B> 2 CHECKMULTISIG`.
. Alice does not broadcast the funding transaction but informs Bob about the transaction id of the funding transaction by sending a `funding_created` message.
. Both Alice and Bob create their version of a commitment transaction. This transaction will spend from the funding transaction and send all the bitcoin back to an address controlled by Alice.
By following this protocol Alice did not give up ownership of her 10 mBTC even though the funds have been sent to a 2-out-of-2 multisignature address for which Alice controls only one key.
At channel opening time, the commitment transactions serve the purpose of allowing Alice to withdraw her funds directly after opening the channel in case Bob does not answer. However, commitment transactions are created each time the channel balance changes. In other words, each time bitcoin is sent between Alice and Bob new commitment transactions are created. Each commitment transaction encodes the latest balance between Alice and Bob.
If Alice wanted to send 3 mBTC to Bob to pay him for a service he offered, both would create a new version of their commitment transactions which would now send 7mBTC to Alice and 3 mBTC to Bob and share signatures with each other.
However, there is still a piece missing in the design presented so far.
How many commitment transactions does Alice hold after her payment of 3mBTC to Bob? She holds two, the original one giving her 10 mBTC and the last one giving her 7mBTC. As you see, in the design presented so far nothing could stop Alice from publishing an old or even initial commitment transaction. A crooked Alice could publish the commitment transaction which grants her 10 mBTC.
Imagine, the commitment transactions can be slightly modified so that publishing an outdated commitment transaction can be punished.
A high punishment will discourage cheating.
The penalty for broadcasting an old commitment transaction is to give the cheated channel partner the ability to claim the funds that belonged to the cheater, i.e. the broadcaster of the outdated transaction.
With this modification in in place, let us go through this scenario again.
Alice creates a channel with Bob and put 10 mBTC into it.
Alice send 3 mBTC to Bob.
Alice now tries to cheat Bob out of his earned 3 mBTC by publishing an old commitment transaction claiming the original 10 mBTC for herself.
With the modification, Bob can now detect the fraud and he is enabled to punish Alice for the fraud by claiming the full 10 mBTC for himself.
Bob ends up with 10 mBTC gaining 7 mBTC for catching Alice cheat.
With such a strong penalty mechanism in place Alice will not be tempted to cheat by publishing an old state as she would almost always lose all her remaining funds in the channel.
A key characteristic of bitcoin is that once a transaction is valid, it remains valid and does not expire. The only way to cancel a transaction is by double-spending its inputs with another transaction before it was mined. That's why we used timelocks [...] to ensure that more recent commitments could be spent before older commitments were valid.
In order to update the balance and receive a signature from Bob, Alice will have to share her half of the revocation secret of the current commitment transaction with Bob.
Obviously, for every new update of the channel balance new revocation secrets have to be created and saved.
As long as a channel remains open, all revocation secrets ever created for this specific channel need to be keep as they might be needed in the future.
Luckily, the secrets are rather small and it is only the channel partners who need to keep them, not the entire network.
Nevertheless, managing and storing the revocation secrets is one of the more elaborate parts of Lightning nodes that require node operators to maintain backups.
Other technologies such as Watchtower services or switching to the aforementioned "eltoo" channels might be future strategies to mitigate these issues.
With the timelocks in place Alice can close the channel at any time if Bob does not respond, claiming her fair share of the balance.
After publishing the commitment transaction "on-chain" Alice has to wait for the time lock to expire before she can spend her funds from the commitment transaction.
Other than that and the "on-chain" fees for opening and closing a channel there comes no additional burden with maintaining a payment channel.
Channel partners can optionally agree to publicly announce the channel over the gossip protocol that comes with the Lightning Network. Such a channel is called a "public" channel.
On the contrary, a channel that is not publicly announced is referred to as a "private" channel and its details are only known to the two channel partners.
Announcing channels publicly is useful as other nodes will then be able to utilize the announced channel to route payments via it to other participants of the network.
Note that even for private channels, the funding transaction is always publicly stored in the Bitcoin blockchain.
However, as it is just a regular transaction to a 2-out-of-2 multisignature address, participants of the Bitcoin network do not know if this particular transaction is used to maintain a payment channel.
In short, the "on-chain" transactions of the Lightning Network are indistinguishable from other Bitcoin transactions.
Private channels can still be used in routing payments but only by the subset of nodes which are aware of their existence.
If a channel and its capacity are publicly announced on the gossip protocol, the channel partners will also be able to announce some meta data about the channel.
This meta data includes the routing fees a node charges to forward payments on that channel as well as information about what kind and how many Hash Time-Locked Contracts (HTLCs) will be accepted.
As we have not discussed HTLCs yet we will just mention that they are additional conditional outputs in the commitment transactions used for routing payments and for updating the channel balance.
When new participants join the Lightning Network they will be able to collect the information propagated via the gossip protocol from their peers.
Peers can only omit messages.
Peers cannot falsify messages to trick other participants as every message is cryptographically signed by the publishing node that created the message.
Opening and closing payment channels will result in Bitcoin fees and in on-chain transactions that need to be stored in the Bitcoin Blockchain.
Hence, creating and closing a Lightning channel for a single payment is inefficient.
The longer a channel remains open and the more payments are made on it, the more efficient it will become in terms of fees and on-chain storage.
An open channel allows you to make an arbitrary amount of payments on the Lightning Network (as long as you have funds and they are liquid).
An open channel even allows a casi infinite number of payments if you consider the situation where two payment partners pay each other back and forth different amounts over time.
However, sometimes closing a channel is desirable or necessary. For example:
* Your channel partner might be offline for too much time preventing you from utilizing the funds in that channel.
* After analyzing your routing statistics, as well as the network topology, you might have come to the conclusion that it might be better to close some underutilized channels and open some new ones to better connected channel partners.
* Your channel partner might have breached the protocol either due to a software bug or on purpose forcing you to protect your funds.
Different conditions require one or the other way to close a channel.
For example, if your channel partner is offline you will not be able to follow "the good way" because a mutual close cannot be done without a cooperating partner.
The good news is that your Lightning Network software will most likely automatically select the best closing mechanism available to you under your specific conditions.
Whether you as a user implicitly close a channel or the Lightning Network software automatically closes a channel for you due to a detected abnormality (e.g. cheating partner), it is usually the Lightning Network software that choses the appropriate way to close.
It has the same balance as the last commitment transaction but no outputs are encumbered with a time lock.
As finalizing the routing attempts can take some time, a mutual close can also take some time.
The on-chain transaction fees of the on-chain transaction for closing the channel in a mutual way are being paid by the channel partner who opened the channel and not by the person who initiated the closing procedure.
As both channel partners sign the on-chain transaction they have the chance to pay small fees for the Bitcoin transaction by using their on-chain fee estimator.
Even though there is a potential waiting time, this type of channel close is usually faster than closing the bad way.
As discussed before the Bitcoin network has no way of knowing if this was the most recent commitment transaction or an old one which you might have published for a financial gain.
* The most obvious reason is that when the commitment transaction was negotiated you and your channel partner didn't know how high the on-chain fees will be at the future time the "force close" is taking place.
As the fees cannot be changed without reassigning outputs of the commitment transaction which needs two signatures and as the force close usually happens in an urgent situation, the protocol developers decided to be very generous with the fee rate included in the commitment transactions. It can be up to 5 times higher than the fee estimators suggest at the time the commitment transaction is negotiated.
* The pending routing attempts in the commitment transaction are encoded as additional outputs which take up additional on-chain transaction space.
* The pending routing attempts will have to be resolved on-chain causing additional on-chain spend transactions. These additional spend transactions don't have to overestimate the fees but they nonetheless incur costs.
In general, you should not do a "force close" unless absolutely necessary.
Your funds will be locked for a longer time and the person who opened the channel will have to pay higher fees. Furthermore, you might have to pay on-chain fees to abort or settle routing attempts even if you haven't opened the channel.
If the channel partner is known to you, maybe it is even a friend of yours, you might consider contacting that individual or company and inquire why his or her Lightning Node is down and request that they re-start it so that you can come to a preferred "mutual close" of the channel. If that is not an option as last resort perform the more costly "force close".
In case your channel partner tries to cheat you - whether deliberately or not - by publishing an outdated commitment transaction, you will be able to use the timelock to detect this attempt to cheat.
If you are watchful you will detect the protocol breach, i.e. the attempt to cheat, and as reward you will take the funds from the cheater.
If you are watchful, you observe the breach and following the protocol you are permitted to collect on the outputs by using the revocation secret you had previously received to negotiate a newer state of the channel.
That means you can claim the funds from the cheating channel partner.
In this case the closing will be rather fast. You as publisher of the transaction will have to pay the corresponding on-chain fees.
This should not bother you as you just claimed the entire channel capacity and by doing so gained the funds from the cheating channel partner.
If you are not vigilant, you will not notice the breach and thereby empowering your channel partner to collect their outputs after the time lock expired.
In this case the fees of the commitment transaction are again paid by the partner who opened the channel and the fees for collecting the outputs are paid by the person controlling the output that is being collected.
Also all the routing attempts will have to be resolved just as explained during the "force close".
The "ugly way" can be executed faster than the "good" and the "bad way" to close a channel.
Hence, we do not recommend to attempt to cheat. We do, however, recommend that anyone catching a cheater punish him to the fullest by taking his funds.
So, how do you catch a cheat or a protocol breach in your day-to-day activities?
You do so by running software that monitors the public Bitcoin blockchain for on-line transactions that correspond to any of your commitment transaction.
A Lightning node can do this monitoring for you.
Specific Lightning wallets might do this for you.
Running a Lightning node 24x7 will catch all cheats.
Remember that the commitment transaction has a timeout period specified in a given number of blocks, up to a maximum od 2016.
As long as you run your Lightning node once before the timeout period is reached, it will catch all cheats.
To give an example, assume that your commitment transactions have all been set to the maximum timeout of 2016 blocks, roughly corresponding to two weeks.
In this case, if you run your Lightning node only once every Sunday, it will still catch all cheats because in this case the timelock is roughly two weeks.
footnote:[Even if the timeout is set to 2016 blocks, don't wait for two weeks! If the Bitcoin blockchain difficulty is low, blocks will get mined faster and the target block specified in the timeout will be reached in less than two weeks. It is the block number that counts, not the time that has passed. So, in our example the user is prudent as he should be and checks every Sunday and not every two weeks. This gives him a safety margin. ]
In addition, you can delegate this responsibility to someone else.
Someone else can monitor the Bitcoin blockchain for you.
One of these technologies is called a "Watchtower".
How do you not catch a cheat? If you don't do any of the above you will be vulnerable. Image you go on a 3-week sailing trip. Before you leave you turn your Lightning node off to save power and you turn your cell phone off because there is no cell coverage. Now add to that that you have not requested anyone else to monitor for you. In short, your wallet provider does not do it for you and you have no Watchtower or similar service. If your channel partner cheats you during the first two days of your remote vacation, he will be able to steal your funds two weeks later and before you come back from vacation. You will have to be responsible and do a little bit of planning to prevent this vulnerability.
An invoice is nothing more than a simple payment instruction containing various pieces of information such as a unique payment identifier, called a payment hash, a recipient, an amount, etc.
While Lightning Nodes usually use the encrypted communication channels over the Lightning peer-to-peer network to exchange information, invoices are being transferred via a second communication channel.
The payee has to pass the invoice to the payer via any arbitrary means.
This could be done via a Webservice, an instant message on a chat app, an SMS or an Email.
Invoices are usually encoded either as long bech32-encoded strings or as QR codes which enables them to be easily scanned by smartphones.
The invoices contains the amount of bitcoin that is requested and a signature of the payee.
The later is used to extract the address of the payee so that the payer knows whom to send the money.
Did you notice how this contrasts with Bitcoin and how different language terms are used? In Bitcoin, the recipient passes an address to the sender. In Lightning, the payee creates an invoice and sends an invoice to the payer. In Bitcoin, the payer sends funds to an address. In Lightning, the payer pays an invoice and it gets routed to the payee. Bitcoin is based on the concept of an "address", and Lightning is a payment network and based on the concept of an "invoice".
The same way, the analog term to Bitcoin's "transaction" is the term "payment" in Lightning.
The payment process of the Lightning Network is only secure if `r` is chosen completely randomly and is not predictable and as long as the Hash function cannot be inverted.
We note that this is not an additional security assumption for Bitcoin as the security of the Hash function is currently the underlying basis of Bitcoin mining.
These hints can furthermore be used to suggest public channels, e.g. those channels on which the payee has enough inbound liquidity to actually receive the amount.
In case the payer's Lightning node is not able to send the payment over the Lightning Network, invoices can optionally include an on-chain Bitcoin fallback address.
We would however always recommend to open a new Lightning payment channel instead of doing an on-chain Bitcoin payment.
You have already learnt that payments start with the payee creating an invoice which includes a Payment Hash to make sure that payments are atomic and that no one on the path of payment channels can withhold the transferred money to their benefit.
In this section we will dive into the ideas and methods that are being used to deliver a payment over the Lightning Network and utilize everything that we have presented so far.
Every peer can validate the information from the `channel_announcement` message and verify that the funding transaction was indeed confirmed by the Bitcoin network.
As nodes might want to change the meta data of their channel occasionally this information is shared in a `channel_update` message.
These messages will only be forwarded about four times a day for every channel to prevent spam.
The gossip protocol also comes with a variety of queries and tools to initially synchronize a node with the view of the network or to update the node's view after being offline for a while.
A major challenge for the participants of the Lightning Network is that the topology information that is being shared by the gossip protocol is only partial.
2. To be able to scale the amount of payments that can be conducted with the Lightning Network. Remember that the Lightning Network was created in the first place because notifying every participant about every payment does not scale well. Thus for simple technical reasons the Lightning Network cannot be designed in a way that the current balance updates of channels are being shared among participants.
3. The Lightning Network is a dynamic organism. It changes constantly and frequently. Nodes are being added, other nodes are being turned off, balances change, etc. Even if everything is always communicated, the information will be valid only for a short amount of time. As a matter of fact, information might be already outdated by the time it is received.
Payments on the Lightning Network are forwarded along a path of channels from one participant to another.
Thus, a path of payment channels has to be selected.
If we knew the exact channel balances of every channel we could easily compute a payment path using any of the standard path finding algorithms taught in any computer science program.
With only partial information about the network topology available this is a real challenge and active research is still being conducted into optimizing this part of the Lightning Network implementations.
The fact that the path finding problem is not fully solved for the case of the Lightning Network is a major point of criticism towards the technology.
The path finding strategy currently implemented in Lightning nodes is to probe paths until one is found that has enough liquidity to forward the payment.
While this is not optimal and certainly can be improved, it should be noted that even this simplistic strategy works well.
This probing is done by the Lightning node or wallet and is not directly seen by the user of the software.
The user might only realize that probing is taking place if the payment is not going though instantly.
The algorithm currently also does not necessarily result in the path with the lowest fees.
While the TCP/IP protocol stack allows reliable communication by resending packages that are not acknowledged this mechanism could not be reused directly in the Lightning Network.
A payment that is not being forwarded would effectively mean that the money was stolen by a router and the sender cannot just send out another payment.
While the routing protocol together with the Border Gateway Protocol which are used for data and information transport on the internet have the nice property of allowing the internet hosts to collaboratively find a path for the information flow through the internet, we cannot reuse and adopt this protocol for forwarding payments on the Lightning Network.
This includes currently known public payment channels, known nodes, known topology (how known nodes are connected), known channel capacities, and known fee policies set by the node owners.
If the sending node of a payment has selected a path that is supposed to be used to make the payment, the Lightning Network uses an onion routing scheme similar to the famous TOR-network.
Note that Lightning Onion routing via "SPHINX mixformat" is only similar to the TOR network routing in concept, but as a protocol as well as in implementation it is definitely different from the TOR network.
For now we want to focus on its properties for the transport of payments.
A payment package used for routing is called an "onion".
footnote:[The term "onion" was originally used by the TOR project.
The acronym TOR stands for "The Onion Router".
Moreover, the Tor network is also called the Onion network.
The Tor project uses an onion as its logo and the top level domain name used by TOR services on the internet is ".onion".]
As a simplified physical analogy imagine the payment package as a sealed box with a onion inside.
On its route from payer to payee the sealed box is handed from node to node.
Sealed just means that the box is encrypted and only the receiving node can open it.
As will be explained, each node opens the box, takes out the onion, and peals off the outermost layer of this onion by using a cryptographic key.
The receiving node can only read this outermost layer, no further layers, achieved through cryptography.
This outermost layer tells the node if the box needs to be routed further and along which channel which implies the next node.
The node than places the remaining, but one layer smaller, onion into the box and sends the box to the next node on the routing path.
This continues until the receiving node is the payee and the routing stops and the payee can read the information encrypted in the innermost layer of the onion.
Why use a box?
The box is used in this analogy to express that the size of the "package" sent along the route is always the same.
The first recipient receives a box of the same size as the last recipient, the payee.
This is done to create privacy.
If not done, an observer could analyze the size of the communication and deduce how many hops there are on the route.
If the size does not change there is no way to tell if this is the first or the last hop in the route.
The box in our analogy is what technically is called an "onion" in the Lightning network.
1. The most important property is that a routing node can only see on which channel it received an onion and on which channel to set up an HTLCs and thus to which peer to forward the onion.
This means that no routing node can know who initiated the payment and to whom the payment is destined.
The exception is the payee.
The payee knows that it is the final destination.
This is one of the many factors that help in the quest for a high degree of privacy.
2. The onions are small enough to fit into a single TCP/IP package and actually even a link layer frame.
This will make traffic analysis of the payments significantly more difficult, increasing privacy further.
3. The onions are constructed in a way that they will always have the same length independent of the position of the processing node along the path.
This is also done to augment privacy.
4. Onions can have up to 20 hops or onion layers if you prefer. This allows for sufficiently long paths.
5. The encryption of the onion for every hop uses different ephemeral encryption keys with every single onion. Should a key (in particular the private key of the public node key) leak at some point in time an attacker who collected onions cannot decrypt other onions.
In simpler terms, keys are never reused in order to achieve more security.
6. Errors can be sent back from the erring node in an encrypted way to the original sender. This is particularly useful as we have seen that Lightning nodes who initiate the onions select a path without knowing whether every node has enough liquidity along their channels to forward the payment.
We will discuss the details of the Onion Format later. But we note already that the `Payment Hash` which is required to set up the HTLCs for the payment is not transported within the onions.
The `Payment Hash` is rather included in the Lightning Message alongside the onion.
This makes the Payment Hash obtainable without the need to decrypt any onion.
In stark contrast to the Internet Protocol Forwarding Algorithm on the Lightning Network it is only the sender of a payment that decides the path it takes to the recipient.
It contains information about the payment for the recipient, routing hints for the intermediary nodes.
Routing fees which those nodes will earn if (and only if) the payment is successfully delivered and settles with the release of the `Payment Hash` are also included to the onion.
All Lightning Nodes must follow the payment forwarding algorithm.
Upon receiving a Lightning Message called `update_add_htlc` which contains the `Payment Hash` and the onion package it needs to follow through X steps:
1. It needs to decrypt the outer layer of the onion and use the HMAC to make sure that the onion was not corrupted.
2. It will check that it can fulfill the routing hints in the way that the fees are respecting its fee announcements and that it has enough liquidity on the outgoing channel or is even owner of the specified channel.
3. It needs to work with its peer on the incoming channel to update the channel state to include the offered HTLC.
4. It will have to add some padding data to the end of the onion to keep it as a constant size even though it removed some data from the beginning.
5. It will then follow the routing hints from its layer of the onion to forward the modified onion package on its outgoing payment channel by also sending and `update_add_htlc` message which includes the same `Payment Hash` and the onion.
If for example in the first step the node detects that the onion was corrupted it will not proceed to the second and subsequent steps to move forward the channel state on the receiving channel to include the HTLC.
Similarly if in the second step the node discovers that it won't be able to fulfill the routing request or that not enough fees have been included it will also abort the payment forwarding algorithm and rather send back an error.
We node that the error is also an onion reply package.
Even though the node sending the error does not know who initially sent out the payment the error message will be encrypted with the key that was used to encrypt the forwarding nodes layer.
While the likelihood for a payment to fail is pretty high if it does not settle quickly a node SHOULD never initiate another payment attempt along a different path before the onion returned with an error as a node might just have delayed the forwarding of the payment.
Nodes which act maliciously by delaying the forwarding of payments or errors are actually hard to detect due to the privacy properties that are gained with the onion routing scheme.
Most importantly communication is needed to open and close payment channels, to send and receive onions, to set up and settle or fail HTLCs and for exchanging gossip information.
This makes development a little bit tricky as one cannot easily monitor one's own traffic on a tool like wireshark for debugging. footnote:[Luckily tools exist to make developer's lives easier: https://github.com/nayutaco/lightning-dissector]
As long as a person follows the protocol and has their node secured, there is no major risk of losing funds when participating in the Lightning Network.
However, there is the cost of paying on-chain fees when opening a channel.
Any cost should come with a corresponding benefit.
In our case the reward for Alice for bearing the cost of opening a channel is that Alice can send and receive payments of bitcoin on the Lightning Network at any time and that she can earn fees in bitcoin by forwarding payments for other people.
Alice knows that in theory Bob can close the channel immediately after opening resulting in on-chain closing fees for Alice.
Alice will need to have a small amount of trust in Bob.
Alice has been to Bob's Cafe and clearly Bob is interested in selling her coffee, so Alice can trust Bob in this sense.
There are mutual benefits to both Alice and Bob.
Alice decides that the reward is enough for her to take on the cost of the on-chain fee for creating a channel to Bob.
In contrast, Alice will not open a channel to someone unknown in a foreign country who just sent her an uninvitedly email asking her to open a channel to him.
While the Lightning Network is built on top of Bitcoin and inherits many of its features and properties, there are important differences that users of both networks need to be aware of.
==== Addresses vs Invoices, Transactions vs Payments
Bitcoin and Lightning have different terminology.
In Bitcoin, a typical operation is that a user receives a Bitcoin address (e.g. he reads it on a webpage, or he received it in an instant message from a friend).
He then uses his Bitcoin wallet to create a transaction to send funds to this address.
In the Lightning Network all starts at the payee.
The payee creates an invoice.
A Lightning "invoice" could be seen as an analogy to a Bitcoin "address".
The payee provides the Lightning invoice to the payer.
This is similar to Bitcoin, the payee places it on the webpage at checkout, or the payee is a friend and sends it via instant message or email.
The payer uses his Lightning wallet to make the invoice payment (e.g. by scanning a QR code).
In Lightning, "payment" is the analog term for a Bitcoin "transaction".
Along the same lines, in Lightning some users prefer to use "payer" and "payee" to what Bitcoin often refers to as "sender" and "receiver".
This is merely a matter of convention.
These terms just underline that Lightning is a very specific network, it is a "payment" network.
For instance, a user making a payment of 1 BTC can use a single output with value 1 BTC, two outputs with value 0.25 BTC and 0.75 BTC, or four outputs with value 0.25 BTC each.
The entire UTXO needs to be spent, so if a user wishes to spend 0.8 BTC, but only has a 1 BTC UTXO, then they need to send 0.8 BTC to the receiver, and 0.2 BTC back to themselves as change.
This is because the channel partners simply update the channel balance and only create a new UTXO when the channel is eventually closed using the Bitcoin network.
These fees are paid to the miner who mines that particular block.
The amount of the fee is based on the _size_ of the transaction in _bytes_ that the transaction is using in a block, as well as how quickly the user wants that transaction mined.
As miners will typically mine the most profitable transactions first, a user who wants their transaction mined immediately will pay a _higher_ fee-per-byte, while a user who is not in a hurry will pay a _lower_ fee-per-byte.
On the Lightning Network, users pay fees to other users to route payments through their channels.
In order to route a payment, a routing user will have to move the funds in two or more channels they own, as well as transmit the data for the sender's payment.
Typically, the routing user will charge the sender based on the _value_ of the payment, as well as setting their own fees they established to route the payment.
Higher value payments will thus cost more to route, and a market for capacity will exist where different users will charge different fees for routing through their channels.
On the Bitcoin network, miners are profit-seeking and will typically include as many transactions in a block as possible, while staying within the block size limit (actually, a modified form called the block weight limit).
If there are more transactions in the queue (called the mempool) than can fit in a block, they will begin by mining the transactions that pay the highest fees per byte (highest fee per weight).
Thus, if there are many transactions in the queue, users will have to pay a higher fee to be included in the next block, or they will have to wait until there are fewer transactions in the queue.
The scarce resource on the Bitcoin network is the space in the blocks. Bitcoin users compete for block space. And the Bitcoin fee market is based on available block space. The scarce resource in the Lightning network is the capacities on the channels and channel connectivity. Lightning users compete for capacity and connectivity. The Lightning fee market is driven by capacity and connectivity.
On the Lightning Network, users are paying fees to the users routing their payments. Routing a payment in economic terms is nothing else than providing and assigning capacity to the payer.
Different routers will charge different fees for routing through their channels.
Following general economic principles, the more capacity and connectivity is provided the more competition there will be and as a result the lower the fees will be.
The growth of the Lightning Network might lead to lower Lightning fees, while the growth in the Bitcoin Network likely leads to higher Bitcoin fees.
While the addresses involved are pseudonymous and are not typically tied to identity, they will still be collected and validated by every other user on the network.
As payments are onion-routed, the users who route the payment will only be aware of the amount of the payment, but neither the source nor the destination.
This is because the security model of Lightning only requires users to control the balances in their channels.
They are not required to be aware of the state of the entire network.
In summary, Bitcoin transactions are broadcasted publicly and stored forever. Lightning payments are executed between a few selected peers and information about is privately stored and only until the channel is closed.
Creating en-masse analysis tools equivalent to the ones on the Bitcoin network will be impossible on Lightning.
When the channel is closed, a transaction will be made on the Bitcoin network and, only once that transaction is confirmed will the channel be considered closed.
For instance, if a user owns one channel with 0.4 BTC on their side, and another channel with 0.2 BTC on their side, then the maximum they can send with one payment is 0.4 BTC.
At the time of writing, Atomic Multi-Path Payments (AMPs) are in development which, in the above example, would allow the user to combine both their 0.4 BTC and 0.2 BTC channels to be able to send a maximum of 0.6 BTC with one payment.
In a direct payment where payer and payee are connected via a channel, the limit is stated as above.
If the payment gets routed, every routing node along the routing path must have at least the amount of funds as indicated in the payment.
If person A pays person C via person B, the payment follows the route A-B-C.
Say, person A wants to pay C the amount of 0.4 BTC.
Then both A as well as B must have 0.4 BTC available in their respective channels A-B and B-C.
The same holds true for longer routes.
There must be enough liquidity available on the channel for the node that wants to forward the payment.
This must hold true for every single channel that the payment is routed through.
The lowest capacity of a channel set the upper limit of the full route through this channel.
Hence, capacity and connectivity are crucial resources in the Lightning network.
On the Lightning Network, the balance in a channel at a particular time is known only to the two channel partners, and is only made visible to the rest of the network when the channel is closed.
When the channel is closed, the final balance of the channel is submitted to the Bitcoin blockchain, and each partner receives their share of the bitcoin in that channel.
For instance, if the opening balance was 1 BTC paid by Alice, and Alice made a payment of 0.3 BTC to Bob, then the final balance of the channel is 0.7 BTC for Alice and 0.3 BTC for Bob.
If Alice tries to cheat by submitting the opening state of the channel to the Bitcoin blockchain, with 1 BTC for Alice and 0 BTC for Bob, then Bob can retaliate by submitting the true final state of the channel, as well as create a penalty transaction that gives him all bitcoin in the channel.
For the Lightning network, the Bitcoin blockchain acts as a court system.
Like an arbitrer Bitcoin records the initial and final balances of each channel, and approves penalties if one of the parties tries to cheat.
The recipient could be logically speaking "online" (e.g. run a node) or could be "offline" (e.g. does not run a node, does not use any wallet currently).
The transaction is registered in the blockchain, and at any later point in time the recipient can have a look at it and see that has has received funds in the past.
In Bitcoin, the recipient can be "offline" and the interaction is asynchronous, sender and receiver do not need to synchronize in any way.
In Lightning, this is different.
The node that represents the payee must be "online" during the transaction.
The payee must run a node or have someone that runs a node for him.
That node must be "online" at the time of the payment.
To be precise, both nodes, the payer's and the payee's must be online at the time of payment.
The payer and payee must cooperate, i.e. in some fashion one could say "synchronize" , during the payment.
If the payee's node is down the payer cannot make the payment.
Both, Bitcoin transactions and Lightning payments are irrevocable.
There is no "undo" operation for either one.
As a user of either one you have to act responsibly.
==== Trustlessness
Just as Bitcoin, Lightning requires the user only to trust mathematics, encryption and that the Lightning code does not have any critical bugs.
Neither Bitcoin nor Lightning require the user to trust a person, a company, an institution or a government.
Since Lightning sits on top of Bitcoin and relies on Bitcoin as its underlying base layer, it is clear that the security model of Lightning reduces to the security of the base blockchain.
In other words, Lightning can never be more trustless than Bitcoin.
==== Permissionlessness
Both Bitcoin and Lightning can be used by anybody with access to the Internet and to the appropriate software, e.g. node and wallet.
The user of neither network requires permission from third-party persons, companies, institutions or a government.
The user does not need permission from anybody as long as he has access to Internet and can run his node or wallet.
Governments can only outlaw Bitcoin or Lightning locally in their jurisdiction, but they cannot prevent their global use.
==== Open Source
Both, Bitcoin and Lightning are open source software and are built by a decentralized global community on open source principles.
