📅 Original date posted:2018-11-13
📝 Original message:
Good morning all,
> MUST NOT forward (if an intermediate node) or claim (if the final node) unless
> it has received a total greater or equal to `intended_total_payment` in all
> incoming HTLCs for the same `payment_hash`.
I was under the impression that this would not require changes on behalf of the
intermediaries, and only need to be implemented by the sender and receiver?
If not, then nodes would need to advertise that they support this so that the
sender can be sure to route through the subset of nodes that support it.
Either way, it would seem that this constraint can only be accurately enforced
by the receiver. If any partial payments fail, then the `intended_total_payment`
through an intermediary may never arise and the payment would be held. This
would also seem to exclude the possibility of iterative path finding, since the
entire payment flow must be known up front during onion packet construction.
Seems the proposal still works without the intermediaries needing to know this?
We may want to add that the receiver:
* SHOULD fail the payment if `intended_total_payment` is less than the invoice
amount
> I'm wondering, since these payments are no longer atomic, should we name it
> accordingly?
Indeed this true. Perhaps NAMP or CPHR (Concurrent Payment Hash Re-use) are more
accurate and may avoid confusion?
Cheers,
Conner
On Tue, Nov 13, 2018 at 8:33 AM Johan Torås Halseth <johanth at gmail.com> wrote:
>
> Good evening Z and list,
>
> I'm wondering, since these payments are no longer atomic, should we name it accordingly?
>
> Cheers,
> Johan
>
> On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>
>> Good morning list,
>>
>> I propose the below to support Base AMP.
>>
>> The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits.
>>
>> ### The `multipath_merge_per_hop` type (`option_base_amp`)
>>
>> This indicates that payment has been split by the sender using Base AMP, and that the receiver should wait for the total intended payment before forwarding or claiming the payment.
>> In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits.
>>
>> 1. type: 1 (`termination_per_hop`)
>> 2. data:
>> * [`8` : `short_channel_id`]
>> * [`8` : `amt_to_forward`]
>> * [`4` : `outgoing_cltv_value`]
>> * [`8` : `intended_total_payment`]
>> * [`4` : `zeros`]
>>
>> The contents of this hop will be the same across all paths of the Base AMP.
>> The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.
>>
>> `intended_total_payment` is the total amount of money that this node should expect to receive in all incoming paths to the same `payment_hash`.
>>
>> This may be the last hop of a payment onion, in which case the `HMAC` for this hop will be `0` (the same rule as for `per_hop_type` 0).
>>
>> The receiver:
>>
>> * MUST impose a reasonable timeout for waiting to receive all component paths, and fail all incoming HTLC offers for the `payment_hash` if they have not totalled equal to `intended_total_payment`.
>> * MUST NOT forward (if an intermediate node) or claim (if the final node) unless it has received a total greater or equal to `intended_total_payment` in all incoming HTLCs for the same `payment_hash`.
>>
>> The sender:
>>
>> * MUST use the same `payment_hash` for all paths of a single multipath payment.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Conner Fromknecht [ARCHIVE] /
npub1za…uua2a
2023-06-09 12:52:41
in reply to nevent1q…48q4
Author Public Key
npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2aPublished at
2023-06-09 12:52:41Event JSON
{
"id": "77d420632545010a66730b438f0b1d3a6189bb751779f33c63b281577b99451f",
"pubkey": "175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246",
"created_at": 1686315161,
"kind": 1,
"tags": [
[
"e",
"809f1a75998ec1e3eebcb7a31f0cc9fe5473d678fb16cc9dfe25f3232ec33478",
"",
"root"
],
[
"e",
"f7809bdc29a11789d1b38390d0f98f18a4f33bc1df612bb3b7da9b988ad3212c",
"",
"reply"
],
[
"p",
"0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f"
]
],
"content": "📅 Original date posted:2018-11-13\n📝 Original message:\nGood morning all,\n\n\u003e MUST NOT forward (if an intermediate node) or claim (if the final node) unless\n\u003e it has received a total greater or equal to `intended_total_payment` in all\n\u003e incoming HTLCs for the same `payment_hash`.\n\nI was under the impression that this would not require changes on behalf of the\nintermediaries, and only need to be implemented by the sender and receiver?\nIf not, then nodes would need to advertise that they support this so that the\nsender can be sure to route through the subset of nodes that support it.\n\nEither way, it would seem that this constraint can only be accurately enforced\nby the receiver. If any partial payments fail, then the `intended_total_payment`\nthrough an intermediary may never arise and the payment would be held. This\nwould also seem to exclude the possibility of iterative path finding, since the\nentire payment flow must be known up front during onion packet construction.\n\nSeems the proposal still works without the intermediaries needing to know this?\n\nWe may want to add that the receiver:\n* SHOULD fail the payment if `intended_total_payment` is less than the invoice\n amount\n\n\u003e I'm wondering, since these payments are no longer atomic, should we name it\n\u003e accordingly?\n\nIndeed this true. Perhaps NAMP or CPHR (Concurrent Payment Hash Re-use) are more\naccurate and may avoid confusion?\n\nCheers,\nConner\nOn Tue, Nov 13, 2018 at 8:33 AM Johan Torås Halseth \u003cjohanth at gmail.com\u003e wrote:\n\u003e\n\u003e Good evening Z and list,\n\u003e\n\u003e I'm wondering, since these payments are no longer atomic, should we name it accordingly?\n\u003e\n\u003e Cheers,\n\u003e Johan\n\u003e\n\u003e On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Good morning list,\n\u003e\u003e\n\u003e\u003e I propose the below to support Base AMP.\n\u003e\u003e\n\u003e\u003e The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits.\n\u003e\u003e\n\u003e\u003e ### The `multipath_merge_per_hop` type (`option_base_amp`)\n\u003e\u003e\n\u003e\u003e This indicates that payment has been split by the sender using Base AMP, and that the receiver should wait for the total intended payment before forwarding or claiming the payment.\n\u003e\u003e In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits.\n\u003e\u003e\n\u003e\u003e 1. type: 1 (`termination_per_hop`)\n\u003e\u003e 2. data:\n\u003e\u003e * [`8` : `short_channel_id`]\n\u003e\u003e * [`8` : `amt_to_forward`]\n\u003e\u003e * [`4` : `outgoing_cltv_value`]\n\u003e\u003e * [`8` : `intended_total_payment`]\n\u003e\u003e * [`4` : `zeros`]\n\u003e\u003e\n\u003e\u003e The contents of this hop will be the same across all paths of the Base AMP.\n\u003e\u003e The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.\n\u003e\u003e\n\u003e\u003e `intended_total_payment` is the total amount of money that this node should expect to receive in all incoming paths to the same `payment_hash`.\n\u003e\u003e\n\u003e\u003e This may be the last hop of a payment onion, in which case the `HMAC` for this hop will be `0` (the same rule as for `per_hop_type` 0).\n\u003e\u003e\n\u003e\u003e The receiver:\n\u003e\u003e\n\u003e\u003e * MUST impose a reasonable timeout for waiting to receive all component paths, and fail all incoming HTLC offers for the `payment_hash` if they have not totalled equal to `intended_total_payment`.\n\u003e\u003e * MUST NOT forward (if an intermediate node) or claim (if the final node) unless it has received a total greater or equal to `intended_total_payment` in all incoming HTLCs for the same `payment_hash`.\n\u003e\u003e\n\u003e\u003e The sender:\n\u003e\u003e\n\u003e\u003e * MUST use the same `payment_hash` for all paths of a single multipath payment.\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e ZmnSCPxj\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\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",
"sig": "648bed90fb531327057f16ffd425eb3e8e6e9e64d6292de604260cdfa6d1f3be4f7c960d49acee0cfb84003ac0216bb1157a4f99c64e1d0d01912d1d6ba8658c"
}