Merge branch 'master' into develop

01_introduction.asciidoc

@@ -10,7 +10,7 @@ Today, in 2021, the Lightning Network is still in its infancy. The Lightning Net
 The concept of the Lightning Network was proposed in 2015, and the first implementation was launched in 2018. As of 2021, we're only beginning to see the opportunities the Lightning Network provides to Bitcoin, including improved privacy, speed, and scale.
 With core knowledge of the Lightning Network, you can help shape the future of the network while also building opportunities for yourself.
 
-We assume you already have some basic knowledge about Bitcoin, but if not, don't worry—we will explain the most important Bitcoin concepts, those you must know to understand the Lightning Network, in <<bitcoin_fundamentals_review>>. If you want to learn more about Bitcoin, you can read _Mastering Bitcoin_, 2nd edition, by Andreas M. Antonopoulos (O'Reilly), available https://bitcoinbook.info/[for free online].
+We assume you already have some basic knowledge about Bitcoin, but if not, don't worry—we will explain the most important Bitcoin concepts, those you must know to understand the Lightning Network, in <<bitcoin_fundamentals_review>>. If you want to learn more about Bitcoin, you can read _Mastering Bitcoin_, 2nd edition, by Andreas M. Antonopoulos (O'Reilly), available https://github.com/bitcoinbook/bitcoinbook[for free online].
 
 While the bulk of this book is written for programmers, the first few chapters are written to be approachable by anyone regardless of technical experience. In this chapter, we'll start with some terminology, then move to look at trust and its application in these systems, and finally we'll discuss the history and future of the Lightning Network. Let's get started.
 

05_node_operations.asciidoc

@@ -747,7 +747,7 @@ As a Lightning node operator, one of the recurring tasks you will need to perfor
 
 As soon as you get your Lightning node up and running, you can fund its Bitcoin wallet and then start opening channels with those funds.
 
-You must choose channel partners carefully because your node's ability to send payments depends on who your channel partners are and how well connected they are to the rest of the Lightning Network. You also want to have more than one channel to avoid being susceptible to a single point of failure. Since Lightning now supports multipath payments, you can split your initial funds into several channels and route bigger payments by combining their capacity. At the same time, avoid making your channels too small. Since you need to pay Bitcoin transaction fees to open and close a channel, the channel balance should not be so small that the on-chain fees consume a significant portion. It's all about balance!
+You must choose channel partners carefully because your node's ability to send payments depends on who your channel partners are and how well connected they are to the rest of the Lightning Network. You also want to have more than one channel to avoid being susceptible to a single point of failure. Since Lightning now supports multipart payments, you can split your initial funds into several channels and route bigger payments by combining their capacity. At the same time, avoid making your channels too small. Since you need to pay Bitcoin transaction fees to open and close a channel, the channel balance should not be so small that the on-chain fees consume a significant portion. It's all about balance!
 
 To summarize:
 
@@ -800,7 +800,7 @@ The autopilot will make channel recommendations whenever the conditions are met
 According to the preceding configuration file, the channels will be between 5 mBTC (minchansize = 500,000 satoshi) and 50 mBTC (maxchansize = 5,000,000 satoshi) in size.
 As is common, the amounts in the configuration file are enumerated in satoshi.
 Currently, channels below 1 mBTC are not very useful, and we do not recommend you open channels that are too small and below this amount.
-With the wider adoption of multipath payments, smaller channels are less of a burden. But for the time being, this is our recommendation.
+With the wider adoption of multipart payments, smaller channels are less of a burden. But for the time being, this is our recommendation.
 
 The +c-lightning+ plug-in, which was originally written by René Pickhardt (a coauthor of this book), works very differently in comparison with the +lnd+ autopilot.
 First, it differs in the algorithms used to make the recommendations. We will not cover this here. Secondly, it differs in its user interface.

11_gossip_channel_graph.asciidoc

@@ -215,7 +215,7 @@ Querying the current DNS +A+ record for a given node can also be used to look up
 At this point in our journey, our new Lightning node has found its first
 peer and established its first connection! Now we can begin the second phase of new peer bootstrapping: channel graph synchronization and validation.
 
-First, we'll explore more of the intricacies of BOLT 10 itself to take a deeper look into how things work under the hood.
+First, we'll explore more of the intricacies of BOLT #10 itself to take a deeper look into how things work under the hood.
 
 ==== SRV Query Options
 

12_path_finding.asciidoc

@@ -7,7 +7,7 @@ In this chapter we will examine the problem of path finding, understand how unce
 
 === Path Finding in the Lightning Protocol Suite
 
