ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-13 📝 Original message: Good morning Conner, > > ...
📅 Original date posted:2018-11-13
📝 Original message:
Good morning Conner,
> > 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?
Strictly, it needs to be implemented by the sender and any merge points it wants.
We have been thinking in terms of the receiver being the merge point, but it would be possible, with this scheme, for the merge point to be anywhere along the paths to the receiver.
A------>B------->C-------
\ \
----->D------->E------->F-------
\ \
---->G------->H------->I------->J
In the above, the ultimate payee is J, which is a merge point.
F is an intermediate node, but merges two paths together before forwarding.
Other intermediate nodes, B, C, D, E, G, H, and I, are not merge points and do not need to understand this.
Only F and J need to be given some merge point information in the new `per_hop_type`.
B, C, D, E, G, H, and I, will be given `per_hop_type` of 0.
This also means that AMP can be performed without the ultimate payee being AMP-capable, as the below:
A------>B------>C-------
\ \
----->D------>E------->F------>G
Splitting the entire payment needs to be done at the ultimate source always, but merging can be done at any point along the way.
So yes, it would be valuable to advertise the ability to merge payments as a global feature bit, not on the invoice.
Regards,
ZmnSCPxj
> 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 Conner,
> > 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?
Strictly, it needs to be implemented by the sender and any merge points it wants.
We have been thinking in terms of the receiver being the merge point, but it would be possible, with this scheme, for the merge point to be anywhere along the paths to the receiver.
A------>B------->C-------
\ \
----->D------->E------->F-------
\ \
---->G------->H------->I------->J
In the above, the ultimate payee is J, which is a merge point.
F is an intermediate node, but merges two paths together before forwarding.
Other intermediate nodes, B, C, D, E, G, H, and I, are not merge points and do not need to understand this.
Only F and J need to be given some merge point information in the new `per_hop_type`.
B, C, D, E, G, H, and I, will be given `per_hop_type` of 0.
This also means that AMP can be performed without the ultimate payee being AMP-capable, as the below:
A------>B------>C-------
\ \
----->D------>E------->F------>G
Splitting the entire payment needs to be done at the ultimate source always, but merging can be done at any point along the way.
So yes, it would be valuable to advertise the ability to merge payments as a global feature bit, not on the invoice.
Regards,
ZmnSCPxj
> 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