<p>This is not specified by the protocol. Implementations can do what ever pleases them. For example I believe many would use a more or less uniform split into parts given the amount and the number of parts they wish to send.</p>
<p>This form of splitting is discussed in <a href="https://arxiv.org/abs/2103.08576" rel="nofollow noreferrer">this research paper</a> and was <a href="https://arxiv.org/abs/2107.05322" rel="nofollow noreferrer">shown to be not optimal</a>. The previous link also provides the optimal solution by recognizing that payments should be understood as minimum cost flow problems. However even dissecting the resulting payment flow into shards is arbitrary and not well defined. The typical solution is to <a href="https://github.com/renepickhardt/pickhardtpayments/blob/bd7fbc562e4c3298fe854b505b8e223f17caded0/pickhardtpayments/Payment.py#L423" rel="nofollow noreferrer">use a chain of cascading shortest paths as done in this function</a>.</p>
<p>Newer research is in progress that uses augmenting paths which are saturated such that <a href="https://github.com/lightningdevkit/rust-lightning/issues/2276" rel="nofollow noreferrer">the probability of the amount for a part reaches a certain threshold</a>.</p>
<p>Disclaimer: I am the main contributor of all the links provided</p>

CC BY-SA 4.0
2023-06-13T09:01:06.120Z
2023-06-13T09:01:06.120Z
Rene Pickhardt
<p>From the source code of <a href="https://github.com/lightningnetwork/lnd/blob/33a5c306713ec24e19a57c8e28f2e4d158433860/routing/payment_session.go" rel="nofollow noreferrer">LND</a>, payments are split in half and retried if no path for the full amount is found:</p>
<pre><code>func (p *paymentSession) RequestRoute(maxAmt, feeLimit lnwire.MilliSatoshi,
    activeShards, height uint32) (*route.Route, error) {

        ...
        // This is where the magic happens. If we can't find a
        // route, try it for half the amount.
        maxAmt /= 2
        ...
</code></pre>
<p>For normal payments, I understand the algorithm will split the payment until it fits a path, send it, and update the weights in the graph to avoid reusing the same path. Then we can do the same for the remaining amount. This is confirmed in <a href="https://bitcoin.stackexchange.com/a/100720/96871">this answer</a>.</p>
<p>However, for <a href="https://github.com/lnbook/lnbook/blob/develop/12_path_finding.asciidoc#mpp_rounds" rel="nofollow noreferrer">MPP</a>, it seems there is a set of parts per round, which are sent concurrently. If this is the case, how does MPP define the amount of each part before sending the parts?</p>

<lightning-network><lightning-network-daemon><lightning-routing><atomic-multi-path-payments>
How does Lightning multipart payments (MPP) protocol define the amounts per part?
Gabriel Rebello
# How does Lightning multipart payments (MPP) protocol define the amounts per part?

(Asked by: username_0 on 2023-02-28)

From the source code of [LND](https://github.com/lightningnetwork/lnd/blob/33a5c306713ec24e19a57c8e28f2e4d158433860/routing/payment_session.go), payments are split in half and retried if no path for the full amount is found:

```
func (p *paymentSession) RequestRoute(maxAmt, feeLimit lnwire.MilliSatoshi,
    activeShards, height uint32) (*route.Route, error) {

        ...
        // This is where the magic happens. If we can't find a
        // route, try it for half the amount.
        maxAmt /= 2
        ...

```

For normal payments, I understand the algorithm will split the payment until it fits a path, send it, and update the weights in the graph to avoid reusing the same path. Then we can do the same for the remaining amount. This is confirmed in [this answer](https://bitcoin.stackexchange.com/a/100720/96871).

However, for [MPP](https://github.com/lnbook/lnbook/blob/develop/12_path_finding.asciidoc#mpp_rounds), it seems there is a set of parts per round, which are sent concurrently. If this is the case, how does MPP define the amount of each part before sending the parts?

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


---

## 1 answers

### Answer by username_1 on 2023-06-13. Score: 3

This is not specified by the protocol. Implementations can do what ever pleases them. For example I believe many would use a more or less uniform split into parts given the amount and the number of parts they wish to send.

This form of splitting is discussed in [this research paper](https://arxiv.org/abs/2103.08576) and was [shown to be not optimal](https://arxiv.org/abs/2107.05322). The previous link also provides the optimal solution by recognizing that payments should be understood as minimum cost flow problems. However even dissecting the resulting payment flow into shards is arbitrary and not well defined. The typical solution is to [use a chain of cascading shortest paths as done in this function](https://github.com/username_1/pickhardtpayments/blob/bd7fbc562e4c3298fe854b505b8e223f17caded0/pickhardtpayments/Payment.py#L423).

Newer research is in progress that uses augmenting paths which are saturated such that [the probability of the amount for a part reaches a certain threshold](https://github.com/lightningdevkit/rust-lightning/issues/2276).

Disclaimer: I am the main contributor of all the links provided


---

