Good morning list,

I propose the below to support Base AMP.

The below would allow arbitrary merges of paths, but not arbitrary splits.  I 
am uncertain about the safety of arbitrary splits.

### 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.

Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to