[Lightning-dev] Proposal for rendez-vous routing

Imagine a future where some powerful participant in the Lightning network starts enforcing KyC requirements on Lightning nodes. It requires its direct neighbors to reveal their identity or else closes channels to them. Next, it asks its direct neighbors to reveal the identity of their direct neighbors (or close their channels), with the threat of either channel closure, or (using the now-known identity) more extreme penalties. I guess this would lead to a split of the Lightning network into a compliant and a non-compliant part, with no ability to perform payments between the two. If we want to keep the Lightning network inclusive, anonymous and free of central authorities who can impose arbitrary rules, this is an undesirable scenario. The enabler of this scenario is the fact that, to allow source routing, we need a public channel map of the network. We have a sort-of-a counter measure called "private channels", which are channels that exist, but whose existence is not published. A private channel might bridge the gap between a compliant and a non- compliant part of the network, but it has a problem: in order to allow payments from one side to the other, the payer has to know about the private channel. If there are lots of payers who have to cross the gap and use the private channel, the existence of the private channel will leak out sooner or later. The node owner on the compliant side of the private channel, presumably having violated the rules by operating a private channel, risks penalties. Therefore, I think private channels are not a very suitable way to keep the network undivided and inclusive and to bridge the gap between different regulatory/non-regulatory domains. I propose another solution: rendez-vous routing. The idea is that the payee chooses one or more routes from certain third-party nodes in the network to himself and passes sphinx-encrypted blobs for those routes to the payer (for instance, as part of a payment request). The payer completes the route by finding routes from himself to those third-party nodes, and tries to perform the payment over these routes. Of course, payee has to tell payer how many hops payer may add to a route, somewhat revealing how much privacy payee wants for himself. I believe this approach has the following properties: * It is a superset of the regular approach to routing: the old approach is simply the special case where payee defines 0 of the 20 hops. * Payee may lead the route over private channels without revealing the existence of those private channels to payers. Of course the private channel still needs to be known to payee; it is probably most realistic that such private channels are operated by payee himself. * The payee node may still be a node inside the "compliant" section of the network; it's just that nobody (not even payer) can see which node it is. So, even when your node is linked to your identity, your activities (even as payee) are not linked to your identity. I guess we already discussed this before, but I just wanted to have a clear place to discuss this idea, and I couldn't find any clear past discussion about this in the mailing list. There might be alternative approaches, such as not routing between incompatible regulatory domains, but simply having nodes on each network if you need to, and simply move funds on-chain between your nodes whenever needed. That will require on-chain mixing though. CJP