{"type":"rich","version":"1.0","title":"Christian Decker [ARCHIVE] wrote","author_name":"Christian Decker [ARCHIVE] (npub1wt…gtuyn)","author_url":"https://yabu.me/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-11-15\n📝 Original message:\nI'm not sure this is an improvement at all over just allowing a single\nmerge-point, i.e., the destination. You see as long as we don't attempt\nintermediate merges the routes are independent and failures of one HTLC\ndo not impact any other parts. Take for example the network below:\n\n  --------\n /        \\\nA----B-----C-----D\n\\               /\n -------E-------\n\nFor simplicity let's assume unit capacities on all channels except C-D\nand a total payment of 2 from A to D.\n\nIf we use C as a merge point for the two partial payments A-C-D and\nA-B-C-D, then C can only forward if both partial payment succeed, i.e.,\nif for example A-C fails then we'll need to tear down the HTLCs for both\npaths because it'll no longer be possible to find an alternative route\nto fulfill the forwarding of 2 over C-D.\n\nIf however we have two independent routes A-B-C-D and A-C-D, then A-C-D\ncan fail independently and we can recover by attempting A-E-D, no need\nto touch A-B-C-D at all.\n\nOverall it seems we get very little benefit (we save some HTLC setups\nand teardown) for a lot of added complexity. In the above case we would\nhave saved on a single C-D HTLC, and the cost of doing so is many times\nlarger (2 HTLCs needed to be torn down because we could no longer pass\nenough capacity to C in order for it to reach the forward threshold).\n\nLet's please stick with the simple mechanism of having the recipient be\nthe only merge point.\n\nCheers,\nChristian\n\nZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\nwrites:\n\u003e Good morning list,\n\u003e\n\u003e I propose the below to support Base AMP.\n\u003e\n\u003e The below would allow arbitrary merges of paths, but not arbitrary splits.  I am uncertain about the safety of arbitrary splits.\n\u003e\n\u003e ### The `multipath_merge_per_hop` type (`option_base_amp`)\n\u003e\n\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 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\n\u003e 1. type: 1 (`termination_per_hop`)\n\u003e 2. data:\n\u003e   * [`8` : `short_channel_id`]\n\u003e   * [`8` : `amt_to_forward`]\n\u003e   * [`4` : `outgoing_cltv_value`]\n\u003e   * [`8` : `intended_total_payment`]\n\u003e   * [`4` : `zeros`]\n\u003e\n\u003e The contents of this hop will be the same across all paths of the Base AMP.\n\u003e The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.\n\u003e\n\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\n\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\n\u003e The receiver:\n\u003e\n\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 * 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\n\u003e The sender:\n\u003e\n\u003e * MUST use the same `payment_hash` for all paths of a single multipath payment.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}