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).
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, November 26, 2018 3:58 PM, Johan Torås Halseth <[email protected]>
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 <[email protected]> wrote:
>
>> Johan Torås Halseth <[email protected]> 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.
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
