[Lightning-dev] Routing on the lightning network?

Rusty Russell rusty at rustcorp.com.au
Wed Jul 15 01:19:25 UTC 2015


CJP <cjp at ultimatestunts.nl> writes:
> Rusty Russell <rusty at rustcorp.com.au> wrote:
>> OK, so this is why I proposed an onion routing system.
>> 
>> Basically: each node sees the next hop, the R hash, the amount, the
>> timeout, the fee being offered.  It doesn't see the source, nor the
>> final destination.
>> 
>> This, however, requires source routing.
>
> Ah, now I understand a bit better what you mean with onion routing. Yes,
> that requires source routing, and it is another way of anonymizing the
> route. A disadvantage of this approach is that it requires the source of
> a route (so basically everyone) to know the shape of the network (who is
> connected to who), which is a privacy disadvantage. This is not
> necessary in TOR, since in TOR, every node can (usually) connect to
> every other node, so finding a route is trivial.
>
> At the risk of making things too complicated: it is possible to combine
> both concepts in a single design. Source routing just requires the
> protocol to be able to carry arbitrary payload data to the next
> waypoint, so that the waypoint (which is supposed to understand the
> arbitrary payload data) can determine how the route should be continued.
> It's perfectly fine if the final waypoint of the route is a "neutral
> meeting point" somewhere in the middle, as in my concept. In-between
> waypoints, routers are free to use non-source routing, as long as the
> waypoints can report with reasonable accuracy which other waypoints are
> reachable, so that other nodes know the high-level shape of the network
> for use in their source routing.

It does follow logically: the node is given the next hop, the fee the
transaction is prepared to pay there, and the time delta (eg. there must
be 3 days left on the HTLC at that point).

If it's expressed that way, there's no reason that "next hop" need be
adjacent, right?

> I don't see the "several thousand hubs" model as more sensitive to
> centralization/censorship than other routing models, as long as there is
> no barrier to creating your own hub and to start using new hubs. Any
> routing model has routable addresses and risks addresses being censored
> by a part of the network.

My concern is mainly that if we design something which doesn't scale,
nodes will be forced to insert barriers to newcomers for their own
preservation.  Thus my preference to design in terms of millions, not
thousands, if that makes sense.

> There is one other attack mode I see, which is independent of the
> routing method: a powerful attacker (read: government) could be
> monitoring transactions on several "regulated" nodes. It could also gain
> the ability, every once in a while, to initiate transactions from an
> "illegal" node that should have been censored (e.g. by physical access
> to its hardware). If such transactions are routed over "regulated"
> nodes, it would immediately recognize this, because the transaction hash
> would be the same. The attacker can then identify the node that allows
> "illegal" transactions to enter the regulated network, and punish it.
> Even if we find a way to somehow use a different hash on every hop of a
> transaction, it can still do this based on the exact payment amount, or
> based on timing. I don't see right now how this attack mode can be
> eliminated; maybe it should be accepted as a risk inherent in the design
> of the network. Let's hope that the freedom-loving part of the network
> will always be so large that censorship-loving parts will just hurt
> themselves by isolating themselves.

Yes, indeed.

Cheers,
Rusty.


More information about the Lightning-dev mailing list