-Path finding, path selection, multipath payments (MPP), and the payment attempt trial and error loop occupy the majority of the "Payment Layer" at the top of the protocol suite.
+Path finding, path selection, multipart payments (MPP), and the payment attempt trial and error loop occupy the majority of the "Payment Layer" at the top of the protocol suite.
 
 These components are highlighted by a double outline in the protocol suite, shown in <<LN_protocol_pathfinding_highlight>>.
 
@@ -147,7 +147,7 @@ We can group these steps into three primary activities:
 * Path finding (filtered and ordered by some heuristics)
 * Payment attempt(s)
 
-These three activities can be repeated in a _payment round_ if we use the failure returns to update the graph, or if we are doing multipath payments (see <<mpp>>).
+These three activities can be repeated in a _payment round_ if we use the failure returns to update the graph, or if we are doing multipart payments (see <<mpp>>).
 
 In the next sections we will look at each of these steps in more detail, as well as more advanced payment strategies.
 
@@ -233,7 +233,7 @@ To quantify the uncertainty of a channel's liquidity, we can apply probability t
 
 * The more channels (hops), the lower the chance of success.
 
-While these may be obvious, they have important implications, especially for the use of multipath payments (see <<mpp>>). The math is not difficult to follow.
+While these may be obvious, they have important implications, especially for the use of multipart payments (see <<mpp>>). The math is not difficult to follow.
 
 Let's use probability theory to see how we arrived at these conclusions.
 
@@ -350,15 +350,15 @@ However, this knowledge becomes somewhat "stale" as the other nodes send or rout
 Therefore, Selena's node must consider how long to keep this knowledge before assuming that it is stale and no longer useful.
 
 [[mpp]]
-=== Multipath Payments (MPP)
+=== Multipart Payments (MPP)
 
-_Multipath payments (MPP)_ are a feature that was introduced in the Lightning Network in 2020 and is already very widely available. Multipath payments allow a payment to be split into multiple _parts_ which are sent as HTLCs over several different paths to the intended recipient, preserving the _atomicity_ of the overall payment. In this context, atomicity means that either all the HTLC parts of a payment are eventually fulfilled or the  entire payment fails and all the HTLC parts fail. There is no possibility of a partially successful payment.
+_Multipart payments (MPP)_ are a feature that was introduced in the Lightning Network in 2020 and is already very widely available. Multipart payments allow a payment to be split into multiple _parts_ which are sent as HTLCs over several different paths to the intended recipient, preserving the _atomicity_ of the overall payment. In this context, atomicity means that either all the HTLC parts of a payment are eventually fulfilled or the  entire payment fails and all the HTLC parts fail. There is no possibility of a partially successful payment.
 
-Multipath payments are a significant improvement in the Lightning Network because they make it possible to send amounts that won't "fit" in any single channel by splitting them into smaller amounts for which there is sufficient liquidity. Furthermore, multipath payments have been shown to increase the probability of a successful payment, as compared to a single-path payment.
+Multipart payments are a significant improvement in the Lightning Network because they make it possible to send amounts that won't "fit" in any single channel by splitting them into smaller amounts for which there is sufficient liquidity. Furthermore, multipart payments have been shown to increase the probability of a successful payment, as compared to a single-path payment.
 
 [TIP]
 ====
-Now that MPP is available it is best to think of a single-path payment as a subcategory of an MPP. Essentially, a single-path is just a multipath of size one. All payments can be considered as multipath payments unless the size of the payment and liquidity available make it possible to deliver with a single part.
+Now that MPP is available it is best to think of a single-path payment as a subcategory of an MPP. Essentially, a single-path is just a multipart of size one. All payments can be considered as multipart payments unless the size of the payment and liquidity available make it possible to deliver with a single part.
 ====
 
 ==== Using MPP
@@ -371,7 +371,7 @@ In our example we can see some immediate improvements to our path finding proble
 
 The fundamental question is how to split the payments. More specifically, what are the optimal number of splits and the optimal amounts for each split?
 
-This is an area of ongoing research where novel strategies are emerging. Multipath payments lead to a different algorithmic approach than single-path payments, even though single-path solutions can emerge from a multipath optimization (i.e., a single path may be the optimal solution suggested by a multipath path finding algorithm).
+This is an area of ongoing research where novel strategies are emerging. Multipart payments lead to a different algorithmic approach than single-path payments, even though single-path solutions can emerge from a multipart optimization (i.e., a single path may be the optimal solution suggested by a multipart path finding algorithm).
 
 If you recall, we found that the uncertainty of liquidity/balances leads to some (somewhat obvious) conclusions that we can apply in MPP path finding, namely:
 
@@ -395,14 +395,14 @@ To read more about the optimization problem known as minimum-cost flows involved
 In our example, Selena's node will attempt to split the 1M satoshi payment into two parts with 600k and 400k satoshi, respectively, and send them on two different paths. This is shown in <<mpp_paths>>.
 
 [[mpp_paths]]
