CJP [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-04 📝 Original message: Imagine a future where ...

📅 Original date posted:2018-11-04
📝 Original message:
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