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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
