Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-22 📝 Original message: Conner Fromknecht <conner ...
📅 Original date posted:2018-11-22
📝 Original message:
Conner Fromknecht <conner at lightning.engineering> writes:
> 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.
It's more code, and takes 8 more bytes out of the onion. I've started
coding up option_simplfied_commitment and it's making me terrified of
adding any additional complexity :(
The more compelling argument is that partial-payment donations might
want this, but it's marginal, IMHO. We should be aiming for static
invoices for the donate case.
Cheers,
Rusty.
Published at
2023-06-09 12:52:46Event JSON
{
"id": "fc4f4cb58c9c21d3455922513a88324ea221b7812ee23a7a2c943ebd4cba3ff5",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315166,
"kind": 1,
"tags": [
[
"e",
"809f1a75998ec1e3eebcb7a31f0cc9fe5473d678fb16cc9dfe25f3232ec33478",
"",
"root"
],
[
"e",
"dfe275de8acc62e19d07c6bf10dfc527d407b8e46ce497a91d3d5429a034f9f1",
"",
"reply"
],
[
"p",
"175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246"
]
],
"content": "📅 Original date posted:2018-11-22\n📝 Original message:\nConner Fromknecht \u003cconner at lightning.engineering\u003e writes:\n\u003e Hi all,\n\u003e\n\u003e\u003e But it's unnecessary for the recipient to know the total amount I meant\n\u003e\u003e to pay; they just need to return the receipt once it exceeds the amount\n\u003e\u003e they want.\n\u003e\n\u003e I think it’s true that the recipient doesn’t need to know necessarily, but\n\u003e sending the intended amount is more robust IMO, since it provides an order\n\u003e invariant hint for when the receiver can safely settle.\n\u003e\n\u003e If the sender does amount fuzzing (as CL does) or adds a tip, it’s possible\n\u003e for the final partial payment to be less than `amount_to_pay` -\n\u003e `invoice_amount`, causing the sender to settle prematurely. Otherwise, we\n\u003e might want to specify that no split should be less than the amount\n\u003e overpaid.\n\u003e\n\u003e Of course, if that amount never comes through yet the invoice is satisfied,\n\u003e the receiver can always choose to settle even if the remaining amount never\n\u003e arrives.\n\nIt's more code, and takes 8 more bytes out of the onion. I've started\ncoding up option_simplfied_commitment and it's making me terrified of\nadding any additional complexity :(\n\nThe more compelling argument is that partial-payment donations might\nwant this, but it's marginal, IMHO. We should be aiming for static\ninvoices for the donate case.\n\nCheers,\nRusty.",
"sig": "006e0699f465c38af5094fae6b8d73ac122b882ad2d115553df97a447560f0cb494e3548748ba932ed9aa91e71a502be8bd9e1e3fd30b0a6c775433beab8734e"
}