📅 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>;
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:52:45
in reply to nevent1q…k3cd
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:52:45Event JSON
{
"id": "54f083043014d420fc0f6aed10e407b42b7da98312dff8e0dd6ce0eef12576c2",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686315165,
"kind": 1,
"tags": [
[
"e",
"809f1a75998ec1e3eebcb7a31f0cc9fe5473d678fb16cc9dfe25f3232ec33478",
"",
"root"
],
[
"e",
"4efa85663b4b6e3e8bb9b816fcc7ead75ee5aeb6feb4d0637730968fa9e0de33",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-21\n📝 Original message:\nSeems like we can restrict the changes to BOLT11 by having the receiver\nassume NAMP for incoming payments \u003c invoice_amount. (with some timeout of\ncourse, but that would need to be the case even when the sender is\nsignalling NAMP).\n\nCheers,\nJohan\n\nOn Wed, Nov 21, 2018 at 3:55 AM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Rusty,\n\u003e\n\u003e \u003e And do not play with `amount_to_forward`, as it's an important\n\u003e \u003e signal to the final node that the previous node did not offer less value\n\u003e \u003e for the HTLC than it was supposed to. (You could steal the top bit to\n\u003e \u003e signal partial payment if you really want to).\n\u003e\n\u003e I do not view this as playing with the existing `amt_to_forward`, but\n\u003e rather retaining its previous use.\n\u003e\n\u003e If it helps, we can rewrite the *current* pre-AMP spec as below:\n\u003e\n\u003e 2. data:\n\u003e ...\n\u003e * [`8` : `amt_to_forward` / `amt_to_pay`]\n\u003e\n\u003e ...\n\u003e\n\u003e * `amt_to_forward` - for **non-final** nodes, this is the value to forward\n\u003e to the next node.\n\u003e Non-final nodes MUST check:\n\u003e\n\u003e incoming_htlc_amt - fee \u003e= amt_to_forward\n\u003e\n\u003e * `amt_to_pay` - for **final** nodes, this is the value that is intended\n\u003e to reach it.\n\u003e Final nodes MUST check:\n\u003e\n\u003e incoming_htlc_amt \u003e= amt_to_pay\n\u003e\n\u003e Then for Base AMP:\n\u003e\n\u003e * `amt_to_pay` - for **final** nodes, this is the total value that is\n\u003e intended to reach it.\n\u003e If `incomplete_payment` flag is not set, final nodes MUST check:\n\u003e\n\u003e incoming_htlc_amt \u003e= amt_to_pay\n\u003e\n\u003e If `incomplete_payment` flag is set, then final nodes must claim HTLCs\n\u003e only if:\n\u003e\n\u003e sum(incoming_htlc_amt) \u003e= amt_to_pay\n\u003e\n\u003e Where `sum(incoming_htlc_amt)` is the total `incoming_htlc_amt` for all\n\u003e incoming HTLCs terminating at this final node with the same `payment_hash`.\n\u003e\n\u003e\n\u003e\n\u003e Now perhaps we can argue that for AMP we should have two fields\n\u003e `amt_to_pay_for_this_partial_payment` and `amt_to_pay_for_total_payment`\n\u003e instead.\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/8f56db8f/attachment.html\u003e",
"sig": "94ed50425b153abbbef045d167c4fedbb9d813c0eaf77ed9bd113c5039b454853ef8197fc4342d9e1dea8e42e19310891874956e4e92a54c603d908a72e571b7"
}