Johan Torås Halseth [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-21 📝 Original message: Seems like we can ...
📅 Original date posted:2018-11-21
📝 Original message:
Seems like we can restrict the changes to BOLT11 by having the receiver
assume NAMP for incoming payments < invoice_amount. (with some timeout of
course, but that would need to be the case even when the sender is
signalling NAMP).
Cheers,
Johan
On Wed, Nov 21, 2018 at 3:55 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/8f56db8f/attachment.html>
📝 Original message:
Seems like we can restrict the changes to BOLT11 by having the receiver
assume NAMP for incoming payments < invoice_amount. (with some timeout of
course, but that would need to be the case even when the sender is
signalling NAMP).
Cheers,
Johan
On Wed, Nov 21, 2018 at 3:55 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/8f56db8f/attachment.html>