ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-09 📝 Original message: Good morning Johan, > C ...
📅 Original date posted:2018-11-09
📝 Original message:
Good morning Johan,
> C must also make sure the detour route stays within the fee limit of course.
This is indeed quite correct. Contrariwise, if the detour route charges a fee that is even just 0.001 satoshi lower than the fee that C would charge, then it would still be rational to make this attempt: there is a nonzero change to earn 0.001 satoshi, whereas the alternative (fail the route) earns C 0 fees.
Another issue, is that the by inserting the switch-ephemeral-keys hop packet, a hop packet at the end may be pushed off, and C cannot know this. However, the same argument applies: the alternative is earning 0 fees.
Christian Decker pointed out that the D->C->A cycle could be rebalanced so that the C<->D link could pass the payment through. However, this has the slight disadvantage. If the route actually terminates to a payee further off at F, and it fails between F and E, then C has already paid for the rebalancing. Using this technique, C neither earns nor loses money.
This also increases the anonymity set, of rendez-vous routing. A rendez-vous supporting node may be used, not for rendez-vous, but instead, this link-level payment rerouting.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/5c3ff072/attachment.html>;
📝 Original message:
Good morning Johan,
> C must also make sure the detour route stays within the fee limit of course.
This is indeed quite correct. Contrariwise, if the detour route charges a fee that is even just 0.001 satoshi lower than the fee that C would charge, then it would still be rational to make this attempt: there is a nonzero change to earn 0.001 satoshi, whereas the alternative (fail the route) earns C 0 fees.
Another issue, is that the by inserting the switch-ephemeral-keys hop packet, a hop packet at the end may be pushed off, and C cannot know this. However, the same argument applies: the alternative is earning 0 fees.
Christian Decker pointed out that the D->C->A cycle could be rebalanced so that the C<->D link could pass the payment through. However, this has the slight disadvantage. If the route actually terminates to a payee further off at F, and it fails between F and E, then C has already paid for the rebalancing. Using this technique, C neither earns nor loses money.
This also increases the anonymity set, of rendez-vous routing. A rendez-vous supporting node may be used, not for rendez-vous, but instead, this link-level payment rerouting.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/5c3ff072/attachment.html>;