CJP [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-04 📝 Original message: ZmnSCPxj schreef op zo ...

📅 Original date posted:2018-11-04
📝 Original message:
ZmnSCPxj schreef op zo 04-11-2018 om 14:34 [+0000]:
> Good morning CJP,
>
> I believe this is a desirable feature, although...
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, November 4, 2018 2:26 PM, CJP <cjp at ultimatestunts.nl>
> wrote:
>
> > 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.
> >
>
> For this particular scenario, it seems to me that it would be better
> for the rest of the network to punish this participant by closing any
> channel to this KYC-requiring participant, and also to do retaliatory
> preemptive closing of any channel to any participant publicly
> connecting, directly or indirectly, to that participant.  Or in
> short, to let that participant enforce whatever it wants to
> close.  This will greatly lower its fee earnings as well as its
> ability to monitor or control the network.  If every Lightning node
> refuses to reveal their identity (etc.) to this participant, then the
> participant will close all its channels and it will no longer be a
> powerful **participant** of Lightning, thus removing itself and its
> influence from Lightning in the most satisfying way possible, i.e.
> through shooting itself in the foot.

I disagree: you may not be in a position to freely close such channels
and remove your ability to transact with this party, similar to how you
may not be in a position to refuse to pay taxes. Also, since it is hard
to avoid (in the current situation) that some Lightning nodes have a
known link to legal entities like companies or persons, there are ways
outside the Lightning network to put pressure on node owners,
especially non-pseudonymous high-profile ones. This is, however, a non-
technical discussion; since we already agree on the desirability of the
feature, I suggest to keep it at this and focus on the technical
details.

> Nonetheless, I believe this feature is desirable, not for the above
> scenario, but simply so that a payee is not required to maintain even
> a pseudonym on the Lightning Network (the payee will still have to be
> somehow contactable so it can generate an invoice somehow, but at
> least it will not even have an identifiable pseudonym on-Lightning;
> perhaps it may have a pseudonym on some other network with better
> privacy).  If all its generated invoices use rendezvous routing, then
> while it, obviously, must have a Lightning node somewhere, that node
> is not easily identifiable among all Lightning nodes.

I guess that for most use cases a payee pseudonym is needed, unless
your use case is donating to random strangers. I only found one
exception: where the thing you pay for is cryptographically linked to
the Lightning payment (effectively, an atomic swap, like in a
Lightning-based decentralized exchange). In that case, a truly
anonymous (as opposed to pseudonymous) payee makes sense.

However, for use cases where the payee needs a pseudonym, it might
still be desirable to decouple that pseudonym from a location in the
Lightning network. Rendezvous routing can do that.

> Looking through BOLT 4, the text assumes inherently that source
> routing is done, and even has a shared secret between hop and
> source.  However, it may be possible in rendezvous routing to simply
> provide the blinding key (while hiding everything beyond the first
> hop on the destination half of the route).

Sounds like it makes sense; I need to look into it.

> I also think that, as the destination is choosing the nodes on its
> half of the route, that it should pay for fees, and thus the source
> is only required to deliver the specified amount to the first hop
> node of the destination half of the rendezvous route.

Agreed. The price agreed between payer and payee is the incoming amount
at the rendezvous point. In the "original" case that the payee-side
route is 0 hops long, the payee is the rendezvous point, and we're
equal to the original concept where the agreed-on price is the incoming
amount at the payee.

CJP