The Lightning Network is a protocol for using Bitcoin in a smart and non-obvious way.
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, LN 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 LN provides including improved privacy, speed, and scale. With core knowledge of LN, 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 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.
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 LN. Let's get started with why the Lightning Network was proposed in the first place.
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
@ -66,7 +66,7 @@ Throughout this book you will see "Bitcoin" with the first letter capitalized, w
The Lightning Network is a network that operates as a "second layer" protocol on top of Bitcoin and other blockchains. The Lightning Network enables fast, secure, private, trustless, and permissionless payments. Here are some of the features of the Lightning Network:
* Users of the Lightning Network can route payments to each other for very low cost and in real time.
* Users of the Lightning Network can route payments to each other for low cost and in real time.
* 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.
* 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.
@ -85,7 +85,7 @@ consumer::
Alice is a Bitcoin user who wants to make fast, secure, cheap, and private payments for small retail purchases. She buys coffee with bitcoin, using the Lightning Network.
merchant::
Bob owns a coffee shop, "Bob's Cafe". "On-chain" bitcoin payments don't scale for small amounts like a cup of coffee, so he uses the Lightning Network to accept bitcoin payments almost instantaneously and for very low fees.
Bob owns a coffee shop, "Bob's Cafe". "On-chain" bitcoin payments don't scale for small amounts like a cup of coffee, so he uses the Lightning Network to accept bitcoin payments almost instantaneously and for low fees.
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.
@ -97,11 +97,11 @@ 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.
migrant::
Farel is an immigrant who works in the Middle East and sends money home to his family in Indonesia. Remittance companies and banks charge very high fees, and Farel prefers to send smaller amounts more often. Using the Lightning Network, Farel can send bitcoin as often as he wants, with negligible fees.
Farel is an immigrant who works in the Middle East and sends money home to his family in Indonesia. Remittance companies and banks charge high fees, and Farel prefers to send smaller amounts more often. Using the Lightning Network, Farel can send bitcoin as often as he wants, with negligible fees.
software service business::
Wei is an entrepreneur who sells information services related to the Lightning Network, as well as Bitcoin and other cryptocurrencies. Wei is monetizing his API endpoints by implementing micro-payments over the Lightning Network. Additionally, Wei has implemented a liquidity provider service that rents inbound channel capacity on the Lightning Network, charging a small bitcoin fee for each rental period.
=== Chapter Summary
In this chapter we looked at the history of the Lightning Network and the motivations behind second layer scaling solutions for Bitcoin and other blockchain based networks. We learned basic terminology including node, payment channel, on-chain transactions, and off-chain payments. Finally, we met Alice, Bob, Saanvi, John, Gloria, Farel, and Wei who we'll be following throughout the rest of the book. In the next chapter we'll meet Alice and walk through her thought process as she selects a Lightning wallet and prepares to make her first LN payment to buy a cup of coffee from Bob's Cafe.
In this chapter we looked at the history of the Lightning Network and the motivations behind second layer scaling solutions for Bitcoin and other blockchain based networks. We learned basic terminology including node, payment channel, on-chain transactions, and off-chain payments. Finally, we met Alice, Bob, Saanvi, John, Gloria, Farel, and Wei who we'll be following throughout the rest of the book. In the next chapter we'll meet Alice and walk through her thought process as she selects a Lightning wallet and prepares to make her first Lightning payment to buy a cup of coffee from Bob's Cafe.
@ -39,7 +39,7 @@ Finally, those seeking simplicity and convenience, even at the expense of contro
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 Lightning Node or does it use a third-party Lightning 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?
@ -52,19 +52,19 @@ But remember that this is just one way of categorizing Lightning wallets.
| *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
| *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.
Q3, quadrant 3, where a full Lightning 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.
The category "Third-party Lightning 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.
- 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 Lightning 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>>.
@ -80,10 +80,10 @@ In <<lnwallet-examples>> we see some examples of currently popular Lightning nod
// TODO: Add a lot more wallet/node examples, confirm the details for correctness
| lnd | Server | Full Node | Bitcoin Core/btcd | Self-Custody
| c-lightning | Server | Full Node | Bitcoin Core | Self-Custody
| Eclair Server | Server | Full Node | Bitcoin Core/Electrum | Self-Custody
@ -100,15 +100,15 @@ Lightning wallets have to strike a careful balance between complexity and user c
When selecting a wallet, keep in mind that even if you don't see these trade-offs, they still exist. For example, many wallets will attempt to remove the burden of channel management from its users. To do so, they introduce central "hub" nodes that all their wallets connect to automatically. While this trade-off simplifies the user interface and user experience, it introduces a Single Point of Failure (SPoF) as these "hub nodes" become indispensable for the wallet operation. Furthermore, relying on a "hub" like this can reduce user privacy since the hub knows the sender and potentially (if constructing the payment route on behalf of the user) also the recipient of each payment made by the user's wallet.
In the next section, we will return to our first user and walk through her first Lightning wallet setup. She has chosen a wallet that is more sophisticated than the easier custodial wallets. This allows us to show some of the underlying complexity and introduce some of the inner workings of an advanced wallet during our example. You may find that your first ideal wallet is further towards "ease of use", by accepting some of the control and privacy trade-offs. Or perhaps you are more of a "power user" and want to run your own LN and Bitcoin nodes as part of your wallet solution.
In the next section, we will return to our first user and walk through her first Lightning wallet setup. She has chosen a wallet that is more sophisticated than the easier custodial wallets. This allows us to show some of the underlying complexity and introduce some of the inner workings of an advanced wallet during our example. You may find that your first ideal wallet is further towards "ease of use", by accepting some of the control and privacy trade-offs. Or perhaps you are more of a "power user" and want to run your own Lightning and Bitcoin nodes as part of your wallet solution.
=== Alice's First LN Wallet
=== Alice's First Lightning Wallet
Alice is a long time Bitcoin user. We first met Alice in Chapter 1 of _"Mastering Bitcoin"_ footnote:["Mastering Bitcoin 2nd Edition, Chapter 1" Andreas M. Antonopoulos (https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch01.asciidoc).], when she bought a cup of coffee from Bob's cafe using a bitcoin transaction. Now, Alice is eager to learn about and experiment with the Lightning Network. First, she has to select a Lightning wallet that meets her needs.
Alice does not want to entrust custody of her bitcoin to third parties. She has learned enough about cryptocurrency to know how to use a wallet. She also wants a mobile wallet so that she can use it for small payments on-the-go, so she chooses the _Eclair_ wallet, a popular non-custodial mobile Lightning wallet.
==== Downloading and Installing a LN Wallet
==== Downloading and Installing a Lightning Wallet
When looking for a new cryptocurrency wallet, you must be very careful to select a secure source for the software.
@ -120,7 +120,7 @@ Alice uses an Android device and will use the Google Play Store to download and
.Eclair Mobile in the Google Play Store
image:images/eclair-playstore.png["Eclair wallet in the Google Play Store"]
Alice notices a few different elements on this page, that help her ascertain that this is, most likely, the correct "Eclair Mobile" wallet she is looking for. Firstly, the organization "ACINQ" footnote:[ACINQ: Developers of the Eclair Mobile Lightning wallet (https://acinq.co/).] is listed as the developer of this mobile wallet, which Alice knows from her research is the correct developer. Secondly, the wallet has been installed "10,000+" times and has more than 320 positive reviews. It is unlikely this is a rogue app that has snuck into the Play Store. As third step, she goes to the ACINQ website (https://acinq.co/). There she goes to the Download section or looks for the link to the Google App store. She finds the link and clicks it. She compares that this link brings her to the very same app in the Google App Store. Satisfied by these findings, Alice installs the Eclair app on her mobile device.
Alice notices a few different elements on this page, that help her ascertain that this is, most likely, the correct "Eclair Mobile" wallet she is looking for. Firstly, the organization "ACINQ" footnote:[ACINQ: Developers of the Eclair Mobile Lightning wallet (https://acinq.co/).] is listed as the developer of this mobile wallet, which Alice knows from her research is the correct developer. Secondly, the wallet has been installed "10,000+" times and has more than 320 positive reviews. It is unlikely this is a rogue app that has snuck into the Play Store. As third step, she goes to the ACINQ website (https://acinq.co/). She verifies that the webpage is secure (https, not http) which is shown as a green lock by some browsers. On the website she goes to the Download section or looks for the link to the Google App store. She finds the link and clicks it. She compares that this link brings her to the very same app in the Google App Store. Satisfied by these findings, Alice installs the Eclair app on her mobile device.
Alice selects the "Cafe Latte" option from the screen and is presented with a _Lightning Invoice_ as shown in <<bob-cafe-invoice>>
[[bob-cafe-invoice]]
.LN Invoice for Alice's latte
.Lightning Invoice for Alice's latte
image:images/bob-cafe-invoice.png[]
To pay the invoice, Alice opens her Eclair wallet and selects the "Send" button (which looks like a right-facing arrow) under the "TRANSACTION HISTORY" tab, as shown in <<alice-send-start>>.
@ -57,7 +57,7 @@ Besides all the technical primitives, the Lightning Network protocol is a creati
=== Payment channels
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 LN participant.
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.
From a computer science perspective a payment channel is a cryptographic communication protocol between you and your channel partner.
It allows both of the channel partners to send funds back and forth as often as they wish.
A channel is only limited by two things:
@ -489,10 +489,10 @@ This makes the Payment Hash obtainable without the need to decrypt any onion.
==== Payment Forwarding Algorithm
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.
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.
Forwarding nodes can only reject a path.
This can happen either on purpose or because they are not able to fulfill the request.
The payment forwarding algorithm is initiated by the sender of an payment who selects a path throught the lightning network and constructs an onion.
The payment forwarding algorithm is initiated by the sender of an payment who selects a path through the Lightning Network and constructs an onion.
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.
@ -524,10 +524,11 @@ It is important to understand that HTLCs have a time measured in absolute blockh
Once the sender of a payment sends away the onion it is completely out if their control what happens.
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.
Thus payment can currently get stuck if nodes want to behave malicously.
Thus payments can currently get stuck if nodes want to behave maliciously.
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 malicously 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.
====
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.
=== Missing bits
@ -680,6 +681,16 @@ 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.
==== Incentives for Large Transaction Value vs. Incentives for Small Transaction Values
The fee structure in Bitcoin is independent of the transaction value.
A $1 million transaction has the same fee as a $1 transaction on Bitcoin.
In Lightning the fee is a fixed base fee plus a percentage of the transaction value.
Hence, in Lightning the payment fee increases with payment value.
These opposing fee structures create different incentives and lead to different usage in regards to transaction value.
A transaction of enough value will be cheaper on Bitcoin and hence users will prefer Bitcoin for large value transactions.
Similarly, on the other end of the spectrum, users will prefer Lightning for small value transactions.
==== Using the Blockchain as a Ledger vs Using the Blockchain as a Court System
On the Bitcoin Network, every transaction is eventually recorded in a block on the blockchain.
@ -723,6 +734,8 @@ When settled on-chain, it must be settled in "satoshis".
Both the Bitcoin network and the Lightning network use the same monetary units: bitcoins.
Lightning payments use the very same bitcoins as Bitcoin transactions.
As an implication, because the monetary unit is the same, also the economic monetary limit is the same: 21 million bitcoins.
From these 21 million bitcoins, some are locked in 2-out-of-2 multisig addresses so that they can enable a payment channel on the Lightning Network.
@ -26,7 +26,7 @@ Some additional definitions, to be cleaned up and moved into alphabetic order ar
** Funding Transaction: a transaction that locks bitcoin into a smart contract to open a channel.
** Settlement Transaction: a transaction that closes a channel, and allocates the locked bitcoin to the channel owners according to the final balance of the channel.
** Penalty Transaction: if one user tries to "cheat" by claiming a prior state of the channel, the other user can publish a penalty transaction to the Bitcoin blockchain, which allocates all bitcoin in that channel to them.
* Wallet: an application that manages private keys in order to send and receive bitcoin. Lightning Wallets have additional features over and above Bitcoin Wallets in that they can open and close channels, and send and receive lightning payments.
* Wallet: an application that manages private keys in order to send and receive bitcoin. Lightning Wallets have additional features over and above Bitcoin Wallets in that they can open and close channels, and send and receive Lightning payments.
////
@ -52,16 +52,16 @@ Balance::
If the channel balance is completely on one side of the channel, i.e. one channel partner has all of the bitcoin in the channel, this particular partner cannot receive any payments through this channel. This partner can, however, send payments and forward HTLCs.
The balance that a node has on its own side of the channel (and is thus able to spend) is called the outbound capacity.
The node's channel partner would refer to that balance as its inbound capacity, i.e. the amount that it is able to receive.
Nodes should aim to have balanced channels with similar inbound and outbound capicities.
Nodes should aim to have balanced channels with similar inbound and outbound capacities.
bech32::
A checksummed base32 address format. It is native to segregated (BIP173). Also referred to as "bc1" because of the starting values of each address. Transactions made using bech32 are smaller in most cases, and therefore, may only require a lower fee.
A checksummed base32 address format, at most 90 characters long, and capable of error correction. It is native to segregated witness (BIP173). Also referred to as "bc1" because of the current starting values of each address. Transactions made using bech32 are smaller in most cases, and therefore, may only require a lower fee.
bip::
Bitcoin Improvement Proposals. A set of proposals that members of the Bitcoin community have submitted to improve Bitcoin. For example, BIP-21 is a proposal to improve the Bitcoin uniform resource identifier (URI) scheme.
bip, BIP::
Bitcoin Improvement Proposals. A set of proposals that members of the Bitcoin community have submitted to improve Bitcoin. For example, BIP-21 is a proposal to improve the Bitcoin uniform resource identifier (URI) scheme. BIPs can be found at https://github.com/bitcoin/bips.
Bitcoin::
Depending on context, could refer to the name of the currency unit (the coin), the network or the underlying enabling protocol. Written as bitcoin with a "b" in lowercase usually refers to the currency unit.
bitcoin, Bitcoin::
Depending on context, could refer to the name of the currency unit (the coin), the network or the underlying enabling protocol. Written as bitcoin with a lowercase "b" usually refers to the currency unit. Bitcoin with an uppercase "B" usually refers to the protocol. See https://www.bitcoin.org for general information. The source code can be found at https://github.com/bitcoin/bitcoin.
Bitcoin Mining::
Bitcoin mining serves two purposes.
@ -79,7 +79,7 @@ Blockchain::
New blocks have a statistical probability of being produced every ten minutes.
BOLT::
BOLT, or Basics Of Lightning Technology, is the formal specification of the Lightning Network Protocol. It serves only as such without delving into implementation, unlike Bitcoin, in which both are one and the same. It is available in its entirety on the lightning network's github page, in the lightning-rfc repository.
BOLT, or Basics Of Lightning Technology, is the formal specification of the Lightning Network Protocol. It serves only as such without delving into implementation, unlike Bitcoin, in which both are one and the same. It is available in https://github.com/lightningnetwork/lightning-rfc.
Breach Remedy Transaction::
A transaction claiming the outputs of a Revocable Sequence Maturity Contract with the help of the revocation key.
@ -95,7 +95,7 @@ Capacity::
It is not to be confused with the balance.
c-lightning::
Implementation of the Lightning Network Protocol by the Victoria based company Blockstream. It is written in C.
Implementation of the Lightning Network Protocol by the Victoria based company https://blockstream.com[Blockstream]. It is written in C. Source code is at https://github.com/ElementsProject/lightning.
Closing Transaction::
If both channel partners agree to close a channel they will create an exercise settlement transaction that reflects the most recent commitment transaction.
@ -142,7 +142,7 @@ Contract::
Diffie Hellman Key Exchange::
On the Lightning Network, the Elliptic Curve Diffie-Hellman method is used.
It is an anonymous key agreement protocol that allows two parties, each having an elliptic-curve public–private key pair, to establish a shared secret over an insecure communication channel.
It is an anonymous key agreement protocol that allows two parties, each having an elliptic-curve public-private key pair, to establish a shared secret over an insecure communication channel.
This shared secret may be directly used as a key, or to derive another key.
The key, or the derived key, can then be used to encrypt subsequent communications using a symmetric-key cipher.
An example of the derived key would be the shared secrete between the ephemeral session key of a sender of an onion with the nodes public key of a hop of the onion as described and used by the SPHINX Mix Format.
@ -166,7 +166,7 @@ ECDSA::
Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
Eclair::
Implementation of the Lightning Network Protocol by the Paris based company ACINQ. It is written in Scala.
Implementation of the Lightning Network Protocol by the Paris based company https://acinq.co[ACINQ]. It is written in Scala. Source code is at https://github.com/ACINQ/eclair.
encoding::
Encoding is the process of converting a message into a different form.
@ -183,8 +183,8 @@ Ephemeral Key::
fees::
The sender of a transaction often includes a fee to the network for processing the requested transaction.
Not to be confused with a routing fee for payments on the lightning network.
Nodes on the Lightning network are allowed to take a routing fee for forwarding payments.
Not to be confused with a routing fee for payments on the Lightning Network.
Nodes on the Lightning Network are allowed to take a routing fee for forwarding payments.
The routing fee is the sum of a fixed _base_fee_ and a _fee_rate_ which depends on the payment amount.
Funding Transaction::
@ -208,9 +208,9 @@ Gossip Protocol::
Usually Lightning nodes connect with their channel partners, but it is fine to connect with any other Lightning node in order to process gossip messages.
hardware wallet::
A hardware wallet is a special type of Bitcoin wallet, which stores the user's private keys in a secure hardware device.
Currently, hardware wallets are not available for lightning network nodes as user nodes need to be online to follow through the protocol.
Several groups are working on solutions.
A hardware wallet is a special type of Bitcoin wallet which stores the user's private keys in a secure hardware device.
Currently, hardware wallets are not available for Lightning Network nodes as they need to be online to participate in the protocol.
Several groups are currently working on solutions.
hash::
A digital fingerprint of some binary input.
@ -241,19 +241,20 @@ Invoice::
Invoices can also include a fallback Bitcoin address to which the payment can be made in case no route can be found, as well as hints for routing a payment through a private channel.
Lightning Message::
A Lightning message is an encrypted data string that can be sent between two peers on the Lightning Network. Similar to other communication protocols lightning messages consist of a header and a body. The header and the body have their own HMAC. This ensures that the headers of fixed length will also be encrypted and adversaries won't be able to figure out what messages are being sent by inspecting the length.
A Lightning message is an encrypted data string that can be sent between two peers on the Lightning Network. Similar to other communication protocols Lightning messages consist of a header and a body. The header and the body have their own HMAC. This ensures that the headers of fixed length will also be encrypted and adversaries won't be able to figure out what messages are being sent by inspecting the length.
The Lightning Network is a protocol on top of Bitcoin (or other cryptocurrencies).
It creates a network of payment channels which enables the trustless forwarding of payments through the network with the help of HTLCs and Onion Routing.
Other components of the lightning network are the gossip protocol, the transport layer, and payment requests.
Other components of the Lightning Network are the gossip protocol, the transport layer, and payment requests.
The source code is availble at https://github.com/lightningnetwork.
Lightning Network Node::
Lightning Network Node, Lightning Node, node::
TBD.
lnd::
Implementation of the Lightning Network Protocol by the San Francisco based company Lightning Labs.
It is written in Go.
Implementation of the Lightning Network Protocol by the San Francisco based company https://lightning.engineering[Lightning Labs].
It is written in Go. Source code is at https://github.com/lightningnetwork/lnd.
Localfeatures::
Localfeatures of a Lightning Network node are the configurable features of direct interest of the peer.
@ -263,8 +264,7 @@ Locktime::
Locktime, or more technically nLockTime, is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the blockchain.
Millisatoshi::
The smallest unit of account on the lightning network.
The value cannot be enforced on chain.
The smallest unit of account on the Lightning Network. A millisatoshi is one hundred billionth of a single bitcoin. A millisatoshi is one thousandth of one Satoshi. Millisatoshis do not exist, nor can they be settled on the Bitcoin network.
multisignature::
Multisignature (multisig) refers to requiring more than one key to authorize a Bitcoin transaction.
@ -274,8 +274,11 @@ multisignature::
Neutrino::
Neutrino is a later alternative to SPV that also verifies whether certain transactions are contained in a block without downloading the entire block. However, it offers a number of improvements over SPV: Neutrino does not transmit any information that would allow a third party to determine users’ identities, it facilitates the use of non-custodial apps, and it reduces the computational load on full nodes. The trade-off for these improvements is that Neutrino requires more data from the full node than SPV.
Node::
See Lightning Network Node
Noise_XK::
The template of the Noise protocol framework to establish an authenticated and encrypted communication channel between two peers of the lightning network.
The template of the Noise protocol framework to establish an authenticated and encrypted communication channel between two peers of the Lightning Network.
X means that no public key needs to be known from the initiator of the connection.
K means that the public key of the receiver needs to be known.
More particular (from: http://www.noiseprotocol.org/noise.html) the protocol enables.
@ -453,7 +456,7 @@ Transaction Malleability::
Transaction Malleability is a property that hash of a transaction can change without changing the semantic of the transaction (the UTXOs it is spending, the destinations and the corresponding amounts).
For example, altering the signature can change the hash of a transaction, because of the non-deterministism of ECDSA signing.
A Commitment Transaction needs the hash of a Funding Transaction, if the hash of the Funding Transaction changes, transactions depending on it will become invalid. This will make users unable to claim the refunds if there is.
Segregated Witness soft fork addresses this issue and therefore is an important upgrade to support Lightning network.
Segregated Witness soft fork addresses this issue and therefore is an important upgrade to support Lightning Network.
Transport Layer::
In computer networking, the transport layer is a conceptual division of methods of a model of how computers talk to each other.
Andreas M. Antonopoulos
4 years ago