Bidirectional Upfront Payment and Type 2 Loop Attacks Mitigatiion

[ariard]

I think a new dependency in the way routing nodes are accounting, advertising and verifying their fees must be underscored better before consider Bidirectional as "balance-safe" for intermediary hops.

Type 2 Loop Attacks are usually defined as long-held HTLCs by the final recipient or an intermediary hops thus freezing liquidity across all the links used by the payment path. This attack is made possible due to a fundamental building block of LN, a safety CLTV delta, deduced at each hop to allow in-order settlement of incoming/outgoing HTLCs. And thus avoiding a routing node to severe a balance disequilibrium across its relay links.

This liquidity timevalue is a resource like another and to prevent its abuse, its usage should be accounted as part of a relay cost structure. Along a payment-path, CLTV timelocks are higher on the topologically first links and thus routing fees required by those nodes will be higher.

Within context of Bidirectional, we should expect new hodl_fees to bind to the above routing fees computation, which may hinder a routing node's balance equilibrium.

E.g, with the following topology:

Alice ---> Bob ---> Caroll

Alice-Bob's HTLC nLocktime is superior to Bob-Caroll's one. H.a , "Alice's hodl_fee" required from Bob is superior to H.b "Bob's hodl_fee" required from Caroll.

Bob must correct this fee difference by a) advertise an unconditional fee F such as F - H.a > H.b and b) enforce that any payment routed through him commits to a F satisfying the equation.

It sounds like mitigating against Type 2 with Bidirectional will come with some change in the routing requirements. Routing fees for a given hop must integrate both incoming/outgoing channels' channel_update rather than only the incoming channel_update.

I don't see this as a blocker, but maybe a bit tricky to get it right.

[t-bast]

Alice-Bob's HTLC nLocktime is superior to Bob-Caroll's one. H.a , "Alice's hodl_fee" required from Bob is superior to H.b "Bob's hodl_fee" required from Caroll.

Why is that? In my proposal the hold_fees increases at each hop. B requires slightly more hold_fees from C than A requires from B. The goal is to ensure the last node in the route has the biggest hold_fees of the route, since he is the one with the ability to release the HTLC quickly (or choose to hodl it, in this case paying the hold_fees).

[ariard]

B requires slightly more hold_fees from C than A requires from B.

And this is the point where I'm not agree on, timelocks decrease along the payment path. A earlier-in-the-path node will have more timevalue burnt than an earlier one, assuming a worst-case scenario of onchain settlement.

So these earlier-in-the-path nodes should be paid more hold_fees IMO. But that's a economic assumption which could be good to discuss during a meeting, even before we start to dig in any solution.

[t-bast]

I understand the point, but it's a philosophical one in my opinion. We simply cannot do it that way otherwise it doesn't prevent spam, it has to (non-strictly) increment along the path to work.

The way I see it is different: every node along the path asks the next node for a hold_fees that it finds satisfying in case the HTLC is held for the longest duration. If that condition is met, they don't need to think about time held at all (nor the fact they will hold it longer than downstream nodes).