What is rendezvous routing in Lightning? How does it work and what are the benefits?

"What is rendezvous routing in Lightning? How does it work and what are the benefits?" Rendezvous is a new routing proposal for the Lightning Network. It is a slight twist on the way source routing works, so let me first quickly explain source routing. You have a Lightning node and want to pay another Lightning node on the network. How do you [send] your payment there? One of the advantages for privacy and confidentiality of your Lightning payments... is that the originator / source of the payment decides on the route, which is called source routing. This is different from how the internet works today, although it did work like that in the beginning. Source routing means that if your node knows wants to pay some other [Lightning] node out there, it will use all the information it knows about the public channels broadcast on the Lightning Network. [Then it will figure out] the best way to get [your payment] there for the minimum fee. [It will construct a route from] Node A, to node B, to node C, etc. to node F. It won't just construct one route, but several routes, and then see which one can get a payment through. If / when node F receives the route, then node F will close the loop and the payment will go through. Here is a problem with this model: in the Lightning Network, you have public and private channels. You can set up Lightning channels that are [only] broadcast to [the participants in the channel]. If the source of a payment doesn't know about [these private channels], they can't use them in a route. Private channels are very useful for maintaining privacy, but they will fail with a source routing mechanism. [Source routing] also makes it difficult to maintain a level of privacy for the payer or the payee. Though nobody else knows where the payment is coming from or where the payment is going. Let's use the example with [nodes] A through F again. If you have the perspective of node D in the route, they are receiving the payment from node C, and sending an outgoing payment to node E. Node D doesn't know about node A, node B, or node F. Node D only knows the previous hop (node C) and the next hop (node E). Node D [does not see] where it is coming from (node A) or where it is going (node F). Node D is passing this encrypted blob of routing information to the next node in line. Node D says to node E, 'Here is a payment and encrypted blob which will tell you where to send it next.' Node E may even be the recipient. They may open this encrypted blob and see, 'Oh, the payment is for me.' 'It doesn't need to go anywhere else.' Or they may find [instructions] for [routing] it to more nodes. They will only see one of [the next nodes], [who will be able to decrypt the next layer], and so they keep routing. That is how onion routing works. It is beautiful. If you are in the middle of that route, you have no idea where the payment is coming from and no idea where it will go. All you will see are the two adjacent nodes. You don't know what position you have in that route. You don't know how long the route is. All routes look like they are the same length. It will appear as if you are always the second hop, you can't tell anything else from routing [information]. So what if we could do that with private channels? Node A would obviously know they are paying node F, because they must construct a route to it, but what if node F wanted to be paid anonymously? This is how rendezvous routing works. Node F tells node A, the [sender], that they will pay node E and then provide an encrypted route... to node E about how to get that payment to node F. When node A [sends a payment], they will construct a route to node E. Then part of that [routing information] is sent to node F, without node A knowing where it went. Node E acts as a rendezvous node, a meeting place, between two routes. One route is constructed by the originator node A, and one is constructed by the destination node F. Node A doesn't know who node F is. Most importantly, that means node F can use a private channel to node E. That really makes things interesting in terms of privacy. Rendezvous has some other interesting implications for improving routing conditions. You can generalize this concept and create routing mechanisms that are hybrids. Hybrid [in terms of] the originator [node] deciding how the payment will reach the destination, the [recipient] of the payment deciding how it will reach its destination, and intermediary nodes deciding... how to route the packet. Or some combination where the rendezvous point is closer to the origin or to the destination, with different parts of the route providing privacy guarantees. This will be an exciting new development in Lightning that solves privacy problems with routing. Private channels will be much more usable.

Has routing on the Lightning Network been figured out yet? If not, how far along are we in terms of getting there, and when will that happen?

Quick follow-up question which is asked a lot, especially because there is active propaganda on this topic... by people who have a political agenda against the Lightning Network, rather than technical arguments. "Has routing on the Lightning Network been figured out yet? If not, [how far along are we], in terms of getting there, and when will that happen?" There is a lot of discussion online about [how] 'Lightning Network routing can't work' even though, of course, it does work in practice. [They say] 'it can never work because it is an NP-hard problem,' 'it is a travelling salesman problem,' there is no way to do optimization, or the chosen routing algorithm is the wrong one. The truth is, you can have different opt-in routing algorithms on the Lightning Network, both the ones that exist today as well as the ones that are proposed, or may be developed, in the future. Routing just needs to be optimized appropriately for Lightning as it is now, not what it will be in the future. Routing is done differently depending on the scale, complexity, and connectivity of the [current] network. A network that is not hierarchical but very flat will route differently than the hierarchical network. [A small network] will route differently than a large network, where nodes are connected... to many other nodes or only a few nodes; this all changes the routing characteristics. Routing algorithms will apply at different stages in the maturity of the Lightning Network. Right now, source routing is effective and has strong privacy protections. It doesn't work perfectly, but perfection is not the goal here. The goal is to be able to route payments most of the time, in a way that reduces fees. You [need] a good enough route, not the perfect route. Not always successful, but 'almost' always a successful and efficient route. That is what routing does. It is an optimization strategy. The current strategy works very well for the size and connectivity characteristics of Lightning today. We don't "solve" routing, just as we don't "solve" scaling. As the network changes in size, the problem changes. We should "solve" routing for today's Lightning Network, just like we solve scaling for today's Bitcoin network. Later, the problem will change and arise again. You "solve" it again and again. There is no final solution. What percentage [of the way] are we [to solve routing]? We are at 100% for Lightning's current scale. We are close to 0% for the [rest] of its [lifetime], because the future is infinite and routing problems will change.