<div dir="ltr">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.<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.</div><div><br></div><div>Cheers,</div><div>Johan<br><div><br><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">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">Johan Torås Halseth &lt;<a href="mailto:johanth@gmail.com" target="_blank">johanth@gmail.com</a>&gt; writes:<br>
&gt; Seems like we can restrict the changes to BOLT11 by having the receiver<br>
&gt; assume NAMP for incoming payments &lt; invoice_amount. (with some timeout of<br>
&gt; course, but that would need to be the case even when the sender is<br>
&gt; signalling NAMP).<br>
<br>
This would effectively become a probe for Base AMP; if you get a partial<br>
payment error, it&#39;s because the recipient didn&#39;t support Base AMP.<br>
<br>
Seems cleaner to have a flag, both on BOLT11 and inside the onion.  Then<br>
it&#39;s explicitly opt-in for both sides and doesn&#39;t affect existing nodes<br>
in any way.<br>
<br>
Cheers,<br>
Rusty.<br>
</blockquote></div></div></div></div>