[Lightning-dev] Base AMP

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed Nov 21 02:54:28 UTC 2018


Good morning Rusty,

> And do not play with `amount_to_forward`, as it's an important
> signal to the final node that the previous node did not offer less value
> for the HTLC than it was supposed to. (You could steal the top bit to
> signal partial payment if you really want to).

I do not view this as playing with the existing `amt_to_forward`, but rather retaining its previous use.

If it helps, we can rewrite the *current* pre-AMP spec as below:

2. data:
    ...
    * [`8` : `amt_to_forward` / `amt_to_pay`]

...

* `amt_to_forward` - for **non-final** nodes, this is the value to forward to the next node.
  Non-final nodes MUST check:

    incoming_htlc_amt - fee >= amt_to_forward

* `amt_to_pay` - for **final** nodes, this is the value that is intended to reach it.
  Final nodes MUST check:

    incoming_htlc_amt >= amt_to_pay

Then for Base AMP:

* `amt_to_pay` - for **final** nodes, this is the total value that is intended to reach it.
  If `incomplete_payment` flag is not set, final nodes MUST check:

    incoming_htlc_amt >= amt_to_pay

  If `incomplete_payment` flag is set, then final nodes must claim HTLCs only if:

    sum(incoming_htlc_amt) >= amt_to_pay

  Where `sum(incoming_htlc_amt)` is the total `incoming_htlc_amt` for all incoming HTLCs terminating at this final node with the same `payment_hash`.



Now perhaps we can argue that for AMP we should have two fields `amt_to_pay_for_this_partial_payment` and `amt_to_pay_for_total_payment` instead.


Regards,
ZmnSCPxj



More information about the Lightning-dev mailing list