Table of Contents

Understanding Atomic Multipath Payments

The Lightning network seamlessly facilitates small payments (micropayments) on Bitcoin as traditional Bitcoin transactions typically have a longer confirmation time and could incur huge fees for small transactions. This focus on micropayments has been a key factor for Lightning’s adoption as it has enabled use cases that were previously not feasible.

Using the Lightning network, people can now pay for coffee, gift items, airtime and even donations. Millions of people can perform off-chain Lightning payments instantly without having to interact with on-chain Bitcoin.

Although Lightning’s prior use cases have focused on micropayments, new improvements to the Lightning network now aim to make it more reliable and suitable for large bitcoin payments. In this article, we would be exploring Atomic Multipath Payments (AMP) and how they can be used to facilitate fast and reliable large bitcoin payments over the Lightning Network.

What Are Atomic Multipath Payments?

Atomic Multipath Payments (AMP) is a new type of Lightning payment implemented by lnd in version v0.13.0-beta that allow a single payment to be split into multiple smaller payments, which are then sent simultaneously through different payment channels.

With AMP, a payment is divided into a series of smaller payment segments, with each segment assigned a unique payment hash which is like a piece of the single preimage generated by the sender. These payment segments are then sent through different payment channels, each with a corresponding hash time-locked contract (HTLC). This allows the recipient to aggregate the payment segments into a single payment by proving knowledge of the preimage of each HTLC.

Multipath payments (MPP) are not a new concept in Lightning but Atomic Multipath Payments differ from MPP as they are governed by the principle of Atomicity which states that “All payments are settled, or no payment is settled”. MPPs, on the other hand, use the same payment hash for all shards, which makes it easy to correlate individual routes and can result in only partial settlement. In contrast, AMPs are either fully settled or not settled at all.

As Atomic Multipath Payments is an end-to-end upgrade, only the sender and receiver need to understand the new payment type and hence does not require an update of the Lightning network before it can be widely used.

Why Are Multipath Payments necessary?

When routing a lightning payment, the ability of a routing node to move lightning payments from the sender to the destination depends on the following factors:

Channel Capacity: This is the aggregate amount of satoshis that were funded into the 2-of-2 multisig with the funding transaction that creates the lightning channel. It represents the maximum amount of value held in the channel. The channel capacity is announced by the gossip protocol and is known to the nodes. The routing node’s payment channels must have enough capacity to accommodate the payment amount. If the payment exceeds the channel capacity, the routing node cannot forward the payment. (Even if you loaded 1 Bitcoin onto your lightning node and used it to open 10 0.1BTC channels then you would not be able to make a single payment larger than 0.1BTC – without an AMP).
Balance: This is the amount of satoshis held by each channel partner that can be sent to the other channel partner. A subset of the balance of A can be sent in the direction (A→B) toward node B. A subset of the balance of B can be sent in the opposite direction (A←B).
Liquidity: This is the available (subset) balance that can be sent across the channel in one direction. The liquidity of A is equal to the balance of A minus the channel reserve and any pending HTLCs committed by A. The routing node must have sufficient funds available in its payment channels to facilitate the payment. If a node has insufficient funds, it cannot forward the payment.
Fee Policy: Routing nodes can set their own fee policies and choose which payments to route based on the fees offered. If the fee offered by the sender is too low or the routing node’s fees are too high, the routing node may choose not to forward the payment.
Network Topology: The topology of the Lightning Network can affect the ability of routing nodes to forward payments. If the shortest path between the sender and receiver involves nodes that are not well connected or have insufficient liquidity, the payment may fail.
Uptime and Reliability: Routing nodes must be online and available to forward payments. If a node goes offline or experiences connectivity issues, it may not be able to forward payments.

Out of the 6 major factors above, the Liquidity and Capacity of the Lightning channel remain the most prominent hindrance to routing large payments on the Lightning network. This is is because payment channels in the Lightning Network have a limited capacity, which is determined by the amount of Bitcoin that is locked up in the channel. If a payment exceeds the channel’s capacity, it cannot be processed through that channel. Using Atomic Multipath payments, the payment can be split into multiple smaller payments, each of which is routed through a different payment channel. This enables payments to be made that exceed the capacity of a single payment channel, increasing the overall efficiency of the network.

How Atomic Multipath Payment works

AMP allows for the splitting of payments across multiple paths in the network.

Here’s an example of how an AMP works:

Alice wants to send 1 BTC to Bob over the Lightning Network.
Since it might be difficult to find a channel with a capacity of up to 1 BTC, Alice’s wallet can split the payment into 10 small payments of 0.1 BTC each with a unique payment hash which is like a shard of a single preimage for a 1 BTC payment.
Each part is routed along a separate path to Bob’s wallet, with its own unique payment hash.
If one of the paths is unable to complete the payment, then all the payments would not be completed.
When Bob receives all parts of the payment, he matches the payment hashes and combines them into a single payment hash which he uses to claim the 1 BTC payment.

In the next part of this article, I would be detailing a comparative analysis between Atomic Multipath Payments and other currently existing and soon-to-be-widely-implemented features of the Lightning Network

Atomic Multipath Payment Vs Invoices

Bolt 11 Lightning invoice is the simplest way to make and receive payments on the Lightning network. An invoice is a request for payment that includes information such as the amount to be paid, the recipient’s public key, and a payment hash. The payer can then use this information to create a payment channel and send the payment to the recipient. You can learn more here in my article – Lightning invoices: how Bolt 11 and Bolt 12 work.

