ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-20 📝 Original message: Good morning Rene, > Hey ...
📅 Original date posted:2018-11-20
📝 Original message:
Good morning Rene,
> 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
Correct.
> 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`.
The bit is not a "feature bit" specifically, as it is not a feature --- instead, it is a mode of operation or option.
Perhaps semantics only, however.
Otherwise, correct.
> ## 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.
MUST NOT, since an incomplete payment can only be signaled for final nodes.
I can explicitly use MUST NOT here I suppose.
> 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)
It would be easily doable to have the rest of the onion be the same for each incoming partial path.
An intermediate hop just needs to store one onion, and compare the HMAC of a second or third incoming onion to differentiate between different forward-merges.
> ## 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)
>
> Even if we leave the exact AMP execution to the sender we could still suggest this divide and conquer scheme in BOLT 04
The above naive scheme will not work in the general case.
See: https://lists.ozlabs.org/pipermail/c-lightning/2018-November/000084.html
It will not work well with the proposed `test_amp_unequal`, `test_amp_3way`. and `test_amp_5way` tests, at least until the amount has been split into tiny parts, possibly with fees becoming an issue (particularly `fee_base_msat`) due to having been split into many tiny parts.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181120/e52dc667/attachment.html>;
📝 Original message:
Good morning Rene,
> 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
Correct.
> 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`.
The bit is not a "feature bit" specifically, as it is not a feature --- instead, it is a mode of operation or option.
Perhaps semantics only, however.
Otherwise, correct.
> ## 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.
MUST NOT, since an incomplete payment can only be signaled for final nodes.
I can explicitly use MUST NOT here I suppose.
> 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)
It would be easily doable to have the rest of the onion be the same for each incoming partial path.
An intermediate hop just needs to store one onion, and compare the HMAC of a second or third incoming onion to differentiate between different forward-merges.
> ## 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)
>
> Even if we leave the exact AMP execution to the sender we could still suggest this divide and conquer scheme in BOLT 04
The above naive scheme will not work in the general case.
See: https://lists.ozlabs.org/pipermail/c-lightning/2018-November/000084.html
It will not work well with the proposed `test_amp_unequal`, `test_amp_3way`. and `test_amp_5way` tests, at least until the amount has been split into tiny parts, possibly with fees becoming an issue (particularly `fee_base_msat`) due to having been split into many tiny parts.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181120/e52dc667/attachment.html>;