Protocol Updates for Atomic Multi-Path Payments
Atomic multi-path payments is one of the next generation technologies coming to Lightning, it allows a sender to send payments from multiple channels to one receiver, aggregating the payments through the route or the final node.
ZmnSCPxj started a discussion on the protocol update to handle such payments. The receiver provides a payment hash that the sender re-uses across all streams and then waits until the sum matches the invoice.
There is currently two proposals on how to do this, one requires every node in
the path to accept AMPs to make every point on the paths a possible merging
point, these nodes must only forward (if intermediate node) or claim (if final
node) when they receive a total payment greater or equal to
intended_total_payment. Receiving nodes then merge every payments to get its
final payment while intermediate nodes merge payments and send it along the
path, this proposal comes with a con that if any of the intermediate nodes fail
in merging the payments the final node will not get its “intended total
payment” and so it causes failure for every other Atomic payment.
Another proposal is that only the sender and the receiver should accept AMPs, every other node on the multiple paths just routes the payment as usual and only the receiver node is able to merge payments, this proposal is simpler and does not require the whole network to comply to this update, but might need more connections on the network.
To get more information about the implementation of AMP, you can read more in the discussion on the Lightning-dev list.
### 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.
Support us and the authors of this article by donating to the following address:3PhPp67RKY6oAwv57Hj9hFM3F2N5Kk5AJA
Comments powered by Talkyard.