<p>The wrong assumption is that <code>G</code> needs to collaborate with <code>C</code> to get the refund for routing the payment.</p>
<p>After step 4 in the situation described in the question, <code>G</code> tries to settle the HTLC with <code>C</code>, claiming that he paid to <code>E</code> and showing the preimage as proof of payment. If <code>C</code> doesn't cooperate I guess <code>G</code> can unilaterally close the channel and claim the funds on-chain.</p>
<p>The latest valid transaction <code>G</code> has the following outputs:</p>
<pre><code>+------------+
| funding tx |
+------------+
      |
      |        +-------------+
      \--------| commit tx G |
               +-------------+
                  |  |  |  
                  |  |  | C's main output
                  |  |  \------------------ to C
                  |  |
                  |  |
                  |  |                  ,-- to G (&amp; delay)
                  |  | G's main output /
                  |  \----------------&lt;
                  |                    \ 
                  |                     `-- to C (&amp; revocation key)
                  |  
                  |                   
                  |                                                   ,-- to G (&amp; delay)
                  |                           +-----------------+    /
                  |                        ,--| HTLC-success tx |---&lt;
                  | HTLC received by G    /   +-----------------+    \
                  \----------------------&lt;     (w/ payment preimage)  `-- to C (&amp; revocation key)
                                          \
                                           `-- to C (after timeout)
                                           \
                                            `- to C (&amp; revocation key)
</code></pre>
<p>Credits to the original ASCII <a href="https://github.com/lightning/bolts/issues/553#issuecomment-455641943" rel="nofollow noreferrer">graph</a></p>
<p>With the preimage and before the <code>OP_CHECK_LOCK_TIME_VERIFY</code> becomes valid, <code>G</code> can spend the HTLC output and claim the funds after the delay. <code>C</code> cannot do anything to prevent <code>G</code> from doing this.
The HTLC in the latest transaction is actually a promise that <code>C</code> will reimburse <code>G</code> if he can provide the preimage, whether <code>C</code> cooperates or not.</p>

CC BY-SA 4.0
2023-06-13T09:07:05.980Z
It is important to stress that `E` must not release the preimage unless all parts for the full amount have arrived. In that case even if `C` had already claimed their HTLC with `B` and `F`(for example because `C` had learnt it from `D`) `C` will not be able to withheld funds from `G` as described in your answer. Luckily `E` is incentiviced to release the preimage only after enough incoming HTLCs were locked in
Rene Pickhardt
CC BY-SA 4.0
2023-06-13T08:30:17.933Z
2023-06-13T13:37:18.273Z
2023-06-13T13:37:18.273Z
Lagrang3
<p>Imagine the following graph in the Lightning Network:</p>
<pre><code>  B   D
 / \ / \ 
A   C   E
 \ / \ /
  F   G
</code></pre>
<p>and node <code>A</code> wants to pay node <code>E</code>.
<code>A</code> chooses to pay with multi-path-payment composed of the routes: <code>A-&gt;B-&gt;C-&gt;D-&gt;E</code>
and <code>A-&gt;F-&gt;C-&gt;G-&gt;E</code>.</p>
<p>According to the BOLT4 in a basic MPP all parts use the same payment hash and payee releases the preimage once a set of HTLC arrive to destination ensuring that the total amount is fulfilled. The atomicity is then guaranteed by the economic incentive of the payee.
However, I don't see how this mechanism prevents the steal of funds when the different routes of the same payment have a common routing node like in the example above.
The issue lies in the fact that the same preimage releases the funds on all parts HTLCs.</p>
<p>My thought experiment is as follows:</p>
<ol>
<li><p><code>A</code> constructs a 2 route MPP to pay <code>E</code>, these are
<code>A-&gt;B-&gt;C-&gt;D-&gt;E</code> and <code>A-&gt;F-&gt;C-&gt;G-&gt;E</code>.</p>
</li>
<li><p><code>E</code> receives two HTLCs from <code>D</code> and <code>G</code> that add up to the payment amount, and then releases the preimage to <code>D</code> and <code>G</code> to settle these.</p>
</li>
<li><p><code>C</code> receives the preimage from <code>D</code> and settles the HTLC in the channel <code>C--D</code>.</p>
</li>
<li><p>at this point <code>C</code> can show the preimage to <code>B</code> and <code>F</code> as proof of payment forwarding, but he doesn't need to settle the HTLC with <code>G</code>. He will wait until the timelock expires, thus effectively stealing funds from <code>G</code>.</p>
</li>
</ol>
<p>I'm sure there must be something wrong with this reasoning.
I cannot see how the cryptographic guarantees that apply to single route payments solve this situation as well. And my fear is that MPP can only be performed securely only for disjoint routes.</p>
<p><a href="https://bitcoin.stackexchange.com/questions/89475/what-are-atomic-multi-path-payments-amps-and-why-how-is-it-being-implemented-i/89476#89476">This</a> 3 year old post describes another kind of multi-part-payment called AMP (atomic multi-path), in which each route uses a different payment hash and thus the problem described above doesn't apply, with the drawback that the preimage is known to the sender in advanced and thus cannot be used as a proof of payment.</p>
<p>Coming back to the question:
What prevents <code>C</code> from stealing <code>G</code>'s funds in a basic MPP payment?</p>

