<div dir="auto"><div dir="auto"><span style="font-family:sans-serif">(excuse me for not yet understanding what this extra complexity gives us)</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">To summarize: My suggestion was to only add an optional field to the invoice, and let the recepient wait until all funds have received before pulling the payment. No changes to the onion.</span><br></div><div dir="auto"><br></div>We briefly discussed this during the last call, that the extra bit set in the onion will be necessary to support Partial Payments (PP?) in the spontaneous payments case. <div dir="auto"><br></div><div dir="auto">However, as we don&#39;t yet have spontaneous payments specced out, wouldn&#39;t this be something to be added at that point?<div dir="auto"><br></div><div dir="auto">I just feel not adding the extra bit to the onion would make the implementation of PP near trivial, and still don&#39;t see the downsides of not adding it.</div><div dir="auto"><br></div><div dir="auto">Cheers, Johan</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 26, 2018, 09:10 ZmnSCPxj &lt;<a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Good morning Johan,<br></div><div><br></div><div>I believe what Rusty refers to here is a probe by an intermediate node, rather than a probe by the source node (who, as we know, already knows whether the payee supports AMP or not, by the invoice).<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></div><div class="m_1978204918174468473protonmail_signature_block"><div class="m_1978204918174468473protonmail_signature_block-user m_1978204918174468473protonmail_signature_block-empty"><br></div><div class="m_1978204918174468473protonmail_signature_block-proton">Sent with <a href="https://protonmail.com" target="_blank" rel="noreferrer">ProtonMail</a> Secure Email.<br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Monday, November 26, 2018 3:58 PM, Johan Torås Halseth &lt;<a href="mailto:johanth@gmail.com" target="_blank" rel="noreferrer">johanth@gmail.com</a>&gt; wrote:<br></div><div> <br></div><blockquote type="cite" class="m_1978204918174468473protonmail_quote"><div dir="ltr"><div>This shouldn&#39;t be problem, as the invoice will already indicate that the node supports BaseAMP. If you have a reason to not reveal that you support BAMP for certain invoices, you&#39;ll just not specify it in the invoice, and act non-BAMPy when receiving payments to this payment hash.<br></div><div><br></div><div>Of course, this will also be opt-in for both sides and won&#39;t affect existing nodes in any way.<br></div><div><br></div><div>Cheers,<br></div><div><div>Johan<br></div><div><div><br></div><div class="gmail_quote"><div dir="ltr">On Wed, Nov 21, 2018 at 11:54 PM Rusty Russell &lt;<a href="mailto:rusty@rustcorp.com.au" target="_blank" rel="noreferrer">rusty@rustcorp.com.au</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Johan Torås Halseth &lt;<a href="mailto:johanth@gmail.com" target="_blank" rel="noreferrer">johanth@gmail.com</a>&gt; writes:<br></div><div> &gt; Seems like we can restrict the changes to BOLT11 by having the receiver<br></div><div> &gt; assume NAMP for incoming payments &lt; invoice_amount. (with some timeout of<br></div><div> &gt; course, but that would need to be the case even when the sender is<br></div><div> &gt; signalling NAMP).<br></div><div> <br></div><div> This would effectively become a probe for Base AMP; if you get a partial<br></div><div> payment error, it&#39;s because the recipient didn&#39;t support Base AMP.<br></div><div> <br></div><div> Seems cleaner to have a flag, both on BOLT11 and inside the onion.  Then<br></div><div> it&#39;s explicitly opt-in for both sides and doesn&#39;t affect existing nodes<br></div><div> in any way.<br></div><div> <br></div><div> Cheers,<br></div><div> Rusty.<br></div></blockquote></div></div></div></div></blockquote><div><br></div></blockquote></div>