Published on: 2018-11-05T08:11:58+00:00
In a discussion between CJP and Rusty Russell about the proposal for a merchant forward service using rendezvous routing, concerns were raised about the potential exclusion of Bob from the network with more strict regulatory conditions. Rusty acknowledged this concern and suggested that forwarding nodes should be checked to see if they are comfortable with such requests. Rusty then presented a design for the merchant forward service where Alice can remain anonymous from the lightning network by using Bob's forwarding service. Alice would pay Bob and provide him with a path to her node via a short-channel-id and privkey. Anything sent from Bob to this short channel id and pubkey would be forwarded to Alice. The payer would not know about this arrangement and it would appear as if Alice has a private channel with Bob. However, there is a minor downside in that Bob can issue invoices as Alice, but this can be addressed with a separate invoice key in the future.ZmnSCPxj disagreed with the use of rendezvous routing in this scenario as it would still allow Bob to route payments through Alice. Instead, ZmnSCPxj suggested that Alice provides a route from another node to maintain anonymity. In response, Rusty explained that the current protocol assumes source routing, but it may be possible to use rendezvous routing with only the blinding key. Rusty then proposed the "merchant forward" service design for Alice who wants to remain anonymous. Bob's node would offer the forwarding service and Alice would pay Bob for a path to her node. Bob would issue an invoice using Alice's identity and create a new HTLC to pay Alice when payment arrives at his node.In a separate email exchange, CJP raised concerns about a scenario where a powerful participant enforces KYC requirements on Lightning nodes. ZmnSCPxj disagreed with this scenario and suggested that the rest of the network should punish this participant by closing any channel to it. ZmnSCPxj also argued for the desirability of a feature that allows payees to not maintain even a pseudonym on the Lightning network for privacy reasons. CJP countered by saying that for most use cases, a payee pseudonym is needed unless the payment is for donating to random strangers or if it is cryptographically linked to the Lightning payment. They discussed rendezvous routing as a way to decouple the pseudonym from a location in the Lightning network.In an email to CJP, ZmnSCPxj discussed a potential scenario where a powerful participant in the Lightning network starts enforcing KYC requirements on nodes. ZmnSCPxj suggested punishing this participant by closing any channel to it and retaliatory preemptive closing of any channel to any participant connected to that participant. The goal would be to lower its fee earnings and ability to control the network. ZmnSCPxj also advocated for the feature of not requiring payees to maintain even a pseudonym on the Lightning Network for privacy reasons. ZmnSCPxj proposed that if all generated invoices use rendezvous routing, then the payee will not have an identifiable pseudonym on-Lightning. The destination should choose the nodes on its half of the route and pay for fees, while the source only needs to deliver the specified amount to the first hop node of the destination half of the rendezvous route.In the Lightning network, concerns have been raised about some powerful participants enforcing KYC requirements on nodes, which could lead to a split in the network. This goes against the decentralized and inclusive nature of the network. Private channels offer some countermeasures, but their existence needs to be known to payers who need to cross between compliant and non-compliant parts of the network. This risks penalties for node owners on the compliant side. Rendezvous routing may provide a better solution, where the payee chooses routes from certain third-party nodes and passes encrypted blobs to the payer. This allows the payee to lead the route over private channels without revealing their existence and remain anonymous within the compliant section of the network. Alternative approaches, such as not routing between incompatible regulatory domains and instead having separate nodes on each network, may also be considered, but would require on-chain mixing.
Updated on: 2023-07-31T20:38:34.307474+00:00