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.
📝 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.