<oembed><type>rich</type><version>1.0</version><title>Johan Torås Halseth [ARCHIVE] wrote</title><author_name>Johan Torås Halseth [ARCHIVE] (npub1pp…hs2fw)</author_name><author_url>https://yabu.me/npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fw</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2018-11-13&#xA;📝 Original message:&#xA;Good evening Z and list,&#xA;&#xA;I&#39;m wondering, since these payments are no longer atomic, should we name it&#xA;accordingly?&#xA;&#xA;Cheers,&#xA;Johan&#xA;&#xA;On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev &lt;&#xA;lightning-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&#xA;&gt; Good morning list,&#xA;&gt;&#xA;&gt; I propose the below to support Base AMP.&#xA;&gt;&#xA;&gt; The below would allow arbitrary merges of paths, but not arbitrary&#xA;&gt; splits.  I am uncertain about the safety of arbitrary splits.&#xA;&gt;&#xA;&gt; ### The `multipath_merge_per_hop` type (`option_base_amp`)&#xA;&gt;&#xA;&gt; This indicates that payment has been split by the sender using Base AMP,&#xA;&gt; and that the receiver should wait for the total intended payment before&#xA;&gt; forwarding or claiming the payment.&#xA;&gt; In case the receiving node is not the last node in the path, then&#xA;&gt; succeeding hops MUST be the same across all splits.&#xA;&gt;&#xA;&gt; 1. type: 1 (`termination_per_hop`)&#xA;&gt; 2. data:&#xA;&gt;   * [`8` : `short_channel_id`]&#xA;&gt;   * [`8` : `amt_to_forward`]&#xA;&gt;   * [`4` : `outgoing_cltv_value`]&#xA;&gt;   * [`8` : `intended_total_payment`]&#xA;&gt;   * [`4` : `zeros`]&#xA;&gt;&#xA;&gt; The contents of this hop will be the same across all paths of the Base AMP.&#xA;&gt; The `payment_hash` of the incoming HTLCs will also be the same across all&#xA;&gt; paths of the Base AMP.&#xA;&gt;&#xA;&gt; `intended_total_payment` is the total amount of money that this node&#xA;&gt; should expect to receive in all incoming paths to the same `payment_hash`.&#xA;&gt;&#xA;&gt; This may be the last hop of a payment onion, in which case the `HMAC` for&#xA;&gt; this hop will be `0` (the same rule as for `per_hop_type` 0).&#xA;&gt;&#xA;&gt; The receiver:&#xA;&gt;&#xA;&gt; * MUST impose a reasonable timeout for waiting to receive all component&#xA;&gt; paths, and fail all incoming HTLC offers for the `payment_hash`  if they&#xA;&gt; have not totalled equal to `intended_total_payment`.&#xA;&gt; * MUST NOT forward (if an intermediate node) or claim (if the final node)&#xA;&gt; unless it has received a total greater or equal to `intended_total_payment`&#xA;&gt; in all incoming HTLCs for the same `payment_hash`.&#xA;&gt;&#xA;&gt; The sender:&#xA;&gt;&#xA;&gt; * MUST use the same `payment_hash` for all paths of a single multipath&#xA;&gt; payment.&#xA;&gt;&#xA;&gt; Regards,&#xA;&gt; ZmnSCPxj&#xA;&gt; _______________________________________________&#xA;&gt; Lightning-dev mailing list&#xA;&gt; Lightning-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev&#xA;&gt;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181113/6342ecf1/attachment-0001.html&gt;</html></oembed>