Skip to content

Commit 5c8ee67

Browse files
committed
Add high AMP to multi-hop-locks writeup
1 parent 65dd354 commit 5c8ee67

File tree

1 file changed

+8
-0
lines changed

1 file changed

+8
-0
lines changed

md/multi-hop-locks.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -95,6 +95,14 @@ With scriptless script multi-hop locks it is possible to do AMP in a similarly t
9595
The payer sets up multiple routes to the payee using uncorrelated locks such that any partial payment claimed by the payee reveals the proof of payment (`z`) to the payer.
9696
Because the payee doesn't want to give up the PoP for just a partial payment, she waits until all routes to her are fully established and claims the all partial payments at once.
9797

98+
It's also possible to set up multiple paths such that the receiver's payment preimage is only revealed once all paths are established, similar to [*base AMP*](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html) (also known as *low AMP*).
99+
The difference is that in the multi-hop-locks world we can keep the proof of payment.
100+
This is referred to as [*high AMP*](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001494.html).
101+
102+
In high AMP the sender first draws a random number `q` and determines random `q1, ... qn` where `n` is the number of paths such that `q = q0 + ... qn`.
103+
The sender adds `q*G` to the receiver's payment point on every path, who is therefore unable to claim any payment because the receiver is not aware of `q`.
104+
However, when setting up each path `i` the sender sent `qi` along to the receiver.
105+
As soon as all paths are established, the receiver can compute `q` and claim the payments.
98106

99107
Resources
100108
---

0 commit comments

Comments
 (0)