@ -6,13 +6,24 @@ Welcome to Mastering the Lightning Network!
The Lightning Network, abbreviated with LN, is a protocol for using Bitcoin in a smart and non-obvious way.
Thus it is a second layer technology on top of Bitcoin.
It is changing the way people exchange value online and it's one of the most exciting advancements to happen to the Bitcoin network over the past few years. Right now, the Lightning Network is in its infancy. In concept it's about 5 years old, in implementation about 3 years old. We're only beginning to see the opportunities the Lightning Network provides including improved privacy, speed, and scale. With core knowledge of the Lightning Network, you can help shape the future of the network while building opportunities for yourself as well. Some basic knowledge about Bitcoin is assumed but can be readily acquired by reading the first two chapters of _Mastering Bitcoin_ which are available for free online.
It is changing the way people exchange value online and it's one of the most exciting advancements to happen in Bitcoin's history.
Today, in 2020, the Lightning Network is in its infancy.
In concept it was first proposed in 2015 and the first implementation was launched in 2018.
As of 2020, we're only beginning to see the opportunities the Lightning Network provides including improved privacy, speed, and scale.
With core knowledge of the Lightning Network, you can help shape the future of the network while building opportunities for yourself as well.
Some basic knowledge about Bitcoin is assumed but can be readily acquired by reading the first two chapters of _Mastering Bitcoin_ which are available for free online.
While the bulk of this book is written for programmers, the first two chapters are written to be approachable by anyone regardless of technical experience. In order to better understand how the technology actually works, and why people use it, we'll be following a number of users and their stories. But first, we'll introduce some of the key concepts in the Lightning Network. Let's get started with why the Lightning Network was proposed in the first place.
=== Motivation for the Lightning Network
As Bitcoin and the demand for transactions grows, the number of transactions in each block will increase until it eventually hits the block size limit. When blocks are full, excess transactions are left to wait in a queue. Many users increase the fees they're willing to pay in order to buy space for their transaction in the next block. At the same time, an increasing number of users are left behind. Their transactions, e.g. microtransactions such as common small spendings, are not economically qualified to be on the network. However, increasing block size simply shifts the problem to node operators, where each increase in blocksize results in a resource increase multiplied by an order of magnitude.
As Bitcoin and the demand for transactions grows, the number of transactions in each block will increase until it eventually hits the block size limit.
When blocks are full, excess transactions are left to wait in a queue.
Many users will increase the fees they're willing to pay in order to buy space for their transaction in the next block.
At the same time, an increasing number of users are left behind.
Their transactions, e.g. microtransactions such as common small spendings, are not economically qualified to be on the network.
We could increase the block size to create space for these smaller transactions.
However increasing block size simply shifts the problem to node operators, and requires them to expend resources to faciliate these additional transactions.
Because blockchains are gossip protocols, each node is required to know and validate every single transaction that occurs on the network. Furthermore, once validated, each transaction and block must be propagated to the node's "neighbors", multiplying the bandwidth requirements. As such, the greater the block size, the greater the bandwidth, processing, and storage requirements for each individual node, effectively limiting the amount of scaling that can be done this way. Furthermore, scaling in this fashion has an undesirable side effect of centralizing the network by reducing the number of nodes and node operators. Since node operators are not compensated for running nodes, if nodes are very expensive to run, only a few well funded node operators will continue to run nodes.
@ -22,18 +33,25 @@ The side effects of increasing the block size or decreasing the block time with
Let us assume the usage of Bitcoin grows so that the network has to process 40,000 transactions per second.
Assuming 250 Bytes on average per transaction this would result in a data stream of 10 Megabyte per second or 80 Mbit/s just to be able to receive all the transactions.
This does not include the traffic overhead of forwarding the transaction information to other peers.
While single hosts on the internet could handle such a load of traffic our current internet would not be able to support this traffic for a large fraction of hosts.
Also storing this information locally would result in 864,000 Megabyte per day. This is roughly 1 Terabyte of data or the size of a hard drive.
While 10 MB/s does not seem extreme in the context of high speed fibre and 5G mobile speeds, it would effectively exclude anyone who cannot meet this requirement from running a node, especially in countries where high-performance internet is not affordable or widely available.
Users also have many other demands on their bandwidth and cannot be expected to expend this much only to receieve transactions.
Furthermore storing this information locally would result in 864,000 Megabyte per day. This is roughly 1 Terabyte of data or the size of a hard drive.
While verifying 40,000 ECDSA signatures per second seems barely feasible (c.f.: https://bitcoin.stackexchange.com/questions/95339/how-many-bitcoin-transactions-can-be-verified-per-second) nodes could hardly catch up initial sync of the blockchain.
====
But what if each node wasn't required to know and validate every single transaction? What if there was a way to have scalable off-chain transactions, without losing the security of the Bitcoin network?
In February 2015, Joseph Poon and Thaddeus Dryja proposed a possible solution to the Bitcoin Scalability Problem, with the publication of _"The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments"_ footnote:[Joseph Poon, Thaddeus Dryja - "The Bitcoin Lightning Network:
Scalable Off-Chain Instant Payments" (https://lightning.network/lightning-network-paper.pdf).] In the meanwhile outdated whitepaper, Poon and Dryja estimate that in order for Bitcoin to reach the 47,000 transactions per second processed at peak by Visa, it would require 8 GB blocks. This would make running a node completely untenable for anyone but large scale enterprises and industrial grade operations. The result would be a network in which only a few users can actually validate the state of the ledger, which ultimately breaks the trust model of Bitcoin.
In February 2015, Joseph Poon and Thaddeus Dryja proposed a possible solution to the Bitcoin Scalability Problem, with the publication of _"The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments"_
In the meanwhile outdated whitepaper, Poon and Dryja estimate that in order for Bitcoin to reach the 47,000 transactions per second processed at peak by Visa, it would require 8 GB blocks.
This would make running a node completely untenable for anyone but large scale enterprises and industrial grade operations.
The result would be a network in which only a few users can actually validate the state of the ledger.
Bitcoin relies on users validating the ledger for themselves, without explicitly trusting third parties, in order to stay decentralized.
Pricing users out of running nodes forces the average user to trust third parties to discover the state of the ledger, ultimately breaking the trust model of Bitcoin.
The Lightning Network proposes a new network, a "second layer", where users can make payments to each other peer-to-peer, without the necessity to publish a transaction to the Bitcoin blockchain for each payment.
Users may pay each other on the Lightning Network as many times as they want, making use of the Bitcoin blockchain only in order to load bitcoin onto the Lightning network initially and to "settle", that is: remove bitcoin from the Lightning Network.
Users may pay each other on the Lightning Network as many times as they want, without creating additional bitcoin transactions or incurring on-chain fees.
They will only make use of the Bitcoin blockchain in order to load bitcoin onto the Lightning network initially and to "settle", that is: remove bitcoin from the Lightning Network.
The result is that many more Bitcoin payments can take place "off-chain", with only the initial loading and final settlement transactions needing to be validated and stored by Bitcoin nodes.
Aside from reducing the burden on nodes, payments on the Lightning Network will be cheaper for users as they do not need to pay blockchain fees, and more private for users as they are not published to all participants of the network and furthermore not stored permanently.
@ -71,7 +89,7 @@ The Lightning Network is a network that operates as a "second layer" protocol on
* Once a payment on the Lightning Network has completed, usually within a few seconds, it is final and cannot be reversed. Like a Bitcoin transaction, a payment on the Lightning Network can only be refunded by the recipient.
* While "on-chain" Bitcoin transactions are broadcast and verified by all nodes in the network, payments routed on the Lightning Network are transmitted between pairs of nodes and are not visible to everyone, resulting in much greater privacy.
* Unlike transactions on the Bitcoin Network, payments routed on the Lightning Network do not need to be stored permanently. Lightning thus uses fewer resources, hence it is cheaper. This property also has benefits for privacy.
* The Lightning Network uses onion routing, similar to the protocol used by The Onion Router (TOR) privacy network, so that even the nodes involved in routing a payment are only directly aware of their predecessor and successor in the payment route.
* The Lightning Network uses onion routing, similar to the protocol used by The Onion Router (Tor) privacy network, so that even the nodes involved in routing a payment are only directly aware of their predecessor and successor in the payment route.
[[user-stories]]
=== Lightning Network Use Cases, Users, and Their Stories
@ -91,7 +109,11 @@ web designer::
Saanvi is a web designer and developer in Bangalore, India. She accepts bitcoin for her work, but would prefer to get paid more frequently and so uses the Lightning Network to get paid incrementally for each small milestone she completes. With the Lightning Network, she can do more small jobs for more clients without worrying about fees or delays.
content creator / curator::
John is a 9-year-old boy from New Zealand, who wanted a games console just like his friends. However, his dad told him that in order to buy it, he had to earn the money himself. Now John is an aspiring artist, so he knows that while he is still improving, he can't charge much for his artwork. After learning about Bitcoin, he managed to set up a website to sell his drawings across the internet. By using the Lightning Network, John was able to charge as little as $1 for one of his drawings, which would normally be considered a micro-payment and, as such, not possible with other payment methods. Furthermore, by using a global currency such as bitcoin, John was able to sell his artwork to customers all over the world and, in the end, buy the games console he so desperately wanted.
John is a 9-year-old boy from New Zealand, who wanted a games console just like his friends. However, his dad told him that in order to buy it, he had to earn the money himself. Now John is an aspiring artist, so he knows that while he is still improving, he can't charge much for his artwork.
After learning about Bitcoin, he managed to set up a website to sell his drawings across the internet.
By using the Lightning Network, John was able to charge as little as $1 for one of his drawings, which would normally be considered a micro-payment and, as such, would typically be impossible on traditional systems.
Furthermore, most legacy financial systems wouldn't even allow a 9-year old like John to open an account!
By using a global currency such as bitcoin, John was able to sell his artwork to customers all over the world, store the money he's earned without a bank account and, in the end, buy the games console he so desperately wanted.
gamer::
Gloria is a teenage gamer from the Philippines. She plays many different computer games, but her favorite ones are those that have an "in-game economy" based on real money. As she plays games, she also earns money by acquiring and selling virtual in-game items. The Lightning Network allows her to transact in small amounts for in-game items as well as earn small amounts for completing quests.
@ -22,10 +22,13 @@ The below is an inexhaustive list (in alphanumerical order):
[TIP]
====
Note that if using Lightning explorers, just like in existing block explorers,
the privacy can be a concern because, if users are careless, the website may track their IP addresses and collect their behavior records (for example, the nodes users are interested in).
Note that when using Lightning explorers, just like with existing block explorers, privacy can be a concern.
If users are careless, the website may track their IP addresses and collect their behavior records (for example, the nodes users are interested in).
Also what should be noted is that, as there is no global consensus of the current Lightning graph, nor the current state of any existing channel policy, users should never rely on Lightning explorers to retrieve the most updated information. That is, Lightning explorers should only be used to gather loosely statistics of Lightning Network.
Also it should be noted that as there is no global consensus of the current Lightning graph or the current state of any existing channel policy, users should never rely on Lightning explorers to retrieve the most updated information.
Furthermore as users open, close, and update channels, the graph will change and individual Lightning explorers may not be up to date.
Users should instead be running their own node to build a channel graph and stay informed of the latest state of the network.
Where they use Lightning explorers, it should be sparingly or to gather statistics.
====
=== Lightning Wallets
@ -107,6 +110,7 @@ In <<lnwallet-examples>> we see some examples of currently popular Lightning nod
| c-lightning | Server | Full Node | Bitcoin Core | Self-Custody
| Eclair Server | Server | Full Node | Bitcoin Core/Electrum | Self-Custody
@ -263,7 +263,14 @@ When new nodes join the Lightning Network they collect the channel announcements
==== Closing the channel
The best way to close a channel is... to not close it! Opening and closing channels requires an on-chain transaction, which will incur transaction fees. So it's best to keep channels open as long as possible. You can keep using your channel to make and forward payments, as long as you have sufficient capacity on your end of the channel. But even if you send all the balance to the other end of the channel, you can then use the channel to receive payments from your channel partner. This concept of using a channel in one direction and then using it in the opposite direction is called "re-balancing" and we will examine it in more detail in another chapter. By re-balancing a channel, it can be kept open almost indefinitely and used for essentially unlimited number of payments.
The best way to close a channel is... to not close it!
Opening and closing channels requires an on-chain transaction, which will incur transaction fees.
So it's best to keep channels open as long as possible.
You can keep using your channel to make and forward payments, as long as you have sufficient capacity on your end of the channel.
But even if you send all the balance to the other end of the channel, you can then use the channel to receive payments from your channel partner.
This concept of using a channel in one direction and then using it in the opposite direction is called "re-balancing" and we will examine it in more detail in another chapter.
By re-balancing a channel, it can be kept open almost indefinitely and used for essentially unlimited number of payments.
However, sometimes closing a channel is desirable or necessary. For example:
@ -274,80 +281,112 @@ However, sometimes closing a channel is desirable or necessary. For example:
There are 3 ways to close a payment channel:
* The good way - Mutual close
* The bad way - Force close
* The ugly way - Protocol breach
* Mutual close (the good way)
* Force close (the bad way)
* Protocol breach (the ugly way)
Each of these methods is useful for different circumstances which we will explore in the next section of this chapter.
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.
Usually, your Lightning Network software will automatically select the best closing mechanism available under the circumstances.
Which way you close a channel will depend on the circumstances. 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.
Usually, you Lightning Network software will automatically select the best closing mechanism available under the circumstances.
===== Mutual close (the good way)
Whether you (the user) issue a command to close a channel or the Lightning Network software automatically closes a channel due to a detected anomaly (e.g. cheating partner), it is usually the Lightning Network software that chooses the appropriate way to close the channel.
Mutual Close is when both channel partners agree to the closure of a channel and is the preferred method of channel close.
When you decide that you want to close a channel, your Lightning Network node will inform your channel partner about your intention.
Now both your node and the channel parter's node work together to close the channel.
No new routing attempts will be accepted from either channel partner and any ongoing routing attempts will be settled or removed after they time-out.
Finalizing the routing attempts takes time, so a mutual close can also take some time to complete.
===== The good way - Mutual close
Once there are no pending routing attempts, the nodes cooperate to prepare a _closing transaction_.
This transaction is similar to the commitment transaction; it encodes the last balance of the channel but the outputs are NOT encumbered with a time lock.
The good way to close a channel is the mutual close and this way is always preferred, if possible. When you decide that you want to close a channel, your Lightning Network node will inform your channel partner about your intention. Now both your node and the channel parter's node work together to close the channel. No new routing attempts will be accepted from either channel partner and any ongoing routing attempts will be settled or removed after they time-out. Finalizing the routing attempts takes time, so a mutual close can also take some time to complete.
The on-chain transaction fees for the closing transaction are paid by the channel partner who opened the channel and not by the one who initiated the closing procedure.
Using the on-chain fee estimator, the channel partners agree on the appropriate fee and both sign the closing transaction.
Once there are no pending routing attempts, the nodes cooperate to prepare a _closing transaction_. This transaction is similar to the commitment transaction, in that it distributes the channel balance to each channel partner according to their last commitment. Unlike the last commitment transaction, the outputs are not encumbered with a time lock.
Once the closing transaction is broadcast and confirmed by the Bitcoin network, the channel is effectively closed and each channel partner has received their share of the channel balance.
Depsite the waiting time, a mutual close is typically faster than a force close.
The on-chain transaction fees for the closing transaction are paid by the channel partner who opened the channel and not by the one who initiated the closing procedure. Using the on-chain fee estimator, the channel partners agree on the appropriate fee and both sign the closing transaction.
Once the closing transaction is broadcast and confirmed by the Bitcoin network, the channel is effectively closed and each channel partner has received their share of the channel balance. A mutual close is usually the fastest way to close a channel.
===== Force close (the bad way)
===== The bad way - Force close
A Force Close is when one channel partner attempts to close a channel without the other channel partner's consent.
Mutual close is not always possible. Sometimes, for example if your channel partner cannot be reached, you have to unilaterally close the channel in order to "free" the funds. Closing the channel unilaterally is called a _force close_. To do a force close, Alice can simply publish the last commitment transaction. After all, that's what commitment transactions are for - they offer a guarantee that Alice doesn't need to trust Bob to retrieve the balance of the channel that belongs to her.
This is usually in the case that one of the channel partners is unreachable, and so a mutual close is not possible.
In this case, you would initiate a force close to unilaterally close the channel and "free" the funds.
Once Alice broadcasts the last commitment transaction she has to the Bitcoin network and it is confirmed, it will create two spendable outputs, one for Alice and one for Bob. As we discussed previously, because this commitment transaction is held by Alice, it gives a slight "advantage" to Bob. Alice's output will have a timelock delay and Bob's will be spendable immediately. This is to protect Bob, so that Alice can't broadcast an old commitment transaction and steal some of the balance. The timelock delay gives Bob the opportunity to "dispute" the transaction using the revocation secret and punish Alice for cheating.
To initiate a force close, you can simply publish the last commitment transaction your node has.
After all, that's what commitment transactions are for - they offer a guarantee that you don't need to trust your channel to retrieve the balance of your channel.
Once you broadcast the last commitment transaction the Bitcoin network and it is confirmed, it will create two spendable outputs, one for you and one for your partner.
As we discussed previously, the Bitcoin network has no way of knowing if this was the most recent commitment transaction or an old one which was published to steal from your partner.
Hence this commitment transaction will give a slight "advantage" to your partner.
The partner who initiated the force close will their output encumbered by a timelock, and the other partner's output will be spendable immediately.
In the case that you broadcasted an earlier commitment transaction, the timelock delay gives your partner the opportunity to "dispute" the transaction using the revocation secret and punish you for cheating.
When publishing a commitment transaction during a force close, the on-chain fees will be higher than a mutual close for several reasons:
. When the commitment transaction was negotiated, the channel partners didn't know how much the on-chain fees would be at the future time the transaction would be broadcast. Since the fees cannot be changed without changing the outputs of the commitment transaction (needs both signatures) and since the force close happens when a channel partner is not available to sign, 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 commitment transaction includes additional outputs for any pending routing attempts (HTLCs), which makes the commitment transaction bigger than a mutual close transaction. Bigger transactions incur more fees.
. The commitment transaction includes additional outputs for any pending routing attempts (HTLCs), which makes the commitment transaction larger (in terms of bytes) than a mutual close transaction. Larger transactions incur more fees.
. Any pending routing attempts will have to be resolved on-chain causing additional on-chain transactions.
[NOTE]
====
Hash Time-Locked Contracts (HTLCs) will be covered in detail in <<htlcs>>. For now, assume that these are payments that are routed across the Ligntning Network, rather than payments made directly between the two channel partners. These HTLCs are carried as additional outputs in the commitment transactions, thereby increasing the transaction size and on-chain fees.
Hash Time-Locked Contracts (HTLCs) will be covered in detail in <<htlcs>>.
For now, assume that these are payments that are routed across the Ligntning Network, rather than payments made directly between the two channel partners.
These HTLCs are carried as additional outputs in the commitment transactions, thereby increasing the transaction size and on-chain fees.
====
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.
In general, a force close is not recommended 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 didn't open the channel.
If the channel partner is known to you, you might consider contacting that individual or company and inquire why their Lightning Node is down and request that they restart it so that you can achieve a mutual close of the channel.
You should consider a force close, only as the last resort.
You should consider a force close only as the last resort.
===== The ugly way - Protocol breach
===== Protocol Breach (the ugly way)
If your channel partner broadcasts an old (revoked) commitment transaction - whether deliberately or not - your node should be able to detect this protocol breach. Your node must be online and watching new blocks and transactions on the Bitcoin blockchain to detect this. Because your channel partner's payment will be encumbered by a timelock, your node has some time to act, before your channel partner can spend the payment and profit from the protocol breach.
A Protocol Breach is when your channel partner tries to cheat you, whether deliberately or not, by publishing an outdated commitment transaction to the Bitcoin blockchain, essentially initiating a (dishonest) force close from their side.
During the timelock, your node can broadcast a _punishment transaction_ that takes your own balance and uses the revocation secret to also take the balance of your channel partner.
Your node must be online and watching new blocks and transactions on the Bitcoin blockchain to detect this.
Because your channel partner's payment will be encumbered by a timelock, your node has some time to act.
You have until the time lock expires to detect a protocl breach and publish a _punishment transaction_.
If you successfully detect the protocol breach and enforce the penalty, you will receive all of the funds in channel, including your channel partner's funds.
In this scenario the channel closure will be rather fast. You will have to pay on-chain fees to publish the punishment transaction, but your node can set these fees according to the fee estimation and not overpay. Furthermore, you will be taking the funds from your channel partner's balance too, so in a way the fees are unlikely to be a factor.
In this scenario the channel closure will be rather fast.
You will have to pay on-chain fees to publish the punishment transaction, but your node can set these fees according to the fee estimation and not overpay.
You will generally want to pay higher fees to guarantee confirmation as soon as possible.
However, as you will eventually receive all of the cheater's funds, it is essentially the cheater who will be paying for this transaction.
If your node is not online and the timelock expires, your channel partner will be able to take whatever balance was allocated to them in that old commitment, perhaps as much as the entire channel balance. If there is any balance allocated to you, you will have to pay on-chain fees to collect that balance.
If you fail to detect the protocol breach and the timelock expires, you will receive only the funds allocated to you by the commitment transaction your partner published.
Any funds you received after this will have been stolen by your partner.
If there is any balance allocated to you, you will have to pay on-chain fees to collect that balance.
Also all pending routing attempts will have to be resolved just as we saw in the force close scenario.
As with a force close, all pending routing attempts will also have to be resolved in the commitment transaction.
The "ugly way" of channel closure can be executed faster than both the "good" and "bad" ways, because you can immediately publish the punishment transaction and collect all the funds.
A Protocol Breach can be executed faster than a mutual close, as you do not wait to negotiate a close with your partner, and faster than a force close as you do not need to wait for your timelock to expire.
Game theory predicts that cheating is not a successful strategy because it is easy to detect a cheater and the cheater will lose all funds committed in the channel.
Game theory predicts that cheating is not an appealing strategy because it is easy to detect a cheater, and the cheater risks losing _all_ of their funds while only standing to gain what they had in an earlier state.
Furthermore, as the Lightning Network matures, and watchtowers become widely available, cheaters will be able to be detected by a third party even if the cheated channel partner is offline.
Hence, we do not recommend cheating. We do, however, recommend that anyone catching a cheater punish them by taking their funds.
Hence, we do not recommend cheating.
We do, however, recommend that anyone catching a cheater punish them by taking their 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-chain transactions that correspond to any commitment transactions for any of your channels.
This software is either:
You do so by running software that monitors the public Bitcoin blockchain for on-line transactions that correspond to any commitment transactions for any of your channels. This software is either:
* A properly maintained Lightning node, running 24x7.
* A properly maintained Lightning node, running 24/7.
* A single-purpose _watchtower_ node that you run to watch your channels.
* A third-party watchtower node that you pay to watch your channels.
We will look at watchtowers in more detail in <<watchtowers>>.
Remember that the commitment transaction has a timeout period specified in a given number of blocks, up to a maximum of 2016.
As long as you run your Lightning node once before the timeout period is reached, it will catch all cheats. It is not advisable to take this kind of risk; it is just as easy to keep a well maintained node running continuously.
Remember that the commitment transaction has a timeout period specified in a given number of blocks, up to a maximum of 2016 blocks.
As long as you run your Lightning node once before the timeout period is reached, it will catch all cheating attempts.
It is not advisable to take this kind of risk; it is just as easy to keep a well maintained node running continuously.
- Does a node need to keep up with all gossip updates? Does this change if they're a routing node or mobile client?
* Protocol Extensions via Feature Bits and TLV:
- How can the channel graph be upgraded using feature bits and TLV fields?
- How does a receiver signal that they can accept MPP/AMP payments?
* How can the channel graph be upgraded using feature bits and TLV fields?
* How does a receiver signal that they can accept MPP/AMP payments?
### What are "Zombie" channels and why do they matter?
A zombie channel can be defined as a channel in which your channel partner has been inactive for so long, that you do not expect them come back online in the future.
This could be because your channel partner has lost access to their or has permanently shut down that node.
As such, a zombie channel is technically still an open channel, but cannot be used to route payments.
Zombie channels offer no benefit to the user but have several downsides:
* Any capacity you have locked in the channel is useless for routing payments and could be allocated elsehwere
* If you lose access to your own node and restore it with only your private key, you will lose access to funds in open zombie channels
* If you lose access to your own node and restore it with your private key and channel backups, you will not be able to contact your channel partner to cooperatively close the channel and may also lose the funds
* Public zombie channels are a burden on the network, as information about them is communicated to the rest of the network, but they cannot be used to route payments
Identifying zombie channels is a challenge as it is not always clear if the channel partner is permanently offline.
A partner node that is offline for a long period may eventually return online in the future.
However, once a zombie channel is identified, it is recommended to close them and a force close is generally required.
### Gossip Announcements
#### How does a peer announce a new channel to the network?
Let's assume that Alice and Bob have just opened a channel together.
How do they let the rest of the network know, so that the channel can be used for forwarding payments?
Well firstly, they don't need to.
Alice and Bob can choose not to announce the channel and simply use it to transfer bitcoin between each other.
In this case, they won't earn any fees for forwarding payments.
However, assuming they do want the channel to be public, they will have marked the channel as public when they initially agreed to open it.
First, they'll have to wait until the funding transaction is confirmed (usually six confirmations).
Once it's confirmed, Alice's and Bob's nodes will now use the `channel_announcement` message to let the rest of the network know the good news.
This announcement message contains some important information:
* *Channel ID*: a short description of the channel that tells users which outputs in which transaction in which Bitcoin block were used to fund the channel
* *Signatures from Alice and Bob*: Remember that the channel funds are locked in a 2-of-2 multisignature address, for which Alice and Bob each hold one of the two keys.
Alice and Bob will each sign from their key, proving that their nodes control the funds in the channel.
They will then send this `channel_announcement` message to each of their peers.
Note that while the `channel_announcement` message makes their peers aware of their channel, their peers won't yet be able to use the channel for forwarding payments.
First, Alice or Bob will have to communicate other information, such as their fee policy, which we will discuss below.
But first, how do their peers verify that the channel announcement is legitimate?
#### Verifying the channel
Let's assume Wei receives this announcement from Bob.
How does he know that this is a real channel, and why should he even bother to check it?
Well, verifying a channel is pretty important.
If Wei tries to forward any payments through a channel that doesn't exist, his payments are going to fail.
Even if the channel does exist, Wei still needs assurances that Bob and Alice actually control the funds inside of it.
Alice and Bob could potentially dupe him by claiming ownership of a channel that actually belongs to someone else.
So Wei will definintely want to verify before he updates his channel graph.
Firstly, Wei will check the channel ID to discover which Bitcoin transaction contains the channel funds.
He will then look up this transaction on the Bitcoin blockchain and he should discover a P2WSH bitcoin UTXO that is signed by both Alice and Bob.
Secondly, Wei will verify the signatures in the channel annoucenment message and confirm that the two nodes who signed the channel announcement are actually Alice and Bob.
Once he's done so, he's convinced that the channel is funded and that Alice and Bob are the funders and owners of that channel.
If any of these checks fail, he'll ignore the channel announcement.
Once Wei is satisifed that the channel announcement checks out, he'll update his channel graph.
He will also send information about this channel to his peers, and they will verify it for themselves.
* presentation layer, applications, how payment details are exchanged
Relevant questions to answer:
* What is BOLT 11?
* What information does an invoice contain?
* How can invoices be extended to integrate new protocol features?
* What are some unique things that can be done with LN?
* recurring payments
* donation addrs
* keysend
* custom data
- recurring payments
- donation addrs
- keysend
- custom data
=== What information does an invoice contain?
@ -76,41 +78,51 @@ If we enter the above invoice into a invoice decoding tool, such as https://lnde
=== What are some unique things that can be done with LN?
**Micropayments**: The current financial system in most countries is divisible to a certain extent and not lower (E.g. $1 = 100c).
However it is usually not viable to send small amounts, e.g. $1 and less, due to transaction fees and other friction in the system.
**Micropayments**: The currencies in most countries are divisible to a certain extent and not lower (e.g. $1 = 100c).
However, it is usually not viable to send small amounts, e.g. $1 and less, due to transaction fees and other friction in the system.
Bitcoin has similar issues due to transaction fees, and fees are likely to increase in the long-term.
The Lightning Network can reasonably accommodate payments of the value of 1 satoshi i.e. one hundred millionth of a Bitcoin.
The Lightning Network can reasonably accommodate payments of the value of 1 satoshi, i.e. one hundred millionth of a Bitcoin.
Even at an obscenely high Bitcoin value of $1m per Bitcoin, this would still allow the transfer of 1 US cent worth of value.
As many Lightning implementations track values to the thousandth of a Satoshi (i.e. one milli-satoshi), payments could conceivably be even smaller than this.
This would allow for micropayment business models such as "pay-per-article", which are not viable in the current system.
This would allow for micropayment business models such as "pay-per-article" or "pay-per-minute", which are not viable in the current financial system.
**Anonymous Payments**: Bitcoin is pseudonymous at best and transactions are permanently stored on the public Bitcoin blockchain.
Hence there is always a risk that transactions can be linked back to users post-hoc.
Hence, there is always a risk that transactions can be linked back to users post-hoc.
Technologies like CoinJoin and Pay-to-EndPoint can assist in giving Bitcoin users a greater degree of anonymity but cannot completely solve this problem.
In contrast, users of the Lightning Network are not aware of other users' payments and, since channels can be private, they may not even be aware of other users' channels.
Users are only aware of other users' payments insofar as they assist in routing payments; in this case they are unaware of both the source and the destination of the payment.
As such, the Lightning Network has a strong use case for anonymous purchases.
This would be of particular benefit to online stores and exchanges that accept Bitcoin as malicious attackers can monitor their addresses on the Bitcoin network to try and determine how much bitcoin the businesses owns; something that is not possible on the Lightning Network
As such, the Lightning Network provides for strong use cases for anonymous purchases.
This would be of particular benefit to online stores and exchanges that accept Bitcoin as malicious attackers can monitor their addresses on the Bitcoin network to try and determine how much bitcoin the businesses owns
footnote:[One variant of this is called a "dust attack", whereby an attacker can send a very small amount of Bitcoin (called a "dust output") to an address it knows is owned by a store or exchange.
By monitoring where this small amount of bitcoin moves, it can determine which other addresses the exchange to store owns.
This kind of attack is not possible on the Lightning Network].
This is not possible on the Lightning Network
**Multiplayer Games**: Lightning Payments can be integrated into online and collaborative games.
One example of this is Satoshi's Place, an online billboard where users can pay 1 satoshi to paint 1 pixel on a million pixel canvas.
What emerges is a constantly changing picture where anyone add, remove, or paint over by paying.
This example can be extended to many other kinds of collaborative games where users can pay to participate.
One example of this is _Satoshi's Place_, an online billboard where users can pay 1 satoshi to paint 1 pixel on a one-million-pixel canvas.
What emerges is a constantly changing picture, where anyone can add, remove, or paint over pixels by paying.
This example can be extended to many other kinds of collaborative games, where users can pay to participate.
The Lightning Network can also be implemented directly into online games, such as MMORPGs, to facilitate in-game transactions.
As Lightning wallets and Lightning invoices can be built directly into the games themselves, this completely bypasses the need for the credit cards and the traditional financial system.
As Lightning wallets and Lightning invoices can be built directly into the games themselves, this completely bypasses the need for credit cards and the traditional financial system.
While all of this is technically possible on Bitcoin, confirmation times and fees make this unfeasible.
Transactions are confirmed on average every ten minutes, although it could potentially take even longer.
Bitcoin transactions are confirmed on average every ten minutes, although it could potentially take even longer.
This exposes the merchant to the risk of accepting unconfirmed transactions.
Lightning transactions, on the other hand, settle instantly and so are better from a user experience standpoint for.
Lightning transactions, on the other hand, settle instantly and so are better from a user experience standpoint.
**Earning "interest" on Bitcoin trustlessly**
While Bitcoin may increase or decrease in value in terms of fiat currencies, it is an asset that does not offer a return in and off itself simply by holding it.
The amount of Bitcoin one holds remains constant, and actually decreases as one moves it around due to transaction fees.
Those wishing to earn a return on their holdings in Bitcoin terms can do so by opening channels and routing payments in return for routing fees.
In this way, users can earn a return (i.e. "interest") by locking their Bitcoin into channels and offering liquidity to other users wishing to transact on the Lightning Network.
Users doing so will need to pay the fees to open and close channels, as well as the cost of maintaining any hardware to run a Lightning Node.
However, as channels can be left open indefinitely, they could earn a profit as long as there are sufficient users of the Lightning Network such that their routing fees are in excess of their channel fees and maintenance costs over the long term.
This is trustless as users do not need to loan or send anyone their Bitcoin; they only need to take the risks of operating a Lightning node and storing Bitcoin in a hot wallet.
Third-party services exist that provide interest on Bitcoin, but these services are in general not trustless.
Those wishing to earn a return on their Bitcoin holdings _trustlessly_ can do so by opening channels and routing payments in return for routing fees.
This way, users can earn a return (i.e. "interest") by locking their Bitcoin into channels and offering liquidity to other users wishing to transact on the Lightning Network.
Users doing so will need to pay the fees to open and close channels, as well as the cost of maintaining any hardware and network infrastructure to run a Lightning Node.
However, as channels can be left open indefinitely, they _could_ earn a profit as long as there are sufficient users of the Lightning Network such that their routing fees are in excess of their channel fees and maintenance costs over the long term.
This is trustless as users do not need to loan or send anyone their Bitcoin. Users only need to take on the efforts and risks of operating a Lightning node and storing Bitcoin in a hot wallet.
**Use Cases outside of Finance**
The Lightning Network's principal object is to move payments across a network.
Could it move data other than payments across its network too? It can.
Some projects such as _Whatsat_, _Sphinx Chat_, and _Juggernaut_ are implementing instant messaging chat apps on top of the Ligtning Network.
One can imaging other types of data such as electronic tickets, QR codes, or other forms of tokens flowing across the Lightning Network as well.
The use cases are limited only by our imagination and reach beyond finance.
Lightning network capacity is the value of bitcoin locked and circulated inside Lightning Network and is the sum of capacities of each channel.
It is a mesurement of the maximum value a user can transfer in Lightning Network because routing nodes will need to have sufficient balances. It also reflects the usage of Lightning Network to some extent, because the higher value is circulated inside Lightning Network the more likely that more people are using it.
Lightning network capacity is the total amount of bitcoin locked and circulated inside the Lightning Network.
It is the sum of capacities of each public channel.
It reflects the usage of the Lightning Network to some extent because we expect that people lock bitcoin into Lightning channels in order to spend it or forward other users' payments.
Hence the higher the amount of bitcoin locked in channels, the higher the expected usage of the Lightning Network.
Note that since only public channel capacity can be observed, the true network capacity is unknown.
See private channel.
Noise_XK::
The template of the Noise protocol framework to establish an authenticated and encrypted communication channel between two peers of the Lightning Network.
Andreas M. Antonopoulos
4 years ago
committed by
GitHub