<h2>The Current Problem</h2>

<p>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 <code>channel_announcement</code> or the <code>channel_update</code> messages that are broadcasted contains the <code>short_channel_id</code> 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.</p>

<p>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.</p>

<p>The third issue is that at the moment (although temporary) we have a limit of 2<sup>32</sup> 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.</p>

<hr>

<h2>The Solution</h2>

<p>Conner Fromknecht and Olaoluwa Osuntokun <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html" rel="noreferrer">proposed Atomic Multi Path</a> (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). </p>

<p>Their proposal required the sender to send some secret <code>s_i</code> 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 <code>BP = s_1 ^ s_2 ^ ... ^ s_n</code>. Now each payment pre-image is <code>SHA256(BP || i)</code>. 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.</p>

<p>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 <code>payment_hash</code>, the sender knew the pre-images in advance.</p>

<p>To solve this issue, Basic MPP (multi-path payments) was proposed. Basic MPPs use the same <code>payment_hash</code> 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.</p>

<hr>

<h2>Implementation</h2>

<p>A new type-length-value (TLV) format <a href="https://github.com/lightningnetwork/lightning-rfc/pull/619" rel="noreferrer">is now being followed</a> 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 <code>global_features</code> flag, bits 8/9 (<code>var_onion_optin</code>). Moreover, the lightning invoice generated needs to set the <code>basic_mpp</code> feature.</p>

<p>Base AMPs uses the same <code>payment_hash</code> for all paths through which the payment will be made. If the final node receives an onion packet which includes a <code>basic_mpp</code> field, then the payment MAY be a "base" AMP. Setting the <code>basic_mpp</code> 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". </p>

<p>Upon receiving an onion with <code>basic_mpp</code>, 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.</p>

<hr>

<h2>Future Releases</h2>

<p>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).</p>

<p>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 <code>secp256k1</code>. 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).</p>

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

CC BY-SA 4.0
2019-07-30T11:40:15.753Z
I like your idea of sharing knowledge in this way and great research. You might want to add link-AMP and how it is basically JIT routing but with a protocol change. In link-AMP Routing nodes forward the onion with and update_add_htlc message that is below the onion value promising to send a different htlc with a student onion on another path. Also it might be nice to emphasize on what was discussed in the last spec meeting and how AMP is currently supposed to evolve. Also naming the obvious downsides (more expensive, slower higher on chain footprint) might be an idea.
Rene Pickhardt
CC BY-SA 4.0
2019-07-31T05:08:01.567Z
@RenePickhardt Thanks! I pinged you in the chat, but then I was brought to the attention that since you weren't there in the room for 24 hours, my message wouldn't send you a notification. So, I liked the idea of including the disadvantages of MPP, and including the last spec meeting details. However, I did not find anything related to link-AMP with a google search also, is there any other proposal on MPP apart from the high AMP?
Ugam Kamat
CC BY-SA 4.0
2019-12-17T16:31:48.517Z
So the original AMP from Osuntokun-Fromknetch was abandoned and now we'll have Basic MPP and wait for Taproot for other forms of high AMP?
fiatjaf
CC BY-SA 4.0
2019-12-17T17:05:17.350Z
@fiatjaf I'm unsure if the OG AMP is abandoned. Probably LND will implement it more as a feature in the software rather than consensus that works across implementations. For High AMP, you will have to wait for Taproot softforks, as it is works on Point Locked Time Locked contracts (PTLCs) which cannot be settled on-chain right now.
Ugam Kamat
CC BY-SA 4.0
2019-07-30T11:12:52.417Z
2019-07-30T11:20:35.733Z
2019-07-30T11:20:35.733Z
Ugam Kamat
<p>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?</p>

<lightning-network><lightning-routing><lightning-rfc><atomic-multi-path-payments>
What are atomic multi path payments (AMPs) and why/how is it being implemented in Lightning Network?
Ugam Kamat
# What are atomic multi path payments (AMPs) and why/how is it being implemented in Lightning Network?

(Asked by: username_0 on 2019-07-30)

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?

**Tags:** lightning-network, lightning-routing, lightning-rfc, atomic-multi-path-payments


---

## 1 answers

### Answer by username_0 on 2019-07-30. Score: 5 | Accepted answer

## 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 232 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](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html) (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](https://github.com/lightningnetwork/lightning-rfc/pull/619) 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.

> **Comments:**
> **username_1**: I like your idea of sharing knowledge in this way and great research. You might want to add link-AMP and how it is basically JIT routing but with a protocol change. In link-AMP Routing nodes forward the onion with and update_add_htlc message that is below the onion value promising to send a different htlc with a student onion on another path. Also it might be nice to emphasize on what was discussed in the last spec meeting and how AMP is currently supposed to evolve. Also naming the obvious downsides (more expensive, slower higher on chain footprint) might be an idea.  
> **username_0**: @username_1 Thanks! I pinged you in the chat, but then I was brought to the attention that since you weren't there in the room for 24 hours, my message wouldn't send you a notification. So, I liked the idea of including the disadvantages of MPP, and including the last spec meeting details. However, I did not find anything related to link-AMP with a google search also, is there any other proposal on MPP apart from the high AMP?  
> **username_2**: So the original AMP from Osuntokun-Fromknetch was abandoned and now we'll have Basic MPP and wait for Taproot for other forms of high AMP?  
> **username_0**: @username_2 I'm unsure if the OG AMP is abandoned. Probably LND will implement it more as a feature in the software rather than consensus that works across implementations. For High AMP, you will have to wait for Taproot softforks, as it is works on Point Locked Time Locked contracts (PTLCs) which cannot be settled on-chain right now.  

---

