Ariel Lorenzo-Luaces [ARCHIVE] on Nostr: đź“… Original date posted:2019-03-14 đź“ť Original message: Hello Rene, ZmnSCPxj, and ...
đź“… Original date posted:2019-03-14
đź“ť Original message:
Hello Rene, ZmnSCPxj, and listÂ
I really like the proposal and I'm sure it's the correct way forward for reducing payment failures and increasing privacy (through mitigating probing based network analysis)Â
However I am concerned that this proposal could introduce a vulnerability to a spoofed-payment attack.Â
An adversary could create a malicious payment that's guaranteed to fail, for free. Any intermediary nodes on the path of the payment before it fails could lose fees due to rebalancing if the rebalancing path's success is not dependent on the original payment's success.Â
Could anyone speak to this and confirm whether it would be possible for the rebalancing step to reuse the original payment hash? If this is possible then it should explicitly be included in this proposal.Â
If reusing the payment hash is not possible on the routing path then JIT routing would need some other mitigation for the spoofed-payment attack.Â
CheersÂ
Ariel Lorenzo-LuacesÂ
On Mar 14, 2019, 7:45 AM, at 7:45 AM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>Good morning Rene and list,
>
>Let us consider then the rule *when* a rebalancing would be beneficial
>to the node.
>
>The node is offered a fee amount (`offered_fee_amount`) for the
>forwarding.
>It knows that, under current channel states, it will definitely have to
>fail and earn 0 fees.
>
>If it engages in JIT-routing, it must pay some fee
>(`rebalancing_fee_amount`) for the rebalancing operation.
>But even if it successfully forwards its hop, it is still possible that
>the route will fail anyway and it will earn 0 fees.
>
>So let us consider the probability of success (`success_rate`), a value
>between 0 to 1.0.
>This is the estimated probability that we will succeed the route after
>we forward it.
>
>We should only engage in JIT-routing if:
>
> offered_fee_amount * success_rate - rebalancing_fee_amount > 0
>
>The LHS of the subtraction is the expected earning, while the RHS of
>the subtraction is the expected cost.
>The above is trivial accounting for determining net earnings.
>
>The fee amounts are trivially computable.
>Presumably the rebalancing code can compute the fee given a particular
>rebalance path, and thus can provide `rebalancing_fee_amount`.
>
>The `success_rate` can be computed statically from some node data.
>Better, is for the node to start with this precomputed static
>information, but augment this over time with its own experienced
>`success_rate` for all forwards.
>
>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/20190314/5243cc1d/attachment.html>;
đź“ť Original message:
Hello Rene, ZmnSCPxj, and listÂ
I really like the proposal and I'm sure it's the correct way forward for reducing payment failures and increasing privacy (through mitigating probing based network analysis)Â
However I am concerned that this proposal could introduce a vulnerability to a spoofed-payment attack.Â
An adversary could create a malicious payment that's guaranteed to fail, for free. Any intermediary nodes on the path of the payment before it fails could lose fees due to rebalancing if the rebalancing path's success is not dependent on the original payment's success.Â
Could anyone speak to this and confirm whether it would be possible for the rebalancing step to reuse the original payment hash? If this is possible then it should explicitly be included in this proposal.Â
If reusing the payment hash is not possible on the routing path then JIT routing would need some other mitigation for the spoofed-payment attack.Â
CheersÂ
Ariel Lorenzo-LuacesÂ
On Mar 14, 2019, 7:45 AM, at 7:45 AM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>Good morning Rene and list,
>
>Let us consider then the rule *when* a rebalancing would be beneficial
>to the node.
>
>The node is offered a fee amount (`offered_fee_amount`) for the
>forwarding.
>It knows that, under current channel states, it will definitely have to
>fail and earn 0 fees.
>
>If it engages in JIT-routing, it must pay some fee
>(`rebalancing_fee_amount`) for the rebalancing operation.
>But even if it successfully forwards its hop, it is still possible that
>the route will fail anyway and it will earn 0 fees.
>
>So let us consider the probability of success (`success_rate`), a value
>between 0 to 1.0.
>This is the estimated probability that we will succeed the route after
>we forward it.
>
>We should only engage in JIT-routing if:
>
> offered_fee_amount * success_rate - rebalancing_fee_amount > 0
>
>The LHS of the subtraction is the expected earning, while the RHS of
>the subtraction is the expected cost.
>The above is trivial accounting for determining net earnings.
>
>The fee amounts are trivially computable.
>Presumably the rebalancing code can compute the fee given a particular
>rebalance path, and thus can provide `rebalancing_fee_amount`.
>
>The `success_rate` can be computed statically from some node data.
>Better, is for the node to start with this precomputed static
>information, but augment this over time with its own experienced
>`success_rate` for all forwards.
>
>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/20190314/5243cc1d/attachment.html>;