Johan Torås Halseth [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-27 📝 Original message: (excuse me for not yet ...
📅 Original date posted:2018-11-27
📝 Original message:
(excuse me for not yet understanding what this extra complexity gives us)
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.
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.
However, as we don't yet have spontaneous payments specced out, wouldn't
this be something to be added at that point?
I just feel not adding the extra bit to the onion would make the
implementation of PP near trivial, and still don't see the downsides of not
adding it.
Cheers, Johan
On Mon, Nov 26, 2018, 09:10 ZmnSCPxj <ZmnSCPxj at protonmail.com wrote:
> 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/20181127/760d330d/attachment-0001.html>;
📝 Original message:
(excuse me for not yet understanding what this extra complexity gives us)
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.
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.
However, as we don't yet have spontaneous payments specced out, wouldn't
this be something to be added at that point?
I just feel not adding the extra bit to the onion would make the
implementation of PP near trivial, and still don't see the downsides of not
adding it.
Cheers, Johan
On Mon, Nov 26, 2018, 09:10 ZmnSCPxj <ZmnSCPxj at protonmail.com wrote:
> 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/20181127/760d330d/attachment-0001.html>;