📅 Original date posted:2018-11-13
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181113/6342ecf1/attachment-0001.html>;
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:52:40
in reply to nevent1q…h5na
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:52:40Event JSON
{
"id": "f7809bdc29a11789d1b38390d0f98f18a4f33bc1df612bb3b7da9b988ad3212c",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686315160,
"kind": 1,
"tags": [
[
"e",
"809f1a75998ec1e3eebcb7a31f0cc9fe5473d678fb16cc9dfe25f3232ec33478",
"",
"root"
],
[
"e",
"7f9981b3bf71347d81a3847a19039b698f6127100db490d4d17437b2d59450d4",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-13\n📝 Original message:\nGood evening Z and list,\n\nI'm wondering, since these payments are no longer atomic, should we name it\naccordingly?\n\nCheers,\nJohan\n\nOn Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning list,\n\u003e\n\u003e I propose the below to support Base AMP.\n\u003e\n\u003e The below would allow arbitrary merges of paths, but not arbitrary\n\u003e splits. I am uncertain about the safety of arbitrary splits.\n\u003e\n\u003e ### The `multipath_merge_per_hop` type (`option_base_amp`)\n\u003e\n\u003e This indicates that payment has been split by the sender using Base AMP,\n\u003e and that the receiver should wait for the total intended payment before\n\u003e forwarding or claiming the payment.\n\u003e In case the receiving node is not the last node in the path, then\n\u003e succeeding hops MUST be the same across all splits.\n\u003e\n\u003e 1. type: 1 (`termination_per_hop`)\n\u003e 2. data:\n\u003e * [`8` : `short_channel_id`]\n\u003e * [`8` : `amt_to_forward`]\n\u003e * [`4` : `outgoing_cltv_value`]\n\u003e * [`8` : `intended_total_payment`]\n\u003e * [`4` : `zeros`]\n\u003e\n\u003e The contents of this hop will be the same across all paths of the Base AMP.\n\u003e The `payment_hash` of the incoming HTLCs will also be the same across all\n\u003e paths of the Base AMP.\n\u003e\n\u003e `intended_total_payment` is the total amount of money that this node\n\u003e should expect to receive in all incoming paths to the same `payment_hash`.\n\u003e\n\u003e This may be the last hop of a payment onion, in which case the `HMAC` for\n\u003e this hop will be `0` (the same rule as for `per_hop_type` 0).\n\u003e\n\u003e The receiver:\n\u003e\n\u003e * MUST impose a reasonable timeout for waiting to receive all component\n\u003e paths, and fail all incoming HTLC offers for the `payment_hash` if they\n\u003e have not totalled equal to `intended_total_payment`.\n\u003e * MUST NOT forward (if an intermediate node) or claim (if the final node)\n\u003e unless it has received a total greater or equal to `intended_total_payment`\n\u003e in all incoming HTLCs for the same `payment_hash`.\n\u003e\n\u003e The sender:\n\u003e\n\u003e * MUST use the same `payment_hash` for all paths of a single multipath\n\u003e payment.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\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/20181113/6342ecf1/attachment-0001.html\u003e",
"sig": "1b6cda1a9ec83d75fbd1e28dd78d5971e0d3ec5c4c6698f4d70457aaf0c8a03c8db97ad27324e4a1eec00ff9489c7d23845b52cf30d182b9116ae2c8925582c8"
}