In this article, we’ll go through multipart payments in the Lightning Network, a critical evolution that overcomes single-part payment restrictions and allows more significant amounts by splitting them into smaller parts. We explore the intricacies of multipart payments, their benefits to network decentralization and privacy, and the different implementation methods currently available, each with its unique tradeoffs.
Single Part Payments Restrictions
Let’s go through a thought experiment to understand the purpose of multipart payments better.
Pretend that Alice wants to send 1 Bitcoin to Bob through the Lightning Network. Alice has two payment channels, one with Chan and one with Dina. Chan and Dina each have two payment channels—one with Alice, as mentioned, and one with Bob. For the sake of simplicity, let’s assume that every channel has a capacity of 0.5 Bitcoin. This is what this piece of the network looks like:
When Bob sends the 1 BTC invoice to Alice, Alice’s node will look for a viable payment path to send the payment through. Since Alice is sending 1 BTC, every payment channel in the selected path must have at least 1 BTC of channel capacity. Considering this limitation, Alice cannot send the payment to Bob since no channel has the required capacity of 1 BTC. If single-part payments were the only payment option in the network, the max amount one could send would be limited to the biggest channel in the network.
But what if Alice was able to split the payment into different parts? Instead of one payment of 1 Bitcoin to Bob, she could send the payment in two parts: 0.5 BTC through her channel with Chan and 0.5 BTC through her channel with Dina. Previously, the highest payment amount was bounded by the channel with the highest capacity. Now, the sum of all channel balances limits the highest payment amount. This is the essence of a multipart payment: splitting the total amount into smaller parts.
Note that multipart payments are also commonly referred to as “multipath” payments, but that’s imprecise terminology since all parts can flow through the same path. Therefore we’ll be using “multipart” instead of “multipath” throughout this article.
Network Benefits
As discussed in the privacy post, payment linkability is one of the privacy issues with HTLCs. Since all HTLCs for a single payment are bound to the same payment secret, it’s trivial for a malicious network participant to unveil information about a payment simply by controlling more than one node in a specific payment path and matching HTLCs. Multipart payments can break this heuristic when using multiple paths for a payment. The malicious node can’t be certain of the total amount of the payment. For instance, if it is not present in all paths, the payment was split.
Another benefit of multipart payments is that they can help to make the network more decentralized. Instead of relying upon big hubs with channels with enough capacity to route a big payment, the payment can be split into smaller bits that can be routed through nodes with less capacity, making these nodes more active than they would be if they could route payments which the total amount is less or equal to the capacity of their channels.
Finally, as mentioned earlier, multipart payments allow the network to handle bigger payments, as the total amount one could send is not limited to the biggest channel in the network anymore.
Multipart Payments Implementations
As discussed, a multipart payment is a payment that is split into smaller bits. Since these payments need to be routed through the Lightning Network, this method must be compatible with the protocol. There are multiple ways of implementing multipart payments. Let’s take a look at some of them and the tradeoffs they offer.
Simplified Multipath Payment (SMP)
As the name suggests, this is the simplest implementation of multipart payments, which requires the least amount of changes to the protocol. Let’s return to the initial example, in which Alice needs to pay Bob 1 BTC and see how SMPs can be used to split the payment.
To initiate the payment process, Bob sends an ordinary BOLT 11 invoice to Alice with a payment request of 1 BTC. The invoice includes essential details such as the payment hash for the payment secret (preimage) utilized by Bob for this payment and the complete payment amount, along with other mandatory and optional information required by BOLT 11.
With Bob’s invoice, Alice’s node starts path selection, considering that the payment can be split to improve delivery efficiency. The node selects two paths:
- Alice → Chan → Bob
- Alice → Dina → Bob
Then it proceeds to create the HTLCs and onion packets to forward the payment through both routes, filling the “amount to forward” fields with 0.5 BTC and the “total amount” with 1 BTC, signaling all nodes in the payment path that the payment is split into multiple parts. Finally, Alice sends the onions through each route just as she would for a single part payment.
Bob’s expected to receive both HTLCs at different times, and SMPs differ greatly from single-part payments. When receiving an HTLC from a regular single-part payment, the receiver can immediately send the payment secret back, providing the payment proof for the sender. With SMPs, Bob needs to wait for all HTLCs before sending the payment secret back. If he sends the payment secret immediately, he loses the guarantee that he can redeem all the HTLCs since the payment secret was revealed, and this information can be used by anyone that holds an HTLC bound to this secret to redeem the payment.
Despite each HTLC being atomic, SMPs are not atomic because the protocol cannot force the receiver to reveal the secret only after it receives all the HTLCs. The only guarantee that the receiver will reveal the secret before receiving all the payments is the economic incentive it has to wait for all the HTLCs, so it can redeem the total amount.
From the GIF above, Bob waits until it receives all HTLCs before returning the payment secret. Also, note that by using a simplified multipart payment, Alice can receive her proof of payment and that all HTLCs are bound to the same payment secret. Using the same payment secret for all HTLCs means that the payments can still be tracked, but a malicious node would have to be present in all paths to be able to link together the total payment amount.
Atomic Multipart Payments
Atomic Multipart Payments was the first proposal for multipart payments. They differ from SMPs because the payment is, as the name suggests, atomic. This means that either the whole payment succeeds entirely or it doesn’t. The receiver cannot redeem only a part of the payment, as was the case with SMPs.
To achieve atomicity, this protocol has to ensure that the receiver can only redeem its payment after it receives all the HTLCs. To enable that, the sender creates a single payment secret and uses this initial value to derive partial secrets for each hop. The redeemer can only reconstruct the original payment secret if it has all the HTLC, satisfying the atomicity requirement.
This scheme makes all HTLCs in the payment bound to different secrets, meaning payment linkability is impossible. Another benefit is that only the sender and the receiver need to implement AMPs for them to work properly. The tradeoff for using AMPs is that, although atomic and harder to track, AMPs make it impossible for the receiver to provide proof of payment since the sender knows the original payment secret from the beginning.
If Alice were to pay Bob using an AMP, she would create an initial payment secret based on public information available for Bob’s node. Alice creates the partial secrets for each hop and sends the HTLCs forward. The hops forward the HTLC to Bob. Once Bob has all the HTLCs, he can compute the original payment secret and redeem the payment.
Multipart Payments with PTLCs (High AMP)
As shown above, SMPs and AMPs have tradeoffs. SMPs allow proof of payment, but all hops use the same payment hash, which makes payments correlatable, and the protocol does not ensure atomicity. On the other hand, AMPs are, as the name suggests, atomic, and they break payment linkability by using different payment hashes for all HTLCs, but one cannot obtain proof of payment using this method, as the sender knows the payment secret from the beginning.
There is a third kind of multipart payment, called High Atomic Multipart Payment (High AMP), which combines the pros of both previous methods, enabling atomic multipart payments with proof of payment while solving the issue of payment linkability. However, High AMPs require PTLCs to be implemented in the Lightning Network.
With High AMPs, the sender selects a base private key and generates private keys for each path, such that the sum of all private keys for each path equals the base private key. The sender then adds the public key to the payment point of the recipient on each path. The recipient cannot claim any payment because they are unaware of the respective private key. Once all paths are delivered, the recipient can calculate the base private key using the received values and then claim the payments.
Multipart Payment and Payment Reliability
For the Lightning Network to succeed, payments must be reliable and cheap. There’s currently active research in the field to propose and test different payment methods and algorithms that leverage the benefits of multipart payments to achieve higher payment reliability.
Rene Pickhardt’s paper, “Optimally Reliable & Cheap Payment Flows on the Lightning Network,” for instance, proposes a new method that considers the likelihood of a multipart payment being successful based on unknown balance distributions in payment channels. This method, called “minimum cost flows,” updates the best paths with information gained from successful and unsuccessful paths on prior payment attempts.
Explore our Lightning FAQ which is growing weekly with new content helping builders grok and understand the foundational components of Lightning.
You can start building on Lightning today, hop on our Dashboard and spin up your own node below!
