Lightning wallets can be installed on a variety of devices, including laptops, servers, and mobile devices. To run a full Lightning node (one that participates in "gossip" and creates its own map of the network for path finding and routing) you will need to use a server or desktop computer, as mobile devices and laptops are usually not powerful enough in terms of capacity, processing, battery life, and connectivity.
@ -55,15 +55,15 @@ In <<lnwallet-examples>> we see some examples of currently popular Lightning nod
| lnd | Server | Full Node | Bitcoin Core/btcd | User Control
| c-lightning | Server | Full Node | Bitcoin Core | User Control
| Eclair Server | Server | Full Node | Bitcoin Core/Electrum | User Control
| Zap Desktop | Desktop | Full Node | Bitcoin Core/btcd | User Control
| Eclair Mobile | Mobile | Lightweight | Electrum | User Control
| Breez Wallet | Mobile | Full Node | Bitcoin Core/btcd | User Control
| Phoenix Wallet | Mobile | Lightweight | Electrum | User Control
| Blue Wallet | Mobile | None | None | Custodial
|===
=== Balancing complexity and control
@ -164,7 +164,7 @@ All of these methods have varying degrees of difficulty, and many will involve p
==== Receiving Bitcoin
Let's assume Alice has found a local Bitcoin ATM and has decided to buy some bitcoin in exchange for cash. An example of a Bitcoin ATM, one built by the Lamassu company, is shown in <<bitcoin-atm>>. A Bitcoin ATM like this one accepts national currency (cash) through a cash slot and send bitcoin to a Bitcoin Address scanned from a user's wallet using a built-in camera.
Let's assume Alice has found a local Bitcoin ATM and has decided to buy some bitcoin in exchange for cash. An example of a Bitcoin ATM, one built by the Lamassu company, is shown in <<bitcoin-atm>>. Such Bitcoin ATMs accepts national currency (cash) through a cash slot and send bitcoin to a Bitcoin Address scanned from a user's wallet using a built-in camera.
[[bitcoin-atm]]
.A Lamassu Bitcoin ATM
@ -219,7 +219,7 @@ Swiping right, Alice accesses the "LIGHTNING CHANNELS" section of Eclair. Here s
Let's review the definition of a "Lightning Network Channel" at this point, to make things a bit clearer. Firstly, the word "channel" is a metaphor for a _financial relationship_ between Alice's Lightning wallet and another Lightning wallet. We call it a channel because it is a means for Alice's wallet and this other wallet to exchange many payments with each other on the Lightning Network (off-chain) without committing transactions to the Bitcoin blockchain (on-chain).
The wallet or _node_ that Alice opens a channel to is called her _channel peer_. Once "opened," a channel can be used to send many payments back and forth between Alice's wallet and her channel peer.
The wallet or _node_ that Alice opens a channel to is called her _channel peer_. Once "opened", a channel can be used to send many payments back and forth between Alice's wallet and her channel peer.
Furthermore, Alice's channel peer can _forward_ payments via other channels further into the Lightning Network. This way, Alice can _route_ a payment to any wallet (e.g. Bob's Lightning wallet) as long as Alice's wallet can find a _path_ made by hopping from channel to channel, all the way to Bob's wallet.
Alice presses "PAY," and a second later, Bob's tablet shows a successful payment. Alice has completed her first Lightning Network payment! It was fast, inexpensive, and easy. Now she can enjoy her latte which was purchased using the most advanced payment technology in the world. And from now on, whenever Alice feels like drinking a coffee at Bob's Cafe she selects an item on Bob's tablet screen, scans the QR code with her cell phone, clicks pay and is served a coffee, all within seconds and all without "on-chain" transaction.
=== Conclusion
In this chapter, we followed Alice as she downloaded and installed her first Lightning wallet, acquired and transferred some bitcoin, opened her first LN channel, and bought a cup of coffee by making her first payment on the Lightning Network. In the following chapters, we will look "under the covers" at how each component in the Lightning Network works, and how Alice's payment reached Bob's Cafe.
@ -170,7 +170,7 @@ This can actually be easily achieved with the following construction:
With this protocol Alice did not give up ownership of her 10 mBTC even though the funds have been sent to a 2-2 multisignature wallet for which Alice controls only one key.
If Bob stops responding to Alice she will be able to broadcast her commitment transaction and receive her funds back.
She will only have lost the fees for the two onchain transactions.
She will only have lost the fees for the two on-chain transactions.
As long as she follows the protocol and has her node secured this is her only risk when opening a channel.
The commitment transactions will not only serve the purpose of allowing Alice to withdraw her funds directly after opening the channel in case Bob does not answer.
@ -245,7 +245,7 @@ There are 3 ways to close a payment channel:
Not all ways could be chosen for each of the above mentioned reasons.
For example if your channel partner is offline you will not be able to engage in the good way to do a mutual close.
The good news for you is that you Lightning Network software will most likely automatically select the best closing mechanism that can currently be used if you ask the software to close the channel or if the software discovers an issue with your channel partner and follows the protocol specification which in most of such cases state that the channel shall be closed.
The good news for you is that your Lightning Network software will most likely automatically select the best closing mechanism that can currently be used if you ask the software to close the channel or if the software discovers an issue with your channel partner and follows the protocol specification which in most of such cases state that the channel shall be closed.
===== Examining the god way - mutual close
The preferred and good way to close a channel is the mutual close.
@ -256,9 +256,9 @@ Once no further routing attempts are pending, the closing transaction is prepare
This transaction is similar to the commitment transaction.
It has the same balance as the commitment transaction but no outputs are encumbered with a time lock.
As the finish up of the routing attempts could take some time, a mutual close can also take some time.
The onchain transaction fees of the shutdown transaction for closing the channel in a mutual way are being paid by the party who opened the channel and not as many people think by the person who initiated the closing procedure.
The on-chain transaction fees of the shutdown transaction for closing the channel in a mutual way are being paid by the party who opened the channel and not as many people think by the person who initiated the closing procedure.
As both nodes sign the shutdown 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 the bad way.
Even though there is a potential waiting time, this type of channel close is usually faster than the bad way.
===== Examining the bad way - force close
In case your node cannot engage in a mutual close (most likely because your channel partner is either offline or not responding) you will have to do a force close.
@ -268,10 +268,10 @@ Thus after that transaction was mined you will have to wait for the timelock of
The output of your channel partner is not encumbered with a time lock and can be spent directly.
The on-chain fees will be much higher than in the good way of the mutual close for several reasons:
* The most obvious reason is that when the commitment transaction was negotiated you and your channel partner didn't know how high the onchain fees might be at the time the force close is taking place.
* 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 might be at the time the force close is taking place.
As the fees cannot be changed without reasigning outputs of the commitment transaction which needs two signatures and as the force close usually should happen in an urgent situation the protocol developers decided to be very generous with the fee rate for the commitment transactions. It can be up to 5 times higher than the fee estimators would 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 more space and will also hit the chain.
* In particular those routing attempts will have to be resolved onchain by additional spends. These additional spends don't have to overestimate the fees but it still adds to the bill.
* In particular those routing attempts will have to be resolved on-chain by additional spends. These additional spends don't have to overestimate the fees but it still adds to the bill.
In general you should not do a force close unless it is absolutely necessary.
Your funds will be locked for a longer time and the person who opened the channel will have to pay higher fees. Also you might have to pay on-chain fees to abort or settle routing attempts - even if you haven't opened the channel.
@ -279,7 +279,7 @@ Your funds will be locked for a longer time and the person who opened the channe
===== Examining the ugly way - protocol breach
In case your channel partner tries to cheat you - weather deliberate or not - by publishing an outdated commitment transaction, you will be able to use the timelock to catch this cheating attempt and collect on the outputs by using the revocation secret you had previously received to negotiate a newer state of the channel.
This close can actually go in two ways.
First if you catch your partner in time you will claim their funds. In that case the closing will be rather fast. Also you will have to pay the onchain fees which could be really high if there is a lot of demand for transactions at that time.
First if you catch your partner in time you will claim their funds. In that case the closing will be rather fast. Also you will have to pay the on-chain fees which could be really high if there is a lot of demand for transactions at that time.
This should not bother you as you just gained the entire channel capacity.
Second if you did not catch the cheating attempt then your channel partner will be able to collect their outputs after the time lock expired.
In that 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.
@ -314,7 +314,7 @@ In case a user has several invoices to pay, the user can read the description an
As payment channels do not need to be publicly announced, the payee can also provide some private channels as routing hints to the invoice.
These hints can also be used for public channels to point to 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 also include a fallback address.
We would however always recommend to open a new payment channel instead of doing an onchain transaction that does not add an additional payment channel.
We would however always recommend to open a new payment channel instead of doing an on-chain transaction that does not add an additional payment channel.
Invoices also have an expiry time so that the payee can delete the preimage after some time to free up space.
=== Delivering the payment
@ -390,7 +390,7 @@ The routing scheme is called the SPHINX mixformat and will be explained in detai
For now we want to focus on its properties for the transport of payments which we also call onions.
1. The most important property is that a routing node can only see on which channels 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 for whom the payment is supposed to be. The exception of course would be if the node is the recipient. In that case it would know that it was the final destination.
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 for intruding the privacy of the payments almost impossible
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 for intruding the privacy of the payments almost impossible.
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.
4. Onions can have up to 20 hops included allowing 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 the other onions that have been stored.
@ -409,7 +409,7 @@ The `Payment Hash` is rather included in the Lightning Message that also transpo
=== Missing bits
From a computer science perspective the Lightning Network protocol is mainly a peer to peer protocol between its participants.
All communication between participants is sent via so called Lightning Messages.
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.
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.
The Lightning messages are sent in an encrypted way after a peer connection has been established.
Establishing the peer connection follows a cryptographic handshake following the Noise Protocol Framework.
The Noise Protocol Framework is a collection of templates for cryptographic handshakes and is also used by WhatsApp and Wireguard.
@ -421,7 +421,7 @@ This makes development a little bit tricky as one cannot easily monitor one's ow
* different scope of the network
** global path finding (entire knowledge of the network necessary)
** multihop routing (onion necessary only a subset of nodes involved)
** locally setting up and settling htlcs (only peers involved)
** locally setting up and settling HTLCs (only peers involved)
=== Thoughts about Trust
As long as a person follows the protocol and has their node secured, there is no principle risk of losing funds when participating in the Lightning Network.
@ -439,7 +439,7 @@ While the Lightning Network is built on top of Bitcoin, and inherits many of it'
In order to make a payment on the Bitcoin network, a sender needs to consume one or more Unspent Transaction Outputs (UTXOs).
If a user has multiple UTXOs, they need to select which one to send.
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 a single output with value 2 BTC.
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.
On Lightning, payments do not require inputs to be consumed but rather for the channel balance to be updated.
This is done by finding a path of channels with sufficient capacity from the sender to the receiver.
@ -449,7 +449,7 @@ As many paths may exist, the choice of path to the Lightning Network payer is so
In order to make a payment on the Bitcoin network, a sender needs to consume one or more Unspent Transaction Outputs (UTXOs).
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.
This 0.2 BTC creates a new UTXO called a 'change output'
This 0.2 BTC creates a new UTXO called a 'change output'.
On Lightning, the UTXO is consumed during the Funding Transaction, which leads to the creation of a channel.
Once the bitcoin is locked within that channel, portions of it can be sent back and forth within the channel, without the need to create any change.
Roman
4 years ago
committed by
GitHub