-.Sending two parts of a multipath payment
+.Sending two parts of a multipart payment
 image::images/mtln_1209.png[]
 
 Because the S->X channel can now be utilized, and (luckily for Selena), the B->R channel has sufficient liquidity for 600k satoshis, the two parts are successful along paths that were previously not possible.
 
 ==== Trial-And-Error Over Multiple "Rounds"
 
-Multipath payments lead to a somewhat modified trial-and-error loop for payment delivery. Because we are attempting multiple paths in each attempt, we have four possible outcomes:
+Multipart payments lead to a somewhat modified trial-and-error loop for payment delivery. Because we are attempting multiple paths in each attempt, we have four possible outcomes:
 
 * All parts succeed, the payment is successful
 * Some parts succeed, some fail with errors returned
@@ -438,4 +438,4 @@ In this chapter we looked at path finding and payment delivery. We saw how to us
 
 We also examined the uncertainty of channel liquidity (from the perspective of the sender) and the implications that has for path finding. We saw how we can quantify the uncertainty and use probability theory to draw some useful conclusions. We also saw how we can reduce uncertainty by learning from both successful and failed payments.
 
-Finally, we saw how the newly deployed multipath payments feature allows us to split payments into parts, increasing the probability of success even for larger payments.
+Finally, we saw how the newly deployed multipart payments feature allows us to split payments into parts, increasing the probability of success even for larger payments.

13_wire_protocol.asciidoc

@@ -385,7 +385,7 @@ single payment to be split into multiple parts or paths, to be assembled at the
 recipient for settlement. The rollout of MPP was coupled with a new
 `node_announcement` level feature bit that indicates that the recipient knows
 how to handle partial payments. Assuming a sender and recipient know about each
-other (possibly via a BOLT 11 invoice), then they're able to use the new
+other (possibly via a BOLT #11 invoice), then they're able to use the new
 feature without any further negotiation.
 
 Another example of an end-to-end upgrade are the various types of

15_payment_requests.asciidoc

@@ -57,7 +57,7 @@ a mechanism that allows a sender to typically request a new payment request
 from the receiver, then an interactive protocol can be used to allow a
 degree of payment request reuse.
 
-=== BOLT 11: Lightning Payment Request Serialization & Interpretation
+=== BOLT #11: Lightning Payment Request Serialization & Interpretation
 
 In this section, we'll describe the mechanism used to encode the set of
 information required to complete a payment on the Lightning Network. As
@@ -91,10 +91,10 @@ its own human-readable prefix (see <<table1501>>). This allows client software a
 quickly determine if a payment request can be satisfied by their node or not.
 
 [[table1501]]
-.BOLT 11 network prefixes
+.BOLT #11 network prefixes
 [options="header"]
 |=============================
-|Network       |BOLT 11 prefix
+|Network       |BOLT #11 prefix
 |mainnet       |`lnbc`
 |testnet       |`lntb`
 |simnet/regtest|`lnbcrt`
@@ -114,7 +114,7 @@ of an invoice at a glance, take the base factor and multiply it by the
 A full list of the currently defined multipliers is given in <<table1502>>.
 
 [[table1502]]
-.BOLT 11 amount multipliers
+.BOLT #11 amount multipliers
 [options="header"]
 |==============================================
 |Multiplier|Bitcoin unit|Multiplication factor
@@ -144,7 +144,7 @@ timestamp allows the sender to gauge how old the invoice is, and as we'll see
 later, allows the receiver to force an invoice to only be valid for a period of
 time if they wish.
 
-Similar to the TLV format we learned about in <<tlv>>, the BOLT 11 invoice
+Similar to the TLV format we learned about in <<tlv>>, the BOLT #11 invoice
 format uses a series of extensible key-value pairs to encode information
 needed to satisfy a payment. Because key-value pairs are used, it's easy to add
 new values in the future if a new payment type or additional
@@ -177,7 +177,7 @@ A given tag field is comprised of three components:
 A full list of all the currently defined tagged fields is given in <<table1503>>.
 
 [[table1503]]
-.BOLT 11 tagged invoice fields
+.BOLT #11 tagged invoice fields
 [options="header"]
 |===
 |Field tag|Data length|Usage

16_security_privacy_ln.asciidoc

@@ -36,7 +36,7 @@ If two colluding nodes happen to be on the same payment path, they would underst
 
 [NOTE]
 ====
-Multipath payments (see <<mpp>>) enable users to obfuscate their payment amounts given their nonuniform split sizes.
+Multipart payments (see <<mpp>>) enable users to obfuscate their payment amounts given their nonuniform split sizes.
 ====
 
 What may be the goals of a Lightning attacker?