[Lightning-dev] Base AMP

Conner Fromknecht conner at lightning.engineering
Wed Nov 21 23:38:20 UTC 2018

Hi all,

> But it's unnecessary for the recipient to know the total amount I meant
> to pay; they just need to return the receipt once it exceeds the amount
> they want.

I think it’s true that the recipient doesn’t need to know necessarily, but
sending the intended amount is more robust IMO, since it provides an order
invariant hint for when the receiver can safely settle.

If the sender does amount fuzzing (as CL does) or adds a tip, it’s possible
for the final partial payment to be less than `amount_to_pay` -
`invoice_amount`, causing the sender to settle prematurely. Otherwise, we
might want to specify that no split should be less than the amount

Of course, if that amount never comes through yet the invoice is satisfied,
the receiver can always choose to settle even if the remaining amount never


On Wed, Nov 21, 2018 at 14:55 Rusty Russell <rusty at rustcorp.com.au> wrote:

> Johan Torås Halseth <johanth at gmail.com> writes:
> > Seems like we can restrict the changes to BOLT11 by having the receiver
> > assume NAMP for incoming payments < invoice_amount. (with some timeout of
> > course, but that would need to be the case even when the sender is
> > signalling NAMP).
> This would effectively become a probe for Base AMP; if you get a partial
> payment error, it's because the recipient didn't support Base AMP.
> Seems cleaner to have a flag, both on BOLT11 and inside the onion.  Then
> it's explicitly opt-in for both sides and doesn't affect existing nodes
> in any way.
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
—Sent from my Spaceship
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/afe803d2/attachment.html>

More information about the Lightning-dev mailing list