Conner Fromknecht [ARCHIVE] on Nostr: đź“… Original date posted:2018-11-21 đź“ť Original message: Hi all, > But it's ...
đź“… Original date posted:2018-11-21
đź“ť Original message:
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
overpaid.
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
arrives.
Cheers,
Conner
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>;
đź“ť Original message:
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
overpaid.
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
arrives.
Cheers,
Conner
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>;