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.
📝 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.