AMPs are more versatile than Invoices as they allow for larger payments to be processed through the Lightning Network, hence increasing the network’s scalability and use cases. AMP also provides enhanced privacy and security, as payments are distributed across multiple payment channels, reducing the risk of third-party tracing or partial settlements. On the other hand, Lightning Invoices cannot be used to perform very large payments as they are usually restricted by the liquidity and capacity of routing nodes. Furthermore, AMP invoices are reusable and can be used for things like subscriptions and donations while Lightning invoices can only be used once.

Feature	Atomic Multipath Payments (AMP)	BOLT 11 Invoices
Purpose	Splitting a single large payment into multiple smaller payments	Requesting payment from a payer
Routing	Payment is split and routed through multiple channels	Payment is routed through a single channel
Requirement	The recipient must support AMP to receive payments	The recipient must generate an invoice for the payer
Payment Size	Can be used for larger payments that exceed the capacity and liquidity of a single channel	Typically used for smaller, one-time payments
Security	Provides enhanced privacy and security, reducing the risk of partial settlements and third-party tracing	Secure and simple way to request payments
Complexity	Can increase the complexity of routing payments, increasing the likelihood of errors or delays	Simple and easy to generate invoices
Use Cases	Useful for larger or recurring payments, as well as enhanced privacy and security	Useful for merchants or individuals who want to receive payments in the Lightning Network
Preimage	Generated by sender, but only known by receiver once all shards are settled	Generated by the receiver

Atomic Multipath Payment Vs Keysend

KeySend is a bLIP (Bitcoin and Lightning Improvement Protocol) feature that allows for small, one-time payments to be sent via the Lightning network without requiring an invoice. This makes KeySend simple and easy to use as they enable payment to be made by the sender without relying on the receiver to provide an invoice. However, for a keysend to occur, the receiver needs to share their public key with the sender once, and then payments of any amount can be made from the sender to the receiver at any time in the future. The sender chooses the hash preimage of the payment hash and encrypts it with the public key of the receiver, hence ensuring that only the receiver can decrypt the payment hash and claim the payment.

AMP is designed for larger payments that exceed the capacity of a single channel. By splitting the payment into multiple shards, AMP allows users to route payments through multiple channels and complete larger transactions that might not otherwise be possible. Additionally, the use of separate payment hashes for each shard improves security and privacy, as partial settlements and third-party tracing become less likely.

In contrast, KeySend is tailored for small, one-time payments that can be sent directly to a recipient’s node without the need for an invoice. This simplicity makes KeySend ideal for use cases like tipping, donations, or other micropayments where an invoice is not necessary or practical.

Feature	Atomic Multipath Payments (AMP)	Keysend
Purpose	Splitting a single large payment into multiple smaller payments	Sending small, one-time payments without requiring an invoice
Routing	Payment is split and routed through multiple channels	Payment is sent directly to the recipient through onion routing
Payment Size	Can be used for larger payments that exceed the capacity of a single channel	Typically used for smaller payments
Invoice/Receipt	Allows for the use of static invoices which can serve as receipt of payment	Does not require the use of invoices at all
Use cases	Useful for larger or recurring payments, as well as enhanced privacy and security	Useful for micropayments or situations where an invoice is not available
Preimage	Generated by sender, but only known by receiver once all shards are settled	Generated and known by the sender

Atomic Multipath Payment Vs Offers

Offers are a relatively new feature of the Lightning Network that allows users to create invoices that can be reused multiple times, making it easier to conduct recurring transactions such as subscriptions. By enabling users to create a single invoice that can be used multiple times, Offers streamlines the invoicing process and reduces the risk of errors or missed payments.

Offers and Atomic Multi-Path Payments (AMP) are both two powerful features of the Lightning Network that can help expand its capabilities in unique ways. However, the only major difference between an Offer and a AMP is that AMP is more suited for large payments because of its multipath feature.

Features	Atomic Multi-Path Payments (AMP)	Offers
Purpose	Suited for larger transactions that require routing across multiple channels	Suited for recurring transactions where a single invoice can be used multiple times
Complexity	AMP routing can be more complex and introduce additional latency and potential routing errors	Offers are relatively simple and easy to use
Use cases	Ideal for high-value, infrequent transactions that require multi-channel routing	Ideal for subscriptions, recurring payments, and low-value transactions
Drawback	Routing can be more complex, may introduce additional latency, and not suitable for low-value transactions	Not suitable for larger transactions that exceed channel capacity, less privacy, and higher risk of errors with recurring payments
Preimage	Generated by sender, but only known by receiver once all shards are settled	Offers can be used to receive payment and also request payment and can be generated by either the sender or receiver

Setting up AMPs on your Lightning Node

If you want to be able to receive spontaneous AMPs, you will need to set

accept-amp=1

in your lnd.conf file before starting your upgraded node.

You will now be able to pay other AMP-enabled nodes by calling the command:

lncli sendpayment --amt <amount in satoshis> --dest <recipient’s public key> --amp

Conclusion

As more people start to use the Lightning network to facilitate payments daily, a stronger focus on some of its limitations would begin to emerge, with one of such limitations being its suitability for large payments. With AMPs, we can address this limitation and unlock excitingly new use cases for Lightning to be used to make large payments which were initially thought to be only suitable as on-chain Bitcoin transactions.

Thank You For Reading

If you found this article helpful, please consider sharing it, supporting one of these affiliates, or making a value for value donation so that we can continue to publish more Bitcoin-only content.

A Comprehensive Guide to Lightning’s Atomic Multipath Payments (AMP)