What are atomic multi path payments (AMPs) and why/how is it being implemented in Lightning Network?

Question

There has been a lot of discussion and articles around how the implementation of AMP is going to benefit the routing capabilities of Lightning Network. What is the exact issue in the current implementation of Lightning that AMP is solving? How does AMP really work? and how is it going to be implemented?

Answer 1

The Current Problem

The major challenge in the current routing mechanism is finding channels with sufficient balance on one side of a node to forward an incoming payment. To be more descriptive, the channel_announcement or the channel_update messages that are broadcasted contains the short_channel_id through which lightning nodes can look up the transaction in the Bitcoin blockchain and find out how many bitcoins are locked in that channel. However, one does not know how much each node of the channel holds. This creates an issue in terms of routing a payment as one side of the channel may not have enough balance to forward the transaction resulting in a routing failure and the origin node has to retry the payment using a different route.

The second issue is with origin node channel balances. Say I am buying a cup of coffee from Starbucks that costs me 20,000 satoshis. Now I have three open channels in the lightning network with my balance equal to 9,000 satoshi in each channel. Neglecting channel reserve balance and transaction fees for now, I can only make payments of 9,000 satoshis in each channel, which makes me incapable of buying that cup of coffee in a single payment. The get around would be to make three payments to the same payment invoice that Starbucks offers me when buying that cup of coffee across all three channels. But this renders security issues, from hash re-use. A node having channels across the paths can use the pre-image it learnt from one path to fulfill a payment along the other path. Also, if only a partial payment went through then I would be at the mercy of Starbucks to refund me the partial payments I did earlier.

The third issue is that at the moment (although temporary) we have a limit of 2³² milli-satoshi (~0.0429 BTC) on a single payment size. Payments above this limit needs to be done via multiple payments. But this again brings the risk of one payment going through and subsequent payments failing to reach the receiver. You are then left to ask the receiver to process a refund to you.

---

The Solution

Conner Fromknecht and Olaoluwa Osuntokun proposed Atomic Multi Path (AMP) payments in order to solve both the above issues by breaking a larger payment into smaller ones while at the same time not re-using any payment hashes across all the smaller payment flows, and adding a strong guarantee that the receiver won't be paid at all until all partial payment flows are completed (atomicity).

Their proposal required the sender to send some secret s_i to the receiver in each smaller payment i. When all payments have been received by the receiver, it will then construct the base payment (BP) secret by taking XOR of all the partial secrets that were sent by the sender, such that BP = s_1 ^ s_2 ^ ... ^ s_n. Now each payment pre-image is SHA256(BP || i). This had the advantage that the receiver could not create the pre-image until all partial payments have been received, thus solving the partial payment as well as the hash re-use issue.

This form of payment proposal is really helpful if done between friends, however, for business usage this proposal has a weakness. We consider the receipt of a pre-image as a cryptographic proof that a successful payment has occurred. If the sender knows and can calculate the pre-images in advance, this destroys the whole principle of a cryptographic receipt that you will get from the receiver of the payment. Since the proposal required the sender to create the shared secrets and the payment_hash, the sender knew the pre-images in advance.

To solve this issue, Basic MPP (multi-path payments) was proposed. Basic MPPs use the same payment_hash for all paths through which the payment will be made. The receiver however, does not release the payment pre-image until all successful payments have been received to thwart the possibility of an intermediate node using the pre-image from one leg of the payment and satisfying the other branch. Since proof-of-payment is valuable then no rational payee will accept partial payments until all parts of the payment have arrived and as a result will not release a pre-image. However, if it releases pre-image along one path, it is in the economic interest of the payee to release the pre-image along all the paths.

---

Implementation

A new type-length-value (TLV) format is now being followed in the Lightning Network protocol as compared to a fixed length byte stream in earlier versions. The use of TLV permits a space saving, potentially leaving more space for application data over the wire or in an onion payload. Nodes supporting such variable payload routing onions indicate it by setting the global_features flag, bits 8/9 (var_onion_optin). Moreover, the lightning invoice generated needs to set the basic_mpp feature.

Base AMPs uses the same payment_hash for all paths through which the payment will be made. If the final node receives an onion packet which includes a basic_mpp field, then the payment MAY be a "base" AMP. Setting the basic_mpp flag is a promise by the sender that the rest of the payments will follow in succeeding HTLCs. All the HTLCs that will be received that fulfills the payments having the same payment pre-image are called as "htlcset".

Upon receiving an onion with basic_mpp, the receiver should wait at least 60 seconds for all other payments to come through. If the payments are not received in sufficient period of time, the final node must fail all the htlcs in the htlcset. However, if it fulfills any HTLCs in the htlset, it must fulfill ALL of them. This subset restriction prevents the pre-image from being released before all the partial payments have arrived: that would allow any intermediate node to immediately claim any outstanding partial payments.

---

Future Releases

Work is being currently done on High AMPs. It combines both the original proposals of AMP and the current Base MPP, retaining proof-of-payment (which was sacrificed by the original proposal) and ensuring cryptographically-secure waiting for all parts (rather than the mere economically-incentivized of Base AMP).

This however, requires that we switch to points and scalars instead of hashes and pre-images. An invoice will now contain a payment point which is basically generated by multiplying a scalar (equivalent to private key) with the standard generator point on secp256k1. Proof-of-payment does not require revelation of the scalar, but a signature using the scalar behind the public key is sufficient to provide proof-of-payment. This also allows support for payment de-correlation (additional scalars are added at each hop, and the sum total scalar is told to the payee), while not requiring either proof-of-payment or spontaneous payments (it can work with either). This is basically Scriptless Script usage on Lightning. Instead of HTLCs we have Scriptless Script Pointlocked Timelocked Contracts (PTLCs).

However, implementation of this would require Schnorr implementation on the Bitcoin mainchain which might be couple of years out.