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 <c...@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. 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. 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). 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. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
