{"type":"rich","version":"1.0","title":"ZmnSCPxj [ARCHIVE] wrote","author_name":"ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)","author_url":"https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-11-13\n📝 Original message:\nGood morning Conner,\n\n\u003e \u003e MUST NOT forward (if an intermediate node) or claim (if the final node) unless\n\u003e \u003e it has received a total greater or equal to `intended_total_payment` in all\n\u003e \u003e incoming HTLCs for the same `payment_hash`.\n\u003e\n\u003e I was under the impression that this would not require changes on behalf of the\n\u003e intermediaries, and only need to be implemented by the sender and receiver?\n\nStrictly, it needs to be implemented by the sender and any merge points it wants.\nWe 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.\n\n\nA------\u003eB-------\u003eC-------\n \\                       \\\n  -----\u003eD-------\u003eE-------\u003eF-------\n  \\                               \\\n   ----\u003eG-------\u003eH-------\u003eI-------\u003eJ\n\n\nIn the above, the ultimate payee is J, which is a merge point.\nF is an intermediate node, but merges two paths together before forwarding.\nOther intermediate nodes, B, C, D, E, G, H, and I, are not merge points and do not need to understand this.\nOnly F and J need to be given some merge point information in the new `per_hop_type`.\nB, C, D, E, G, H, and I, will be given `per_hop_type` of 0.\n\nThis also means that AMP can be performed without the ultimate payee being AMP-capable, as the below:\n\nA------\u003eB------\u003eC-------\n \\                      \\\n  -----\u003eD------\u003eE-------\u003eF------\u003eG\n\nSplitting the entire payment needs to be done at the ultimate source always, but merging can be done at any point along the way.\n\n\nSo yes, it would be valuable to advertise the ability to merge payments as a global feature bit, not on the invoice.\n\nRegards,\nZmnSCPxj\n\n\u003e If not, then nodes would need to advertise that they support this so that the\n\u003e sender can be sure to route through the subset of nodes that support it.\n\u003e\n\u003e Either way, it would seem that this constraint can only be accurately enforced\n\u003e by the receiver. If any partial payments fail, then the `intended_total_payment`\n\u003e through an intermediary may never arise and the payment would be held. This\n\u003e would also seem to exclude the possibility of iterative path finding, since the\n\u003e entire payment flow must be known up front during onion packet construction.\n\u003e\n\u003e Seems the proposal still works without the intermediaries needing to know this?\n\u003e\n\u003e We may want to add that the receiver:\n\u003e\n\u003e -   SHOULD fail the payment if `intended_total_payment` is less than the invoice\n\u003e     amount\n\u003e\n\u003e\n\u003e \u003e I'm wondering, since these payments are no longer atomic, should we name it\n\u003e \u003e accordingly?\n\u003e\n\u003e Indeed this true. Perhaps NAMP or CPHR (Concurrent Payment Hash Re-use) are more\n\u003e accurate and may avoid confusion?\n\u003e\n\u003e Cheers,\n\u003e Conner\n\u003e On Tue, Nov 13, 2018 at 8:33 AM Johan Torås Halseth johanth at gmail.com wrote:\n\u003e\n\u003e \u003e Good evening Z and list,\n\u003e \u003e I'm wondering, since these payments are no longer atomic, should we name it accordingly?\n\u003e \u003e Cheers,\n\u003e \u003e Johan\n\u003e \u003e On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev lightning-dev at lists.linuxfoundation.org wrote:\n\u003e \u003e\n\u003e \u003e \u003e Good morning list,\n\u003e \u003e \u003e I propose the below to support Base AMP.\n\u003e \u003e \u003e The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits.\n\u003e \u003e \u003e\n\u003e \u003e \u003e ### The `multipath_merge_per_hop` type (`option_base_amp`)\n\u003e \u003e \u003e\n\u003e \u003e \u003e 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.\n\u003e \u003e \u003e In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits.\n\u003e \u003e \u003e\n\u003e \u003e \u003e 1.  type: 1 (`termination_per_hop`)\n\u003e \u003e \u003e 2.  data:\n\u003e \u003e \u003e\n\u003e \u003e \u003e -   [`8` : `short_channel_id`]\n\u003e \u003e \u003e -   [`8` : `amt_to_forward`]\n\u003e \u003e \u003e -   [`4` : `outgoing_cltv_value`]\n\u003e \u003e \u003e -   [`8` : `intended_total_payment`]\n\u003e \u003e \u003e -   [`4` : `zeros`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e The contents of this hop will be the same across all paths of the Base AMP.\n\u003e \u003e \u003e The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.\n\u003e \u003e \u003e `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`.\n\u003e \u003e \u003e 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).\n\u003e \u003e \u003e The receiver:\n\u003e \u003e \u003e\n\u003e \u003e \u003e -   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`.\n\u003e \u003e \u003e -   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`.\n\u003e \u003e \u003e\n\u003e \u003e \u003e The sender:\n\u003e \u003e \u003e\n\u003e \u003e \u003e -   MUST use the same `payment_hash` for all paths of a single multipath payment.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Regards,\n\u003e \u003e \u003e ZmnSCPxj\n\u003e \u003e \u003e\n\u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}