You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: md/multi-hop-locks.md
+9Lines changed: 9 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -96,6 +96,15 @@ With scriptless script multi-hop locks it is possible to do AMP in a similarly t
96
96
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.
97
97
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.
98
98
99
+
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*).
100
+
The difference is that in the multi-hop-locks world we can keep the proof of payment.
101
+
This is referred to as [*high AMP*](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001494.html).
102
+
103
+
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 = q1 + ... qn`.
104
+
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`.
105
+
However, when setting up each path `i` the sender sent `qi` along to the receiver.
106
+
As soon as all paths are established, the receiver can compute `q` and claim the payments.
0 commit comments