Author: ZmnSCPxj 2018-11-13 12:28:06
Published on: 2018-11-13T12:28:06+00:00
The proposal presented in this context aims to support Base AMP by allowing arbitrary merges of payment paths. However, it does not allow for arbitrary splits as their safety is uncertain. The `multipath_merge_per_hop` type (`option_base_amp`) indicates that payment has been split by the sender using Base AMP and the receiver should wait for the total intended payment before forwarding or claiming the payment. If the receiving node is not the last node in the path, succeeding hops must be the same across all splits.The contents of this hop will be the same across all paths of the Base AMP, and the `payment_hash` of incoming HTLCs will also be the same across all paths. `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`. 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 totaled equal to `intended_total_payment`. They must not forward (if an intermediate node) or claim (if the final node) unless they have 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. 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).
Updated on: 2023-05-25T16:35:23.661353+00:00