Author: Conner Fromknecht 2018-11-13 19:00:48
Published on: 2018-11-13T19:00:48+00:00
A proposal for supporting Base AMP has been put forward in which payment can be split by the sender using Base AMP, and the receiver should wait for the total intended payment before forwarding or claiming the payment. The `multipath_merge_per_hop` type (`option_base_amp`) 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. If the receiving node is not the last node in the path, then 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. 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`. In case the payment is held, it may exclude the possibility of iterative path finding as the entire payment flow must be known up front during onion packet construction.The proposal still works without the intermediaries needing to know this. It is suggested that the receiver SHOULD fail the payment if `intended_total_payment` is less than the invoice amount. It is also suggested that since these payments are no longer atomic, they should be named accordingly using NAMP or CPHR (Concurrent Payment Hash Re-use) to avoid confusion.
Updated on: 2023-05-25T16:36:35.105445+00:00