[Lightning-dev] Proposal: AMPs With Proof of Payment

[ZmnSCPxj]

Good morning Nadav,

Yes, this is possible.

https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001100.html

This is called as "High" AMP to contrast with OG and Base, and was discussed in Adelaide 2018.
At Adelaide 2018 only path decorrelation and High AMP were the known advantages of payment point/scalar, thus the decision to wait for Schnorr-like signatures to hit the base layer rather than implement 2p-ECDSA.

The possibility of Stuckless (which potentially allows Escrow-over-Lightning as well) gives additional boost to the use of payment points.
Since bip-schnorr probably will have 1 year of arguing, 1 year of testing+ developing, and 2 years of miners delaying activation before another UASF, I am currently tempted to consider implementing 2p-ECDSA already.

Regards,
ZmnSCPxj


>
> 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