Conner Fromknecht [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-13 📝 Original message: Good morning all, > MUST ...
📅 Original date posted:2018-11-13
📝 Original message:
Good morning all,
> MUST NOT forward (if an intermediate node) or claim (if the final node) unless
> it has received a total greater or equal to `intended_total_payment` in all
> incoming HTLCs for the same `payment_hash`.
I was under the impression that this would not require changes on behalf of the
intermediaries, and only need to be implemented by the sender and receiver?
If not, then nodes would need to advertise that they support this so that the
sender can be sure to route through the subset of nodes that support it.
Either way, it would seem that this constraint can only be accurately enforced
by the receiver. If any partial payments fail, then the `intended_total_payment`
through an intermediary may never arise and the payment would be held. This
would also seem to exclude the possibility of iterative path finding, since the
entire payment flow must be known up front during onion packet construction.
Seems the proposal still works without the intermediaries needing to know this?
We may want to add that the receiver:
* SHOULD fail the payment if `intended_total_payment` is less than the invoice
amount
> I'm wondering, since these payments are no longer atomic, should we name it
> accordingly?
Indeed this true. Perhaps NAMP or CPHR (Concurrent Payment Hash Re-use) are more
accurate and may avoid confusion?
Cheers,
Conner
On Tue, Nov 13, 2018 at 8:33 AM Johan Torås Halseth <johanth at gmail.com> wrote:
>
> Good evening Z and list,
>
> I'm wondering, since these payments are no longer atomic, should we name it accordingly?
>
> Cheers,
> Johan
>
> On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>
>> Good morning list,
>>
>> I propose the below to support Base AMP.
>>
>> The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits.
>>
>> ### The `multipath_merge_per_hop` type (`option_base_amp`)
>>
>> This indicates that payment has been split by the sender using Base AMP, and that the receiver should wait for the total intended payment before forwarding or claiming the payment.
>> In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits.
>>
>> 1. type: 1 (`termination_per_hop`)
>> 2. data:
>> * [`8` : `short_channel_id`]
>> * [`8` : `amt_to_forward`]
>> * [`4` : `outgoing_cltv_value`]
>> * [`8` : `intended_total_payment`]
>> * [`4` : `zeros`]
>>
>> The contents of this hop will be the same across all paths of the Base AMP.
>> The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.
>>
>> `intended_total_payment` is the total amount of money that this node should expect to receive in all incoming paths to the same `payment_hash`.
>>
>> This may be the last hop of a payment onion, in which case the `HMAC` for this hop will be `0` (the same rule as for `per_hop_type` 0).
>>
>> The receiver:
>>
>> * MUST impose a reasonable timeout for waiting to receive all component paths, and fail all incoming HTLC offers for the `payment_hash` if they have not totalled equal to `intended_total_payment`.
>> * MUST NOT forward (if an intermediate node) or claim (if the final node) unless it has received a total greater or equal to `intended_total_payment` in all incoming HTLCs for the same `payment_hash`.
>>
>> The sender:
>>
>> * MUST use the same `payment_hash` for all paths of a single multipath payment.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
Good morning all,
> MUST NOT forward (if an intermediate node) or claim (if the final node) unless
> it has received a total greater or equal to `intended_total_payment` in all
> incoming HTLCs for the same `payment_hash`.
I was under the impression that this would not require changes on behalf of the
intermediaries, and only need to be implemented by the sender and receiver?
If not, then nodes would need to advertise that they support this so that the
sender can be sure to route through the subset of nodes that support it.
Either way, it would seem that this constraint can only be accurately enforced
by the receiver. If any partial payments fail, then the `intended_total_payment`
through an intermediary may never arise and the payment would be held. This
would also seem to exclude the possibility of iterative path finding, since the
entire payment flow must be known up front during onion packet construction.
Seems the proposal still works without the intermediaries needing to know this?
We may want to add that the receiver:
* SHOULD fail the payment if `intended_total_payment` is less than the invoice
amount
> I'm wondering, since these payments are no longer atomic, should we name it
> accordingly?
Indeed this true. Perhaps NAMP or CPHR (Concurrent Payment Hash Re-use) are more
accurate and may avoid confusion?
Cheers,
Conner
On Tue, Nov 13, 2018 at 8:33 AM Johan Torås Halseth <johanth at gmail.com> wrote:
>
> Good evening Z and list,
>
> I'm wondering, since these payments are no longer atomic, should we name it accordingly?
>
> Cheers,
> Johan
>
> On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>
>> Good morning list,
>>
>> I propose the below to support Base AMP.
>>
>> The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits.
>>
>> ### The `multipath_merge_per_hop` type (`option_base_amp`)
>>
>> This indicates that payment has been split by the sender using Base AMP, and that the receiver should wait for the total intended payment before forwarding or claiming the payment.
>> In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits.
>>
>> 1. type: 1 (`termination_per_hop`)
>> 2. data:
>> * [`8` : `short_channel_id`]
>> * [`8` : `amt_to_forward`]
>> * [`4` : `outgoing_cltv_value`]
>> * [`8` : `intended_total_payment`]
>> * [`4` : `zeros`]
>>
>> The contents of this hop will be the same across all paths of the Base AMP.
>> The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.
>>
>> `intended_total_payment` is the total amount of money that this node should expect to receive in all incoming paths to the same `payment_hash`.
>>
>> This may be the last hop of a payment onion, in which case the `HMAC` for this hop will be `0` (the same rule as for `per_hop_type` 0).
>>
>> The receiver:
>>
>> * MUST impose a reasonable timeout for waiting to receive all component paths, and fail all incoming HTLC offers for the `payment_hash` if they have not totalled equal to `intended_total_payment`.
>> * MUST NOT forward (if an intermediate node) or claim (if the final node) unless it has received a total greater or equal to `intended_total_payment` in all incoming HTLCs for the same `payment_hash`.
>>
>> The sender:
>>
>> * MUST use the same `payment_hash` for all paths of a single multipath payment.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev