CJP [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-14 📝 Original message: > OK, so this is why I ...

📅 Original date posted:2015-07-14
📝 Original message:
> 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.

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.

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.


> In summary:
>
> 1) Each-hop routing:
> - Final destination hub is revealed to all nodes.
> - May be forwarded, though.
Yes, may be forwarded, as in the "hybrid design" I described here. Also,
bi-directional routing towards a meeting point in the middle doesn't
reveal the final destination of the route as a whole.
> - Source may be revealed to all nodes?
Not necessary. You just need to keep the route open for a while, so that
messages towards the source can follow it back.
> - Fees are tricky.
> - Too low will fail
> - How to estimate?
I'll make another reply about fees; that's a whole subject on its own.
> - Adaptable to changing network conditions
> - Intermediary nodes can reroute.
> - End clients need not know anything.
>
> 2) Source routing:
> - Neither final source nor dest revealed to intermediary nodes.
> - Fees are known in advance.
> - Requires retransmission from source if routes change.
> - End clients need routing/fee information.
> - Allows selection of nodes from source
> - May let you avoid bad/tracking/unreliable nodes?

CJP