Merge source into master

_src/posts/payment-splitting-in-lightning-network.md

@@ -13,15 +13,15 @@ This post assumes you have knowledge about how payments work in Lightning Networ
 
 ## Base MPP
 
-Probably the simplest form of multi-part payments (MPP) is Base MPP. That's why it's sometimes also referred to as [Simplified Multipath Payments][optech] (SMP). It is the only type of MPP that is part of the official [Lightning Network specifications][bolt-mpp], aka Basis of Lightning Technology (BOLT). The basic idea is that the sender uses multiple payments that combined are enough to buy the thing it wants. All those payments use the same payment hash, and a group of HTLCs which uses the same payment hash are called an HTLC set.
+Probably the simplest form of multi-part payments (MPP) is Base MPP. That's why it's sometimes also referred to as [Simplified Multipath Payments][optech] (SMP). It is the only type of MPP that is part of the official [Lightning Network specifications][boltmpp], aka Basis of Lightning Technology (BOLT). The basic idea is that the sender uses multiple payments that combined are enough to buy the thing it wants. All those payments use the same payment hash, and a group of HTLCs which uses the same payment hash are called an HTLC set.
 
 A sender can only use Base MPP if the receiver has shown support for it. The receiver does this by offering the `basic_mpp` feature in the invoice. The sender can now use multiple payments to pay the invoice. It should try to use diverse paths to the receiver, to increase the chances of success. The receiver, upon receiving the first HTLC out of the set, waits for at least 60 seconds for the other HTLCs from that set. If it receives them all, it reveals the pre-image to collect all of them. If it doesn't receive all HTLCs in time, it fails all HTLCs it *did* receive.
 
 There is no cryptographic trickery that makes it impossible for the receiver to reveal the pre-image prematurely, but the receiver does have an economic incentive not to do so.
 
 ## Link MPP
 
-Base MPPs lesser known sibling is [Link MPP][bitcoinse1]. Link MPP works in a situation where two nodes have two parallel channels between them. At some point one of the nodes gets asked to relay a payment to the other node, but none of the balances in either channel is sufficient. Instead of failing the payment, the nodes agree to use both channels to relay the payment in two parts using the same payment hash. The channel partner should wait until both HTLCs are received, before forwarding the payment further. Link MPP is different from Base MPP in a variety of ways. Base MPP uses different paths, while Link MPP is something that happens inside a hop (with parallel channels) that is part of a bigger path. More importantly, Base MPP is something that is initiated by the sender: it's the sender who breaks up the payment in different parts. Link MPP is initiated by the two channel partners and the sender doesn't need to (and won't) know about it, nor does the receiver. Also, Link MPP isn't part of the official [Lightning Network specifications][bolt-mpp] and I don't know of any client that supports it. But Link MPP can be (and maybe has been) implemented without it being part of the LN protocol. Two nodes can have their own Link MPP protocol that nobody needs to know about.
+Base MPPs lesser known sibling is [Link MPP][bitcoinse1]. Link MPP works in a situation where two nodes have two parallel channels between them. At some point one of the nodes gets asked to relay a payment to the other node, but none of the balances in either channel is sufficient. Instead of failing the payment, the nodes agree to use both channels to relay the payment in two parts using the same payment hash. The channel partner should wait until both HTLCs are received, before forwarding the payment further. Link MPP is different from Base MPP in a variety of ways. Base MPP uses different paths, while Link MPP is something that happens inside a hop (with parallel channels) that is part of a bigger path. More importantly, Base MPP is something that is initiated by the sender: it's the sender who breaks up the payment in different parts. Link MPP is initiated by the two channel partners and the sender doesn't need to (and won't) know about it, nor does the receiver. Also, Link MPP isn't part of the official [Lightning Network specifications][boltmpp] and I don't know of any client that supports it. But Link MPP can be (and maybe has been) implemented without it being part of the LN protocol. Two nodes can have their own Link MPP protocol that nobody needs to know about.
 
 ## Atomic Multi-Path Payments, the OG MPP
 
@@ -45,8 +45,8 @@ The sender creates the Base Secret just like before. Using the BS it creates a p
 
 [ln-post]: /post/how-do-payments-in-lightning-network-work/ "How do payments in Lightning Network work?"
 [optech]: https://bitcoinops.org/en/topics/multipath-payments/ "Bitcoin Optech: Multipath payments"
-[bolt-mpp]: https://github.com/lightning/bolts/blob/master/04-onion-routing.md#basic-multi-part-payments "BOLT #4: Basic Multi-Part Payments"
-[bitcoinse1]: https://bitcoin.stackexchange.com/questions/98697/what-is-link-level-multiplexing "What is "Link-Level Multiplexing"?"
+[boltmpp]: https://github.com/lightning/bolts/blob/master/04-onion-routing.md#basic-multi-part-payments "BOLT #4: Basic Multi-Part Payments"
+[bitcoinse1]: https://bitcoin.stackexchange.com/questions/98697/what-is-link-level-multiplexing "What is Link-Level Multiplexing?"
 [bitcoinse2]: https://bitcoin.stackexchange.com/questions/89475/what-are-atomic-multi-path-payments-amps-and-why-how-is-it-being-implemented-i "What are atomic multi path payments (AMPs) and why/how is it being implemented in Lightning Network?"
 [ln-dev]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html "AMP: Atomic Multi-Path Payments over Lightning"
 [sa-post]: /post/why-does-signature-half-aggregation-break-adaptor-signatures/ "Why does signature half aggregation break adaptor signatures?"