@ -18,7 +18,7 @@ Because blockchains are gossip protocols, each node is required to know and vali
[NOTE]
[NOTE]
====
====
The side effects of increasing the block size or the decreasing the block time with respect to centralization of the network are severe as a few calculations with the numbers show.
The side effects of increasing the block size or decreasing the block time with respect to centralization of the network are severe as a few calculations with the numbers show.
Let us assume the usage of Bitcoin grows so that the network has to process 40,000 transactions per second.
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.
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.
This does not include the traffic overhead of forwarding the transaction information to other peers.
@ -70,7 +70,7 @@ The Lightning Network is a network that operates as a "second layer" protocol on
* Users who exchange value over the Lightning Network do not need to wait for block confirmations for payments.
* Users who exchange value over the Lightning Network do not need to wait for block confirmations for payments.
* 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.
* 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.
* 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. This makes Lightning use less resources, and hence cheaper, as well as more private.
* 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.
@ -36,33 +36,61 @@ If users decide to outsource some functionality to a third party they usually gi
Finally, those seeking simplicity and convenience, even at the expense of control and security, may choose a custodial Lightning wallet. This is the least technically challenging option, but it _undermines the trust model of cryptocurrency_ and should therefore be considered only as a stepping stone towards more control and self-reliance.
Finally, those seeking simplicity and convenience, even at the expense of control and security, may choose a custodial Lightning wallet. This is the least technically challenging option, but it _undermines the trust model of cryptocurrency_ and should therefore be considered only as a stepping stone towards more control and self-reliance.
In <<lnwallet-categories>> we see the three broad categories of lightning wallets and the relative degree of control they offer to the user.
There are many ways wallets can be characterized or categorized.
The most important questions to ask about a specific wallet are:
- Does this Lightning wallet have a full LN Node or does it use a third-party LN Node?
- Does this Lightning wallet have a full Bitcoin Node or does it use a third-party Bitcoin Node? footnote:[If a Lightning wallet uses a third-party Lightning node, it is this third-party Lightning node who decides how to communicate with Bitcoin. Hence, using a third-party Lightning node implies that you as a wallet user also use a third-party Bitcoin node. Only in the other case, when the Lightning wallet uses its own Lightning node, does the choice "full Bitcoin-node" vs. "thrid-party Bitcoin node" exist. ]
- Does this Lightning wallet store its own keys under user control (self-custody) or are the keys held be a third-party custodian?
At the highest level of abstraction, question 1 and 3 are the most elementary ones.
From these two questions we can derive four possible categories.
We can place these four categories into a quadrant as seen in Table <<lnwallet-categories>>.
But remember that this is just one way of categorizing Lightning wallets.
| Full Node & Wallet | Full Node | Non-Custodial | High
| *Self-Custody* | Q1: High technical skill, least trust in 3rd parties, most permissionless | Q2: Below medium technical skills, below medium trust in 3rd parties, requires some permissions
| Non-Custodial Wallet | 3rd-party node | Non-Custodial | Medium
| *Custodial* | Q3: Above medium technical skills, above medium trust in 3rd parties, requires some permissions | Q4: Low technical skills, high trust in 3rd parties, least permissionless
Q3, quadrant 3, where a full LN node is used but the keys are held by a custodian is currently not common.
Future wallets from that quadrant would let a user worry about the operational aspects of their node, but then delegate the access to the keys to a third party which may use primarily cold storage.
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.
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.
The category "Third-party Ligntning Nodes" can again be subdivided into:
- Lightweight: means that the Lightning Node is operated by a third party and that the wallet obtains the required information through an API that connects wallet and third-party LN node.
- None: means that not only is the Lightning Node operated by a third party but most of the wallet is operated by a third party in the cloud such that the wallet does not even need to make calls on a Lightning node API.
These subcategories are used in Table <<lnwallet-examples>>.
Other terms that need explanation in Table <<lnwallet-examples>> in column "Bitcoin Node" are:
- Neutrino: Neutrino is a specific implementation of a protocol to get data from Bitcoin as outlined in BIP 157 and BIP 158. The Bitcoin Node is run by a third-party and accessed via "neutrino".
- Electrum: This means the wallet connects to an Electrum Server. The Bitcoin Node is run by a third-party and accessed via the "Electrum" protocol.
- Bitcoin Core: implementation of Bitcoin full node
- btcd: another implementation of Bitcoin full node
In <<lnwallet-examples>> we see some examples of currently popular Lightning node and wallet applications for different types of devices.
In <<lnwallet-examples>> we see some examples of currently popular Lightning node and wallet applications for different types of devices.
// TODO: Add a lot more wallet/node examples, confirm the details for correctness
// TODO: Add a lot more wallet/node examples, confirm the details for correctness
@ -289,7 +289,7 @@ The output of your channel partner is not encumbered with a time lock and can be
The on-chain fees will be higher than in "the good way" of the mutual close for several reasons:
The on-chain fees will be 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 on-chain fees will be at the future 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 will be at the future 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 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.
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 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.
* 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.
@ -328,7 +328,7 @@ While Lightning Nodes usually use the encrypted communication channels over the
This could be via a Webservice or Email.
This could be via a Webservice or Email.
Invoices are usually encoded either as long bech32 strings or as QR codes which enables them to be easily scanned by smartphones.
Invoices are usually encoded either as long bech32 strings or as QR codes which enables them to be easily scanned by smartphones.
Obviously the invoices contains the amount of bitcoin that is requested and a signature of the payee.
Obviously 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.
The latter is used to extract the address of the payee so that the payer knows whom to send the money.
Besides some other meta data the most important but not quite obvious data in the invoice is a Payment Hash.
Besides some other meta data the most important but not quite obvious data in the invoice is a Payment Hash.
==== Payment Hash
==== Payment Hash
@ -362,7 +362,7 @@ After opening a channel a node will send out an announcement of the channel via
Every peer can validate the information from the `channel_announcement` message and verify that the funding transaction was indeed confirmed by the Bitcoin network.
Every peer can validate the information from the `channel_announcement` message and verify that the funding transaction was indeed confirmed by the Bitcoin network.
Upon verification the node will forward the gossip message to its peers.
Upon verification the node will forward the gossip message to its peers.
In order to avoid spam this will only be done if the message was not forwarded by that node already.
In order to avoid spam this will only be done if the message was not forwarded by that node already.
Similarly nodes can be announced via the gossip protocol with the `node_announcment` message.
Similarly nodes can be announced via the gossip protocol with the `node_announcement` message.
For this message to be forwarded a node has to have at least one public channel that was announced on the gossip protocol.
For this message to be forwarded a node has to have at least one public channel that was announced on the gossip protocol.
This again is a spam reduction measure of the gossip protocol.
This again is a spam reduction measure of the gossip protocol.
Payment channels have various meta data that are useful for other participants of the network.
Payment channels have various meta data that are useful for other participants of the network.
@ -372,7 +372,7 @@ These messages will only be forwarded about four times a day for every channel t
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.
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.
We will investigate the details of the gossip protocol in a later chapter.
We will investigate the details of the gossip protocol in a later chapter.
For now it is only important to know that it exists and that it is used to share topology information of the Lightning Network with its participants.
For now it is only important to know that it exists and that it is used to share topology information of the Lightning Network with its participants.
This topology information is crucually needed for delivering payments through the network of payment channels.
This topology information is crucially needed for delivering payments through the network of payment channels.
[NOTE]
[NOTE]
====
====
@ -452,14 +452,14 @@ Upon receiving a Lightning Message called `update_add_htlc` which contains the `
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.
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.
6. Obviously it also has to collaborate with its peer on the outgoing channel to move foward the state to also include the offered `HTLC`.
6. Obviously it also has to collaborate with its peer on the outgoing channel to move foward the state to also include the offered `HTLC`.
Of course those steps will be interrupted and abroated if an error is detected.
Of course those steps will be interrupted and aborted if an error is detected.
In most of those cases an error message will be send back to the originator of the received `update_add_htlc` message.
In most of those cases an error message will be send back to the originator of the received `update_add_htlc` message.
If for example in the first step the node detects that the onion was corrupted it will not proceed to the second and subsecquent steps to move forward the channel state on the receiving channel to include the HTLC.
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 discoveres that it won't be able to fulfill the routing request or that the not enough fees have been included it will also abort the payment forwarding algorithm and rather send back an error.
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.
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.
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.
The reply onion is then send back on the incoming channel.
The reply onion is then sent back on the incoming channel.
The node on the other side knows on which channel it received an onion and with which other channel it has an HTLC with the same `Payment Hash`.
The node on the other side knows on which channel it received an onion and with which other channel it has an HTLC with the same `Payment Hash`.
Thus the error can safely propagate back towards the originator.
Thus the error can safely propagate back towards the originator.
Nodes that are sending back an error Onion must on their way remove the HTLCs from their payment channels to make sure that they cannot be enforced.
Nodes that are sending back an error Onion must on their way remove the HTLCs from their payment channels to make sure that they cannot be enforced.
@ -468,7 +468,7 @@ Nodes that are sending back an error Onion must on their way remove the HTLCs fr
====
====
It is important to understand that HTLCs have a time measured in absolute blockheight through which they are valid.
It is important to understand that HTLCs have a time measured in absolute blockheight through which they are valid.
Once the sender of a payment sends away the onion it is completely out if their controll what happens.
Once the sender of a payment sends away the onion it is completely out if their controll what happens.
Honest nods SHOULD either forward the onion as quickly as possible or send an error back the original.
Honest nodes SHOULD either forward the onion as quickly as possible or send an error back the original.
While sender expects nodes along the path to be honest it has according to the protocol no power of making sure that nodes act quickly.
While sender expects nodes along the path to be honest it has according to the protocol no power of making sure that nodes act quickly.
Thus payment can currently get stuck if nodes want to behave malicously.
Thus payment can currently get stuck if nodes want to behave malicously.
While the likelihood for a payment to fail is pretty high if it does not settle quickly a node SHOULD never initate 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.
While the likelihood for a payment to fail is pretty high if it does not settle quickly a node SHOULD never initate 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.
Rene Pichardt
4 years ago