[Lightning-dev] Trampoline Routing

[fiatjaf]

Thank you very much. These were very clarifying answers and ramblings.

On Monday, August 5, 2019, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning fiatjaf,
>
>> No. My question was more like why does Alice decide to build a route
that for through T1 and RT2 and not only through one trampoline router she
knows.
>
> If Alice only always used one trampoline node, then the trampoline node
can assume the next hop is always the payee, and thus record who the payee
is (eroding privacy).
> If Alice uses two, then a trampoline node would have a 50/50 chance of
knowing who the final payee is, reducing the privacy erosion.
>
> Similarly, onion routing over Tor typically passes through 3 "trampoline"
nodes before going to the actual site being accessed.
>
>>
>> That makes sense you me in the context of ZmnSCPxj's virtual space idea,
but not necessarily in the current network conditions. You also said we're
going to need some hierarchy, but what it's that? Is it required?
>
> I believe in the future we will see a public network that is too large to
fit on most devices available to most people.
> We may or may not want to have such an enormous network, but the cost of
advertising a public channel is the same as the cost of creating a
non-public channel, thus there is no incentive for random end-user nodes to
*not* publish their channels, and incentive to publish (there is a tiny but
non-zero chance of being routed through, especially as local-area
specializations like JIT-Routing get implemented).
>
> Thus, I believe it is eventually required that we hierarchicalize how we
store information, with a "myopic" detailed channel map and a "rough"
global map with just trampoline-payee association mappings.
> I think it is best for each payer to define its own hierarchy or split,
preferentially with some random component.
>
> One might consider, however, that my ramblings are too indefinite and it
would be better to see the network as it evolves.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190805/85da457a/attachment.html>