<p>As far as I know It can and did happen.</p>
<p>On a protocol level, 2 separate nodes (or the same node) can construct two different (or the same) onions and initiate the routing process.</p>
<p>On a protocol level I am not aware of any mechanics to prevent two htlcs on the same channel with the same payment hash, and on different channels, this is obviously not encoded to the protocol. In particular, while there might be a rule that the recipient SHOULD NOT release the preimage more than once, I don't see any way to detect or prevent such a behavior without drastic protocol changes.</p>
<p>The situation becomes worse once we implement base AMP in which a recipient node expects several htlcs anyway and overpayment is also part of the expected protocol behavior.</p>
<p>A little off topic: AMP also allows a denial of service attack vector by just denying the second onion with the same payment hash to be forwarded.</p>

CC BY-SA 4.0
2019-05-13T11:06:00.943Z
2022-09-01T18:47:27.423Z
2022-09-01T18:47:27.423Z
Rene Pickhardt
<p>If multiple Lightning nodes attempt to pay the same invoice (using the same payment request), is it absolutely necessary that no more than <em>one</em> of the attempts will succeed (that is, only one payer will learn the preimage)?</p>

<p>I'd expect that clients <em>try</em> to not make multiple payments happen. What I'm willing to learn is whether it's actually <em>impossible</em> by protocol design.</p>

<lightning-network>
Can two parties accidentally pay the same lightning network invoice simultaneously?
Anton Kovalenko
# Can two parties accidentally pay the same lightning network invoice simultaneously?

(Asked by: username_0 on 2019-05-13)

If multiple Lightning nodes attempt to pay the same invoice (using the same payment request), is it absolutely necessary that no more than *one* of the attempts will succeed (that is, only one payer will learn the preimage)?

I'd expect that clients *try* to not make multiple payments happen. What I'm willing to learn is whether it's actually *impossible* by protocol design.

**Tags:** lightning-network


---

## 1 answers

### Answer by username_1 on 2019-05-13. Score: 5 | Accepted answer

As far as I know It can and did happen.

On a protocol level, 2 separate nodes (or the same node) can construct two different (or the same) onions and initiate the routing process.

On a protocol level I am not aware of any mechanics to prevent two htlcs on the same channel with the same payment hash, and on different channels, this is obviously not encoded to the protocol. In particular, while there might be a rule that the recipient SHOULD NOT release the preimage more than once, I don't see any way to detect or prevent such a behavior without drastic protocol changes.

The situation becomes worse once we implement base AMP in which a recipient node expects several htlcs anyway and overpayment is also part of the expected protocol behavior.

A little off topic: AMP also allows a denial of service attack vector by just denying the second onion with the same payment hash to be forwarded.


---

