Routing and pathfinding on the Lightning Network is a rapidly evolving area of research. The topology of the network allows for payments to be sent peer-to-peer over connected channels where liquidity can flow.
In this article, we’ll cover the differences between Multi-part Payments (MPP) and Atomic Multi-part Payments (AMP). To understand the differences, let’s first review Bolt 11 and Keysend payments.
BOLT 11 Invoice Payment
The receiver must generate an invoice which encodes the following:
- receiver’s public key
- payment hash
- payment amount
- timestamp
- CLTV expiry
- (optional) routing hints
With the invoice, the sender constructs a route to forward the payment along to the receiver using HTLCs that can be redeemed with a preimage that only the receiver knows. The sender can choose to use the routing hints provided in the invoice.
Once the receiver has been handed an HTLC that satisfies the invoice, he will reveal the preimage to the payment hash back along the route allowing each hop to redeem their HTLC as well.
BOLT 11 invoices are atomic, meaning the payment either succeeds or fails entirely, and they provide proof of payment because the only way the sender can know the preimage is if the payment worked.
Keysend
With keysend, the sender can make a spontaneous payment using the recipient’s public key. The sender generates a secret payment_key and inserts it into the onion such that only the receiver can read it.
As before, the payment is forwarded along to the destination using HTLCs.
Once the receiver has uncovered the payment_key, he can redeem the HTLC by revealing the key to every node along the path.
Keysend payments are atomic, but proof-of-payment is impossible since the sender knows the payment_key from the start.
Multipart Payments (MPP)
A multipart (or multi-path) payment is a concept for a lightning network payment where the required amount is sent over many smaller payments using multiple routes to get to the destination.
MPP is preferable for many reasons:
- Privacy – the full payment amount is not revealed to any routing node
- Larger payments – nodes can make full use of their wallet balance since they no longer limited by the size of their largest channel.
There are many proposed implementations of MPP. Each has various tradeoffs regarding proof-of-payment and atomicity.
We will review the following proposals of MPP:
- Base AMP
- Basic MPP
- High AMP
Base AMP
In this proposal, the sender essentially makes multiple keysend payments to the receiver. However, the payments are constructed such that the receiver must have all the preimages from all the paths to claim the funds.
This approach gives strong cryptographic assurance of atomicity (hence why it is called Base AMP). However, as with keysend, the proof-of-payment is weak since the sender can also reconstruct the information needed to “prove” the payment was received. The sender knows all the preimages since he wrapped them in the onion to begin with.
Basic MPP
Basic MPPs use the same payment_hash for all paths through which the payment will be made. It also requires an invoice since the receiver is the one who will reveal the preimage providing the proof-of-payment.
The receiver however, does not release the payment pre-image until all successful payments have been received.
Basic MPP relies on an economic incentive for the receiver to claim ALL funds vs. just SOME of the funds. This is not atomic.
High AMP
High AMPs are a way to combine the above approaches and gain the benefits of both. i.e. atomicity and proof-of-payment.
This implementation requires PTLCs.
Leave a Reply