From joseph at lightning.network  Thu Aug 20 21:08:23 2015
From: joseph at lightning.network (Joseph Poon)
Date: Thu, 20 Aug 2015 14:08:23 -0700
Subject: [Lightning-dev] Loop attack with onion routing..
In-Reply-To: <874mjujyqe.fsf@rustcorp.com.au>
References: <874mjujyqe.fsf@rustcorp.com.au>
Message-ID: <20150820210823.GB1762@lightning.network>

On Thu, Aug 20, 2015 at 03:19:29PM +0930, Rusty Russell wrote:
>         So, with some prompting from AJ who has been working on node
> incentives, I realized there's a nasty attack available to the
> network. You simply route a payment back to another channel you own,
> then refuse to dislose R.
> 
> You have to lock up N bitcoins, but so does every node in the path
> (and nobody gets paid!).  Onion routing means nobody knows who to
> blame (you can simply claim there's another hop after you).

This can be defined as a feature, though. If one expects the coins to be
locked up for the duration from the outset, the risk models are a lot
more clear.

It forces the graph to be more diffuse. It also forces intermediate
nodes who are well-connected (who therefore also are the most likely
subject of attacks) to offload their HTLCs to 3rd party channel
liquidity providers.

E.g. If Mallory tries to tie up the Alice<->Bob link, then if Carol is
connected to both Alice and Bob, she can take the HTLC to be
Alice->Carol->Bob, so that the Alice<->Bob link is clear.

> I think in this case we need to peel the onion[1]: if a payment takes
> too long you tell the previous node where you sent it (and relay where
> it sent it, etc.)  If you're the last in the queue, you also need to
> prove that you closed the channel to the offender[2] (which costs you
> a txfee, providing disincentive).

My concern with mitigating this by establishing blame via information
disclosure is that it will encourage graph centralization.

> Anyone see any other problems?

I see the primary problem with "onion" routing is that some parts of the
graph may be faster with disclosure of R. In effect, some people may
have higher costs in the "time" part of "time-value"

E.g. A->B->C->D->E. If C, D, and E are colluding participants to each
other, and their R gets disclosed immediately, their channel's value
permits much lower fees. They can collude to be dishonest with B, so
that B's channel is tied up for the maximum period of time. This
increases the costs for B and biases channels to use the C,D,E cartel
due to lower costs (since the channels aren't locked up as long). 

However! The effect isn't necessarily that the cartel is successful,
there are always second order effects in preventing potential problems.
It's possible that B mitigates this by biasing the routing towards
certain participants that B "likes" (IOW, trusts to not withhold R to the
maximum time), which is where I think the real complexity with
incentives lie -- B will discourage using onion routing entirely.

I see the tradeoffs as having both as an option may make sense, the
second order effect gives you an option for either (with one possibly
being slightly more expensive due to the withholding risks), whereas
forcing onion *only* on everything may create emergent cartelization
incentives. I haven't fully thought out the implications, and not
particularly attached to this viewpoint, though.

Thaddeus mentioned a possible solution to all this being funds sent to
each participant with multiple signatures for different times of
disclosure of R (having the spending transaction be double-spent with
different locktimes, this is dependent upon a longer-term malleability
fix and may require a more elaborate tree structure for the HTLC
spends). E.g. release within 4 hours will have each hop make slightly
more money in fees. It doesn't guarantee against withholding, it just
creates a material cost to do so. I don't think we've really fleshed out
the idea, though AFAIK.

-- 
Joseph Poon