ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-21 📝 Original message: Good morning Rusty, > And ...

📅 Original date posted:2018-11-21
📝 Original message:
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