đź“… 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>;
Conner Fromknecht [ARCHIVE] /
npub1za…uua2a
2023-06-09 12:52:46
in reply to nevent1q…52pt
Author Public Key
npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2aPublished at
2023-06-09 12:52:46Event JSON
{
"id": "dfe275de8acc62e19d07c6bf10dfc527d407b8e46ce497a91d3d5429a034f9f1",
"pubkey": "175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246",
"created_at": 1686315166,
"kind": 1,
"tags": [
[
"e",
"809f1a75998ec1e3eebcb7a31f0cc9fe5473d678fb16cc9dfe25f3232ec33478",
"",
"root"
],
[
"e",
"1d53a81d38741a7bffcc2bca96253d43071197ba46d1e5f4adbc5b58a4474465",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-11-21\n📝 Original message:\nHi all,\n\n\u003e But it's unnecessary for the recipient to know the total amount I meant\n\u003e to pay; they just need to return the receipt once it exceeds the amount\n\u003e they want.\n\nI think it’s true that the recipient doesn’t need to know necessarily, but\nsending the intended amount is more robust IMO, since it provides an order\ninvariant hint for when the receiver can safely settle.\n\nIf the sender does amount fuzzing (as CL does) or adds a tip, it’s possible\nfor the final partial payment to be less than `amount_to_pay` -\n`invoice_amount`, causing the sender to settle prematurely. Otherwise, we\nmight want to specify that no split should be less than the amount\noverpaid.\n\nOf course, if that amount never comes through yet the invoice is satisfied,\nthe receiver can always choose to settle even if the remaining amount never\narrives.\n\nCheers,\nConner\n\nOn Wed, Nov 21, 2018 at 14:55 Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Johan Torås Halseth \u003cjohanth at gmail.com\u003e writes:\n\u003e \u003e Seems like we can restrict the changes to BOLT11 by having the receiver\n\u003e \u003e assume NAMP for incoming payments \u003c invoice_amount. (with some timeout of\n\u003e \u003e course, but that would need to be the case even when the sender is\n\u003e \u003e signalling NAMP).\n\u003e\n\u003e This would effectively become a probe for Base AMP; if you get a partial\n\u003e payment error, it's because the recipient didn't support Base AMP.\n\u003e\n\u003e Seems cleaner to have a flag, both on BOLT11 and inside the onion. Then\n\u003e it's explicitly opt-in for both sides and doesn't affect existing nodes\n\u003e in any way.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-- \n—Sent from my Spaceship\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/afe803d2/attachment.html\u003e",
"sig": "cb9ef7fe95da1b5ff57b430201a3aed5d54c5437b62098b268225793511c4b181db569d7f349b00e75b1166c3268e4f7648d46eb4912734df6bf0d33b5890bc0"
}