<div><div dir="auto">Hi all,</div></div><div dir="auto"><br></div><div dir="auto">> <span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">But it's unnecessary for the recipient to know the total amount I meant</span></div><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)"><div dir="auto">> to pay; they just need to return the receipt once it exceeds the amount </div></span><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)"><div dir="auto">> they want. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Conner</div></span><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 21, 2018 at 14:55 Rusty Russell <<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Johan Torås Halseth <<a href="mailto:johanth@gmail.com" target="_blank">johanth@gmail.com</a>> writes:<br>
> Seems like we can restrict the changes to BOLT11 by having the receiver<br>
> assume NAMP for incoming payments < invoice_amount. (with some timeout of<br>
> course, but that would need to be the case even when the sender is<br>
> signalling NAMP).<br>
<br>
This would effectively become a probe for Base AMP; if you get a partial<br>
payment error, it's because the recipient didn't support Base AMP.<br>
<br>
Seems cleaner to have a flag, both on BOLT11 and inside the onion. Then<br>
it's explicitly opt-in for both sides and doesn't affect existing nodes<br>
in any way.<br>
<br>
Cheers,<br>
Rusty.<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">—Sent from my Spaceship</div>