Unrealated to the Space, but have you seen this:
How Lightning’s Routing Diminishes its Anonymity" (ARES 2021)
?
Thank you for the compliments and criticism
(1) I do not claim that phoenix lets you have channels with peers other than Acinq, but I do claim that it's possible to route payments to other people without Acinq being able to detect it. I've demonstrated the feasibility and profit-potential of doing so in this video: https://www.youtube.com/watch?v=oWBX68_2TQo
Since any user can do this without detection by Acinq, Acinq has to add a caveat to all of their assumptions about the sender of a payment: "This user is the sender, unless he is forwarding someone else's payment." <-- that means they do not know the sender
Regarding the destination, Acinq does not know that either, thanks to the existence of rendezvous routing, as demonstrated by lnproxy (for bolt11) and CLN (for bolt12). They can look up info about the pubkey in a bolt11, but since that pubkey might belong to someone other than the destination, they have to add a caveat to all of their assumptions about the destination of a payment: "This pubkey belongs to the destination, unless it is a rendezvous node." <-- that means they do not know the destination
They do know the amount sent (since they only allow one channel), though, and that is one area where you admittedly have a privacy degradation by using phoenix.
(2) "That's objectively worse ux" <-- yes, on that one aspect of UX. But there are many aspects to UX and just because monero wins on one of them does not mean it wins on all of them, or even most of them. Had my opponent thought to bring this point up, I would concede that monero has better UX than lightning in this one respect, but I would not have conceded that it has better UX than lightning "in general," for the reasons I gave in the debate.
Discussion
I haven't seen that particular paper before, thank you for sharing it. I observe that it was published 4 years ago and new privacy preserving techniques are available now. In particular, I think the paper makes assumptions that are no longer reliable. One of them is revealed in this sentence:
"This attack is possible for any source routing protocol using shortest paths or similar selection strategies." (page 2)
Thanks to the existence of rendezvous routing (as implemtented in bolt12, bolt11 Blinded Routes, and lnproxy), many source-routed payments no longer use the shortest path to the destination. Indeed, when those protocols are used, the sender does not *know* the destination.
Another unreliable assumption is revealed in this paragraph:
"Identifying [either party] reveals information about buying and selling habits to [the attacker]. While [the attacker] might not know the exact transaction value as it only sees the transaction with fees included, these fees are typically low so that the order of magnitude of the transaction value is indeed revealed." (page 5)
When this paper was published, LND supported multipath payments for over a year. So it was already unreliable to assume any given HTLC reveals the order of magnitude of the total value transferred in the corresponding payment, because when MPP is used, multiple in flight HTLCs may carry different parts of the payment. LND uses up to 16 shards, so one can only reasonably conclude that a given HTLC reveals something like 1/16th of the total value transferred, which is an order of magnitude different from their assumptions.
I also think the paper is weak for assuming that senders and recipients are always public nodes: “We use a snapshot of the Lightning Network obtained in June 2020…[The] network [has] 4791 nodes and 28997 channels. We randomly distributed the capacity between the endpoints of each channel…[and] the sender and recipient for each transaction [were] assigned randomly…” (page 6)
By assigning the sender and recipient to only the publicly known nodes, they exclude all unannounced nodes, i.e. all nodes that do not route payments, and they greatly contract the size of the graph. That makes it much easier for them to guess senders and recipients.