<script><lightning-routing><atomic-multi-path-payments>
What cryptographic guarantees apply to non-disjoint paths in basic MPP?
Lagrang3
# What cryptographic guarantees apply to non-disjoint paths in basic MPP?

(Asked by: username_0 on 2023-06-13)

Imagine the following graph in the Lightning Network:

```
  B   D
 / \ / \ 
A   C   E
 \ / \ /
  F   G

```

and node `A` wants to pay node `E`.
`A` chooses to pay with multi-path-payment composed of the routes: `A->B->C->D->E`
and `A->F->C->G->E`.

According to the BOLT4 in a basic MPP all parts use the same payment hash and payee releases the preimage once a set of HTLC arrive to destination ensuring that the total amount is fulfilled. The atomicity is then guaranteed by the economic incentive of the payee.
However, I don't see how this mechanism prevents the steal of funds when the different routes of the same payment have a common routing node like in the example above.
The issue lies in the fact that the same preimage releases the funds on all parts HTLCs.

My thought experiment is as follows:

1. `A` constructs a 2 route MPP to pay `E`, these are
   `A->B->C->D->E` and `A->F->C->G->E`.
2. `E` receives two HTLCs from `D` and `G` that add up to the payment amount, and then releases the preimage to `D` and `G` to settle these.
3. `C` receives the preimage from `D` and settles the HTLC in the channel `C--D`.
4. at this point `C` can show the preimage to `B` and `F` as proof of payment forwarding, but he doesn't need to settle the HTLC with `G`. He will wait until the timelock expires, thus effectively stealing funds from `G`.

I'm sure there must be something wrong with this reasoning.
I cannot see how the cryptographic guarantees that apply to single route payments solve this situation as well. And my fear is that MPP can only be performed securely only for disjoint routes.

[This](https://bitcoin.stackexchange.com/questions/89475/what-are-atomic-multi-path-payments-amps-and-why-how-is-it-being-implemented-i/89476#89476) 3 year old post describes another kind of multi-part-payment called AMP (atomic multi-path), in which each route uses a different payment hash and thus the problem described above doesn't apply, with the drawback that the preimage is known to the sender in advanced and thus cannot be used as a proof of payment.

Coming back to the question:
What prevents `C` from stealing `G`'s funds in a basic MPP payment?

**Tags:** script, lightning-routing, atomic-multi-path-payments


---

## 1 answers

### Answer by username_0 on 2023-06-13. Score: 2 | Accepted answer

The wrong assumption is that `G` needs to collaborate with `C` to get the refund for routing the payment.

After step 4 in the situation described in the question, `G` tries to settle the HTLC with `C`, claiming that he paid to `E` and showing the preimage as proof of payment. If `C` doesn't cooperate I guess `G` can unilaterally close the channel and claim the funds on-chain.

The latest valid transaction `G` has the following outputs:

```
+------------+
| funding tx |
+------------+
      |
      |        +-------------+
      \--------| commit tx G |
               +-------------+
                  |  |  |  
                  |  |  | C's main output
                  |  |  \------------------ to C
                  |  |
                  |  |
                  |  |                  ,-- to G (& delay)
                  |  | G's main output /
                  |  \----------------<
                  |                    \ 
                  |                     `-- to C (& revocation key)
                  |  
                  |                   
                  |                                                   ,-- to G (& delay)
                  |                           +-----------------+    /
                  |                        ,--| HTLC-success tx |---<
                  | HTLC received by G    /   +-----------------+    \
                  \----------------------<     (w/ payment preimage)  `-- to C (& revocation key)
                                          \
                                           `-- to C (after timeout)
                                           \
                                            `- to C (& revocation key)

```

Credits to the original ASCII [graph](https://github.com/lightning/bolts/issues/553#issuecomment-455641943)

With the preimage and before the `OP_CHECK_LOCK_TIME_VERIFY` becomes valid, `G` can spend the HTLC output and claim the funds after the delay. `C` cannot do anything to prevent `G` from doing this.
The HTLC in the latest transaction is actually a promise that `C` will reimburse `G` if he can provide the preimage, whether `C` cooperates or not.

> **Comments:**
> **username_1**: It is important to stress that `E` must not release the preimage unless all parts for the full amount have arrived. In that case even if `C` had already claimed their HTLC with `B` and `F`(for example because `C` had learnt it from `D`) `C` will not be able to withheld funds from `G` as described in your answer. Luckily `E` is incentiviced to release the preimage only after enough incoming HTLCs were locked in  

---

