People wonder why I dislike monero
Well, I learned how it works
Discussion
Do you think liquid is better than monero?
No
But it has one thing going for it: it leverages a harder money
Thoughts on Bitcoin Silent Payments?
They are neat technology, but it is bad if they make people think it is generally safe to reuse them. It is not. If you use them, you should make a new silent payment address for every service you use, and if it an anonymous service (like a swap service) you should make a new one for each *payment.*
Otherwise you are subject to two attacks:
1. Profiling
A supposedly anonymous service, like a swap service, can create a hidden profile of a user based on the address they send money to. E.g. if I use it twice with the same silent payment address, they can keep a record of that and know that at time A I received $20 and at time B I received $35, because I reused the same silent payment address. Thus they create a hidden profile on me and learn *when* I use their service and *how much* I swap there day to day, which is info they should not know. Mitigating this attack requires creating a new silent payment address for each payment whenever you use an anonymous service like that.
2. The colluding sender attack
This attack also relies on address reuse. In it, two people -- Alice and Bob -- observe that Alice sent $10 to the same silent payment address that Bob sent $5 to. So together they know the same person received at least $15, which they should not know. Ideally, Alice should only know about *her* payment and Bob should only know about *his.* But if I reuse the same address, they can compare notes and learn that both of their payments went to the same person. That's a privacy leak, and to mitigate it, you must not give the same silent payment address to two different people. Make a different one for each such payment.
"You must not give the same silent payment address to two different people." As far as I know, SPs use stealth addresses, so wouldn't that mitigate these types of attacks?
No, stealth addresses do not eliminate the weakness to the profiling attack or the colluding sender attack. Monero addresses and silent payment addresses and bolt12 offers are all weak to these two attacks if reused in the mentioned contexts.
The reason, btw, is because even though the senders *send to* a stealth address, they can log the original silent payment address (or monero address, or bolt12 offer, or in general any reusable payment string) and (1) use that for profiling -- every time someone asks them to send money to it, it's another data point in their profile on that payment string (2) share data with other senders about times when they sent money to that payment string, that way, together, the colluding senders know more than they would know individually
It was a pretty good convo; listened the full 4h live 🙏
Two constructive comments:
1) I think you had some misrepresentation on Phoenix:
-> you cant have channels with other peers than acinq. Thus they know when and how much you are paying and receicing, and since they are your trampoline also the destination. It's a convenient wallet, but not very private.
2) On the UX section: both of you ignored that you can deterministically send any amount with Monero (or any other blockchain for that matter), while with LN the larger the payment the less likely it succeeds. LN payments generally have this 'Please please go through' vibe to it.
That's objectively worse ux
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.
Unrealated to the Space, but have you seen this:
How Lightning’s Routing Diminishes its Anonymity" (ARES 2021)
?
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.
Are you sure you learned it properly?
🤣🤣