Oh darn! My bad for posting so fast, I should have looked around more :P
Thanks for the info! And agreed, it would be awesome to have even if just as a proof of concept. Best, Nadav On Wed, Oct 2, 2019 at 6:48 PM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > 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 > > >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
