Good morning Ariel and Rene and list,

I have started to consider how best to attack the modified Luaces-Pickhardt 
JIT-Routing, which reuses the same payment hash as the message to forward.
(In the case where JIT-Routing is used by the ultimate source of a payment, the 
payment hash of the invoice being paid.)

And it seems that, unless hop routes are given more time than their reported 
`cltv_delta`, then either:

1.  JIT-Routing cannot be done since the rebalancing requires more blocks than 
is allocated to the hop,
2.  OR, JIT-Routing is done despite the lack of blocks, at the major risk of 
possibly getting attacked by fooling around with lock times.

Decorrelation could remove the risk in #2.

--

So let us consider the below simple network graph:


    A ----- B ----- D ----- E
            |       |
            |       |
            +-- C --+

Let us pretend that C-Lightning has taken over the world and that everyone uses 
a sensible 14-block `cltv_delta`.

The node B receives an onion from A, with the specs:

1.  A offers an HTLC to B with value 1001 msat, and timelocked in 70 blocks 
from now.
2.  B should offer an HTLC to D with value 1000 msat, and timelocked in 56 
blocks from now.

As it happens, B has not enough money in channel B-D, but can augment it with 
money from B-C by rebalancing.

If it's the original Pickhardt JIT-Routing, then B takes on the risk that a 
later hop in the onion will fail, however it can complete the rebalancing 
without caring about the timelocks of the "actual" route.

However, if we reuse the payment preimage, and use the "reverse the polarity" 
operation proposed by Pickhardt in response to Luaces, then we need to respect 
the timelocks.
In particular, even the rebalance nodes C and D will impose `cltv_delta`.
Note that C and D have 14 blocks each, but what is allocated to B is only 14 
blocks for itself.

Suppose we consider --- since the "reverse the polarity" operation means there 
are HTLCs from B->D and B->C->D, then it should be safe to have the B->C->D->B 
path have a longer timelock on the first HTLC; the B->D direct HTLC would still 
allow B to claim the money from A.
So B would do:

1.  It receives the onion from A and finds it has insufficient capacity on B-D 
channel.
2.  It creates a new onion B->C->D->B, with timelocks:
    a. D->B now+56 (this will be reversed into a B->D HTLC with timelock now+56)
    b. C->D now+70
    c. B->C now+84
3.  B sends the above onion, using the same payment hash as the original onion.

Now suppose A, D, and C are actually controlled by an evil person Eve.
Eve knows the original onion and in particular knows the original payment hash 
and preimage.
In addition, it knows the condition of channels B-C and B-D.

So Eve attacks as below:

1.  C stalls until now+71.
    a.  The original A->N HTLC (with timeout now+70) is invalidated.
    b.  The B->C HTLC (with timeout now+84) is still valid.
2.  C claims the amount in the B->C HTLC.
    Even if B refuses, C can always settle it onchain.

Now of course B might not choose the specific C controlled by Eve in the 
rebalance.
But note that D can keep failing incoming HTLCs from all nodes until either B 
selects the C that Eve controls, or B gives up (in which case Eve loses nothing 
anyway).

So B cannot safely use the "reverse the polarity" operation, unless the onion 
gives it much more time than its `cltv_delta` declares.
But if nodes boost their `cltv_delta`s, then it also becomes impossible to 
JIT-route.
And if we give each hop node more than their declared `cltv_delta`, then that 
increases the risk on the source node (since the total time it gives to all hop 
nodes is the maximum amount of time that its money could be locked in the worst 
case).

A similar attack on D can be mounted (by B, C, and E) if we adjust the 
timelocks in the opposite direction.

In conclusion, the "reverse the polarity" operation is not feasible for 
JIT-Routing.
Instead, the hop node B needs to incur the entire risk in rebalancing.
It also means that the JIT-Routing technique cannot be used by 
unidirectional-only implementations like Eclair Mobile.

--

> An intermediate route node could decide for any reason to re-route a payment 
> through any subset of nodes to arrive at the next hop. This is similar to 
> Rene's local AMP idea where friend-of-a-friend nodes are used. But instead 
> this system could allow arbitraryly long paths to the next hop by finding a 
> new sub-route and re-layering the onion packet with the new sub-route 
> prepended.

This requires "Rendezvous Routing", which cdecker and cjp are working on; there 
is something something math involved.
In particular it requires switching to some other point in the onion 
encryption; sorry, I am not enough of a mathist to tell you what that means.

The problem with this is again that timelocks need to be respected.
If a hop node cannot find a route that fits its own time risk and the time risk 
allocated to it by the source payer.

Regards,
ZmnSCPxj

Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to