Re: [Lightning-dev] Fwd: Trampoline Routing
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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Fwd: Trampoline Routing
> > Anyway, I'm probably missing something, but another way of putting my > question would be: why does your example use 2 trampolines instead of 1? Because I wanted to show the generality of the scheme: the number of trampoline hops is entirely Alice's choice. If Alice only cares about cost-efficiency, she will choose a single trampoline hop (in the current network's conditions). If Alice cares about privacy, she will likely chose more than one trampoline hop. The fact that she *may* use multiple trampoline hops is important because it increases her anonymity set (even if she uses only one in the end). You also said we're going to need some hierarchy, but what it's that? Is it > required? This is not needed in the current network because the routing table is still small. If the network eventually reaches a billion channels, we can't expect even trampoline nodes to sync everything and be able to find a route to any other node in the network: when/if that happens, we will need to introduce some kind of hierarchy / packet-switching as ZmnCSPxj previously mentioned. But we don't know yet if that will happen, or when it will happen. It's important to think about it and make sure we can have a working solution if that happens, but this isn't a short-term need. Le lun. 5 août 2019 à 11:30, fiatjaf a écrit : > 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. > > 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? > > Anyway, I'm probably missing something, but another way of putting my > question would be: why does your example use 2 trampolines instead of 1? > > On Monday, August 5, 2019, Bastien TEINTURIER wrote: > > Good morning fiatjaf, > > This is a good question, I'm glad you asked. > > As:m ZmnSCPxj points out, Alice doesn't know. By not syncing the full > network graph, Alice has to accept > > "being in the dark" for some decisions. She is merely hoping that RT2 > can find a route to Bob. Note that > > it's quite easy to help Alice make informed decision by proving routing > hints in the invoice and in gossip > > messages (which we already do for "normal" routing). > > The graph today is strongly connected, so it's quite a reasonable > assumption (and Alice can easily retry > > with another choice of trampoline node if the first one fails - just > like we do today with normal payments). > > I fully agree with ZmnSCPxj though that in the future this might not be > true anymore. When/if the network > > becomes too large we will likely lose its strongly connected nature. > When that happens, the Lightning > > Network will need some kind of hierarchical / packet switched routing > architecture and we won't require > > trampoline nodes to know the whole network graph and be able to route to > mostly anyone. > > I argue that trampoline routing is a first step towards enabling that. > It's a good engineering trade-off between > > ease of implementation and deployment, fixing a problem we have today > and enabling future scaling for > > problems we'll have tomorrow. It's somewhat easy once we have trampoline > payments to evolve that to a > > system closer to the internet's packet switching infrastructure, so > we'll deal with that once the need for it > > becomes obvious. > > Does that answer your question? > > Cheers, > > Bastien > > Le sam. 3 août 2019 à 05:48, ZmnSCPxj a > écrit : > >> > >> Good morning fiatjaf, > >> > >> I proposed before that we could institute a rule where nodes are mapped > to some virtual space, and nodes should preferably retain the part of the > network graph that connects itself to those nodes near to it in this > virtual space (and possibly prefer to channel to those nodes). > >> > >> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001959.html > >> > >> Thus Alice might **not** know that some route exists between T1 and T2. > >> > >> T1 itself might not know of a route from itself to T2. > >> But if T1 knows a route to T1.5, and it knows that T1.5 is nearer to T2 > than to itself in the virtual space, it can **try** to route through T1.5 > in the hope T1.5 knows a route from itself to T2. > >> This can be done if T1 can remove itself from the trampoline route and > replace itself with T1.5, offerring in exchange some of the fee to T1.5. > >> > >> Other ways of knowing some distillation of the public network without > remembering the channel level details are also possible. > >> My recent pointlessly long spam email for example has a section on > Hierarchical Maps. > >> > >> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002095.html > >> > >> Regards, > >> ZmnSCPxj > >> > >> > >> Sent with ProtonMail Secure Email. > >> > >> ‐‐‐ Original Message ‐‐‐ > >>
[Lightning-dev] Fwd: Trampoline Routing
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. 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? Anyway, I'm probably missing something, but another way of putting my question would be: why does your example use 2 trampolines instead of 1? On Monday, August 5, 2019, Bastien TEINTURIER wrote: > Good morning fiatjaf, > This is a good question, I'm glad you asked. > As:m ZmnSCPxj points out, Alice doesn't know. By not syncing the full network graph, Alice has to accept > "being in the dark" for some decisions. She is merely hoping that RT2 can find a route to Bob. Note that > it's quite easy to help Alice make informed decision by proving routing hints in the invoice and in gossip > messages (which we already do for "normal" routing). > The graph today is strongly connected, so it's quite a reasonable assumption (and Alice can easily retry > with another choice of trampoline node if the first one fails - just like we do today with normal payments). > I fully agree with ZmnSCPxj though that in the future this might not be true anymore. When/if the network > becomes too large we will likely lose its strongly connected nature. When that happens, the Lightning > Network will need some kind of hierarchical / packet switched routing architecture and we won't require > trampoline nodes to know the whole network graph and be able to route to mostly anyone. > I argue that trampoline routing is a first step towards enabling that. It's a good engineering trade-off between > ease of implementation and deployment, fixing a problem we have today and enabling future scaling for > problems we'll have tomorrow. It's somewhat easy once we have trampoline payments to evolve that to a > system closer to the internet's packet switching infrastructure, so we'll deal with that once the need for it > becomes obvious. > Does that answer your question? > Cheers, > Bastien > Le sam. 3 août 2019 à 05:48, ZmnSCPxj a écrit : >> >> Good morning fiatjaf, >> >> I proposed before that we could institute a rule where nodes are mapped to some virtual space, and nodes should preferably retain the part of the network graph that connects itself to those nodes near to it in this virtual space (and possibly prefer to channel to those nodes). >> >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001959.html >> >> Thus Alice might **not** know that some route exists between T1 and T2. >> >> T1 itself might not know of a route from itself to T2. >> But if T1 knows a route to T1.5, and it knows that T1.5 is nearer to T2 than to itself in the virtual space, it can **try** to route through T1.5 in the hope T1.5 knows a route from itself to T2. >> This can be done if T1 can remove itself from the trampoline route and replace itself with T1.5, offerring in exchange some of the fee to T1.5. >> >> Other ways of knowing some distillation of the public network without remembering the channel level details are also possible. >> My recent pointlessly long spam email for example has a section on Hierarchical Maps. >> >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002095.html >> >> Regards, >> ZmnSCPxj >> >> >> Sent with ProtonMail Secure Email. >> >> ‐‐‐ Original Message ‐‐‐ >> On Saturday, August 3, 2019 12:29 AM, fiatjaf wrote: >> >> > Ok, since you seem to imply each question is valuable, here's mine: how does Alice know RT2 has a route to Bob? If she knows that, can she also know T1 has a route to Bob? In any case, why can't she just build her small onion with Alice -> T1 -> Bob? I would expect that to be the most common case, am I right? >> > >> > On Friday, August 2, 2019, Bastien TEINTURIER wrote: >> > >> > > Good morning list, >> > > >> > > I realized that trampoline routing has only been briefly described to this list (credits to cdecker and pm47 for laying >> > > out the foundations). I just published an updated PR [1] and want to take this opportunity to present the high level >> > > view here and the parts that need a concept ACK and more feedback. >> > > >> > > Trampoline routing is conceptually quite simple. Alice wants to send a payment to Bob, but she doesn't know a >> > > route to get there because Alice only keeps a small area of the routing table locally (Alice has a crappy phone, >> > > damn it Alice sell some satoshis and buy a real phone). However, Alice has a few trampoline nodes in her >> > > friends-of-friends and knows some trampoline nodes outside of her local area (but she doesn't know how to reach >> > > them). Alice would like to send a payment to a trampoline node she can reach and defer calculation of the rest of >> > > the route to that node. >> > > >> > > The onion routing part is very simple now that we
