Nadav Kohen [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-02 📝 Original message: Hi list, Like most people ...
📅 Original date posted:2019-10-02
📝 Original message:
Hi list,
Like most people I am super excited for AMPs to hit the lightning network!
(For the remainder of this post when I say AMP I mean OG AMP (
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html)
since that is the one I know)
It is my understanding however that it is not possible to do AMPs with
Proof of Payment (PoP). This is because the payment pre-images must be
fully known to the payer since they must compute a hash of each payment
pre-image. And if the payer must know the pre-image in advance then there
is nothing for them to learn atomically with payment completion.
This makes me sad because PoP is really important for many applications
and any application that uses PoP will not be AMP compatible.
Queue Payment Points to the rescue! Once the lightning network moves to
support Payment Points and PTLCs instead of Payment Hashes with their
HTLCs, OG AMP can be modified in the following simple way in order to allow
for PoP-enabled AMPs:
Let PP = pop*G be the payment point (e.g. in an invoice) where pop is
known to the receiver.
Like in the original proposal, let V be the total amount with pieces
v_1 through v_n.
Like in the original proposal, let BS = s_1 ^ ... ^ s_n (where I use BS
= Base Secret)
Like in the original proposal, let r_i = H(BS || i), but this will not
be our pre-image.
Instead, let the payment point for partial payment i be: P_i = r_i*G +
PP
This makes each payment scalar (as opposed to pre-image) r_i + pop
The rest is the same as OG AMP: Use the triple (ID, v_i, s_i) in each
payment's EOB
This allows the receiver to add pop to each r_i which is required to
complete each payment.
*TLDR*: Have a Payment Point, PP = pop*G, and add it to each partial
payment point!
Once we have Payment Points I propose that this be how AMPs work (and
simply set PP = 0 in the case of spontaneous AMPs). This will allow AMPs to
enjoy all of the awesome things that come with PoP!
If it is true, as I believe it to be, that it is not possible to have PoP
in AMPs without Payment Points, then I find this to be (yet another) really
compelling reason to move to Payment Points as soon as we can (likely when
bip-schnorr enters base layer I believe?).
All feedback is welcome.
Best,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191002/accb329a/attachment.html>;
📝 Original message:
Hi list,
Like most people I am super excited for AMPs to hit the lightning network!
(For the remainder of this post when I say AMP I mean OG AMP (
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html)
since that is the one I know)
It is my understanding however that it is not possible to do AMPs with
Proof of Payment (PoP). This is because the payment pre-images must be
fully known to the payer since they must compute a hash of each payment
pre-image. And if the payer must know the pre-image in advance then there
is nothing for them to learn atomically with payment completion.
This makes me sad because PoP is really important for many applications
and any application that uses PoP will not be AMP compatible.
Queue Payment Points to the rescue! Once the lightning network moves to
support Payment Points and PTLCs instead of Payment Hashes with their
HTLCs, OG AMP can be modified in the following simple way in order to allow
for PoP-enabled AMPs:
Let PP = pop*G be the payment point (e.g. in an invoice) where pop is
known to the receiver.
Like in the original proposal, let V be the total amount with pieces
v_1 through v_n.
Like in the original proposal, let BS = s_1 ^ ... ^ s_n (where I use BS
= Base Secret)
Like in the original proposal, let r_i = H(BS || i), but this will not
be our pre-image.
Instead, let the payment point for partial payment i be: P_i = r_i*G +
PP
This makes each payment scalar (as opposed to pre-image) r_i + pop
The rest is the same as OG AMP: Use the triple (ID, v_i, s_i) in each
payment's EOB
This allows the receiver to add pop to each r_i which is required to
complete each payment.
*TLDR*: Have a Payment Point, PP = pop*G, and add it to each partial
payment point!
Once we have Payment Points I propose that this be how AMPs work (and
simply set PP = 0 in the case of spontaneous AMPs). This will allow AMPs to
enjoy all of the awesome things that come with PoP!
If it is true, as I believe it to be, that it is not possible to have PoP
in AMPs without Payment Points, then I find this to be (yet another) really
compelling reason to move to Payment Points as soon as we can (likely when
bip-schnorr enters base layer I believe?).
All feedback is welcome.
Best,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191002/accb329a/attachment.html>;