 What is rendezvous protocol in Lightning? How does it work? What are the benefits? A new routing example is possible with the Lightning network, which is a slight twist on the way source routing works. Let me first explain source routing very quickly. You have a Lightning node. You want to pay another Lightning node somewhere else in the network. How do you get your payment there? One of the advantages for privacy and for the confidentiality of your payment in Lightning is that... the origin or the originator of the payment gets to decide the route. That is called source routing, because the source of the payment makes the routing decisions. This is different from how the internet works now, although it did work like that in the beginning. So, source routing means that your node knows it wants to pay some other node out there, and it is going to use all of the information it knows about the public channels that are being broadcast on the Lightning network. In order to say, the best way to get there for the minimum fee is A, B, C, D, E, boom. That way it can get to node F. For A to F, it is going to construct this route, A, B, C, D, E, F. In fact, it doesn't just construct one route, it will construct several routes and see which one can get a payment through. If and when F receives the paid route, then F will close that loop, and the payment will go through. Here is the problem with this model. In Lightning network, you have public and private channels. You can set up channels in Lightning that are not advertised to anyone, that are not broadcasted only you know. However, if the source of a payment doesn't know about a route, they can't use it. Private channels are very useful for maintaining privacy, but they fail when the routing mechanism is source routing. It also makes it very difficult to maintain a level of privacy towards the payer or the payee. Nobody else knows where payment is coming from or where payment is going. Let's take that example of the route again. A, B, C, D, E, F. If you take it from the perspective of D, they are receiving an incoming payment from C, the node before it, and they are sending an outgoing payment to E. They don't know about A and B, they don't know about F. As far as they are concerned, they only know the immediate previous hop, C, and the immediate afterwards hop, the next hop, or E. D only sees where it is coming from, where it is going, and they are passing this encrypted blob of information that has more routing information for the next person in line. D says, hey, node E, here is a payment, and here is an encrypted blob that tells you where it goes next. In fact, E may actually be the recipient, and they may open the encrypted blob and say, oh, actually, it's for me, it's not going anywhere next. Or they open the encrypted blob, and there are another ten nodes, but they only see one of them, and more encrypted blobs that they have to keep routing. That's how onion routing works, and it's beautiful in that if you're in the middle of that route, you have no idea where payment is coming from, you have no idea where it is going, all you see is the two adjacent nodes, you don't know where you are in that route, which position you have in the route, and you don't know how long the route is. All routes look like they're the same length, and it looks like you're always the second hop. You can't really tell anything from the routing. So, what if we could do that with private channels? Now, if A is constructing this, then A obviously knows that they're paying F, because they have to construct a route to it. What if F wanted to get paid anonymously? So, this is how round-devil routing works. F actually tells A, the payer, that they're going to pay node E, and they then provide an encrypted route to E on how to get that payment all the way to F. So, when A pays, they construct a route to E, and then the encrypted part of that route gets the payment to F without A knowing where it's going. So, E acts as a round-devil node, a meeting place between two routes, one which is constructed by the originator A, and one which is constructed by the destination F, so that A doesn't know who F is or how to get to them. Most importantly, that means F can use private channels to get from E to F, that A doesn't know about. That really makes things very interesting in terms of privacy. Round-devil has some other interesting implications for improving routing conditions, because you can generalize this concept and really create routing mechanisms that are hybrid, hybrid from the origin of the payment decides how to get there, the destination of the payment decides how to get there, an intermediary node decides how to route the packet, or some combination where the round-devil point is closer to the origin or closer to the destination with different parts of the route provided by different people with different privacy guarantees. So, an exciting new development in lightning solves routing problems, solves privacy problems, makes private channels much more usable, and really an exciting development. Quick follow-up question, and this comes up a lot, especially because there's active propaganda on this topic by people who have primarily political agenda against lightning network, rather than a technical argument against it, which is, Deepak asks, would you say that routing in lightning network has been figured out yet, and if not, what percentage of the way are we in terms of getting there, and well, will that happen in your opinion? There's a lot of discussion online about the fact that lightning network routing doesn't work, or can't work, even though, of course, it does work in practice, or it can never work because it's an NP-hard problem, or it's a traveling salesman problem, or because there's no way to do optimization, or the routing algorithm that's been chosen is the wrong one. The truth is that on lightning network, you can have different routing algorithms, and these routing algorithms, both the ones that exist today, as well as ones that are proposed, as well as future ones that may be developed, need to be appropriate for lightning as it is now. You never optimize for something that's going to happen in the future, you optimize now. Routing efficiently is done differently, depending on the scale, complexity, and connectivity characteristics of the network. A network that is not hierarchical and very flat routes differently than a network that's more hierarchical routes differently than a network that's very large versus a network that's very small, that has nodes that are connected to many other nodes or only a few nodes. All of these change the routing characteristics, so different routing algorithms will apply at different stages in the maturity of lightning network. Right now, source routing is effective, it has strong privacy protections, and it works. 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, or gives you a good enough route, not the perfect route, and not always successful, but almost always successful, and almost always an efficient route. That's what routing does, it's an optimization strategy, and the current strategy works very well for the size and scale and connectivity characteristics of the lightning network today. We don't solve routing, just like we don't solve scaling, because as the network changes in size, the problem changes. We solve routing today for today's lightning network, just like we can solve scaling today temporarily for bitcoin, and then later the problem is going to arise again as the problem changes, and then you solve it again, and again, and again, and there is no final solution. So what percentage are we? We're 100% for the current scale of the network in terms of solving routing, and we're 0% for the future, because the future is infinite, and the routing problem will constantly change.