[Lightning-dev] Base AMP

ZmnSCPxj ZmnSCPxj at protonmail.com
Mon Nov 26 08:10:11 UTC 2018

Good morning Johan,

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


Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, November 26, 2018 3:58 PM, Johan Torås Halseth <johanth at gmail.com> wrote:

> This shouldn'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'll just not specify it in the invoice, and act non-BAMPy when receiving payments to this payment hash.
> Of course, this will also be opt-in for both sides and won't affect existing nodes in any way.
> Cheers,
> Johan
> On Wed, Nov 21, 2018 at 11:54 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
>> Johan Torås Halseth <johanth at gmail.com> writes:
>>> Seems like we can restrict the changes to BOLT11 by having the receiver
>>> assume NAMP for incoming payments < invoice_amount. (with some timeout of
>>> course, but that would need to be the case even when the sender is
>>> signalling NAMP).
>> This would effectively become a probe for Base AMP; if you get a partial
>> payment error, it's because the recipient didn't support Base AMP.
>> Seems cleaner to have a flag, both on BOLT11 and inside the onion.  Then
>> it's explicitly opt-in for both sides and doesn't affect existing nodes
>> in any way.
>> Cheers,
>> Rusty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181126/c4f7a7a6/attachment-0001.html>

More information about the Lightning-dev mailing list