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. 


Ariel Lorenzo-Luaces 

On Mar 14, 2019, 7:45 AM, at 7:45 AM, ZmnSCPxj via Lightning-dev 
<lightning-dev@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
>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.
>Lightning-dev mailing list
Lightning-dev mailing list

Reply via email to