Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-20 📝 Original message: René Pickhardt via ...
📅 Original date posted:2018-11-20
📝 Original message:
René Pickhardt via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Hey List,
>
> as this base AMP proposal seems pretty small I just started to write this
> up to make a PR for BOLT04 and BOLT11. While doing my write up I realize
> that there are smaller things that I would want to verify / double check
> and propose with you.
>
> ## Verifying:
> 1.) I understand the receiving node signals support for Base AMP by setting
> a feature bit in the BOLT11 String
Yes, this seemed a logical reason to add features to BOLT11.
> 2.) The sending node signals a multipath payment by setting a feature bit
> and by using the same `amount to forward` value in the last hop of the
> onion for all paths which will also be bigger that the incoming htlcs whose
> sum has to be at least the size of `amount_to_forward`.
Not a feature bit as such, but some signal for the final node (in the
onion). 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).
> ## Clarifying:
> 3.) Senders MUST NOT (SHOULD NOT?) create paths which would have to be
> merged by intermediary nodes (as we don't know - and have no means of
> querying - if they support the format of the adepted onion packages for
> partial paths. Also it even seems impossible since the rest of the path for
> at least one partial path could not be stored in the onion / forwarded
> onions can't be seen)
In-path merging is overreach, let's not do it or mention it.
There's a slight preference to avoid sharing intermediary nodes to avoid
correlation. Intermediary nodes know they need to forward all of them
or not get paid for any of them, and they're already supposed to do so.
> ## Proposing:
> Should we specify an algorithm for executing a multipath payment for the
> sending node or should this be left to the implementation. An obvious Idea
> for an algorithm would be a divide and conquer scheme which should be
> obvious with the following python style pseudo code:
>
> def pay_base_amp(amount):
> success = False
> for route in get_available_routes():
> success = send_via_route(route, amount)
> if not success:
> pay_base_amp(amount/2 + 1) # the +1 is to mitigate rounding errors.
> there could be other ways to do so.
> pay_base_amp(amount/2 + 1)
I don't think this is actually useful. For example, I would suggest a
more random split, and start by using some estimate of channel capacity.
> Even if we leave the exact AMP execution to the sender we could still
> suggest this divide and conquer scheme in BOLT 04
>
> Another idea I had (which is probably a bad one as it allows for probing of
> channel balances) would be to allow nodes on a partial path to send back
> some hints of how much additional capacity they can forward if they see
> that the partial payment feature bit is set (this would require to set this
> feature bit in every onion) Also if we want to make use of this information
> every node would have to support base amp. So I guess this idea is bad for
> several reasons. Still we could have a MAY rule out of it?
I think we should adapt a convention for a lower limit at which we
disable the channel if we can't forward (eg 1% of capacity? 100
satoshis?). That gives us a better starting point for AMP, too.
Cheers,
Rusty.
Published at
2023-06-09 12:52:45Event JSON
{
"id": "70cc358371b04262739131af9297e47063f48f1bf7f534990b6ec391f98b783c",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315165,
"kind": 1,
"tags": [
[
"e",
"809f1a75998ec1e3eebcb7a31f0cc9fe5473d678fb16cc9dfe25f3232ec33478",
"",
"root"
],
[
"e",
"9e6748b29807af0f4d760f2cc81579362ff4fd79e3dbfa1a555e2444d0286b04",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-20\n📝 Original message:\nRené Pickhardt via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e writes:\n\u003e Hey List,\n\u003e\n\u003e as this base AMP proposal seems pretty small I just started to write this\n\u003e up to make a PR for BOLT04 and BOLT11. While doing my write up I realize\n\u003e that there are smaller things that I would want to verify / double check\n\u003e and propose with you.\n\u003e\n\u003e ## Verifying:\n\u003e 1.) I understand the receiving node signals support for Base AMP by setting\n\u003e a feature bit in the BOLT11 String\n\nYes, this seemed a logical reason to add features to BOLT11.\n\n\u003e 2.) The sending node signals a multipath payment by setting a feature bit\n\u003e and by using the same `amount to forward` value in the last hop of the\n\u003e onion for all paths which will also be bigger that the incoming htlcs whose\n\u003e sum has to be at least the size of `amount_to_forward`.\n\nNot a feature bit as such, but some signal for the final node (in the\nonion). And do not play with `amount_to_forward`, as it's an important\nsignal to the final node that the previous node did not offer less value\nfor the HTLC than it was supposed to. (You could steal the top bit to\nsignal partial payment if you really want to).\n\n\u003e ## Clarifying:\n\u003e 3.) Senders MUST NOT (SHOULD NOT?) create paths which would have to be\n\u003e merged by intermediary nodes (as we don't know - and have no means of\n\u003e querying - if they support the format of the adepted onion packages for\n\u003e partial paths. Also it even seems impossible since the rest of the path for\n\u003e at least one partial path could not be stored in the onion / forwarded\n\u003e onions can't be seen)\n\nIn-path merging is overreach, let's not do it or mention it.\n\nThere's a slight preference to avoid sharing intermediary nodes to avoid\ncorrelation. Intermediary nodes know they need to forward all of them\nor not get paid for any of them, and they're already supposed to do so.\n\n\u003e ## Proposing:\n\u003e Should we specify an algorithm for executing a multipath payment for the\n\u003e sending node or should this be left to the implementation. An obvious Idea\n\u003e for an algorithm would be a divide and conquer scheme which should be\n\u003e obvious with the following python style pseudo code:\n\u003e\n\u003e def pay_base_amp(amount):\n\u003e success = False\n\u003e for route in get_available_routes():\n\u003e success = send_via_route(route, amount)\n\u003e if not success:\n\u003e pay_base_amp(amount/2 + 1) # the +1 is to mitigate rounding errors.\n\u003e there could be other ways to do so.\n\u003e pay_base_amp(amount/2 + 1)\n\nI don't think this is actually useful. For example, I would suggest a\nmore random split, and start by using some estimate of channel capacity.\n\n\u003e Even if we leave the exact AMP execution to the sender we could still\n\u003e suggest this divide and conquer scheme in BOLT 04\n\u003e\n\u003e Another idea I had (which is probably a bad one as it allows for probing of\n\u003e channel balances) would be to allow nodes on a partial path to send back\n\u003e some hints of how much additional capacity they can forward if they see\n\u003e that the partial payment feature bit is set (this would require to set this\n\u003e feature bit in every onion) Also if we want to make use of this information\n\u003e every node would have to support base amp. So I guess this idea is bad for\n\u003e several reasons. Still we could have a MAY rule out of it?\n\nI think we should adapt a convention for a lower limit at which we\ndisable the channel if we can't forward (eg 1% of capacity? 100\nsatoshis?). That gives us a better starting point for AMP, too.\n\nCheers,\nRusty.",
"sig": "ed8ab29bf69b0b2c1507ae65f8d1c6aefc186eeccf0760f3678f78d682f6d0bdd89bd1cd2a13a53c2980fba5adaf79dc1a620bf29b272d0c870a53b638245e7a"
}