ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-26 📝 Original message: Good morning Johan, I ...
📅 Original date posted:2018-11-26
📝 Original message:
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 <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>;
📝 Original message:
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 <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>;