He's wrong about unencrypted receiver (or meant something else) but LN nodes only see MINIMUM amount, not total amount because of multi paths. And funnily enough, large nodes provide better privacy if they are honest. So if you use several large hubs and at least one of them is honest it's pretty good. (But there are some issues being worked on.)

Also ~90% Monero users use Coinomi or similar wallets that scan their entire wallets so you have the same problem with the difference that people don't talk as much about it.

Reply to this note

Please Login to reply.

Discussion

>"...LN nodes only see MINIMUM amount, not total amount because of multi paths"

Multi path payments is optional for every wallet I've tried that even has it available (same with things for wrapped invoices/blinded paths/bolt12). That's the problem when these things aren't default very few will use them.

"...And funnily enough, large nodes provide better privacy if they are honest."

The whole point is not requiring trusted third parties to insure your privacy. Otherwise it's just offering the same privacy of a traditional bank.

The last part is not true. All the popular Monero wallets are non-custodial (GUI/CLI, Cake, Monerujo, Stack, Feather) and don't have your viewkeys. That's why you have to spend time syncing your wallet every time you open it. I've never seen anyone even mention the word Coinomi much less recommend them.

It doesn't matter that it's optional. The node in the middle doesn't know if it's turned on or not, so it cannot know if it sees the full amount or not.

Monero also requires trusting that the other 14 keys are not held by the same entity or cooperate to deanon you. This is true for any privacy system and impossible to avoid.

14 is arguably higher than the usual length of payment path in LN, so I'll give you that but it's stilk not infinite and making LN path 14 nodes long is still possible.

You might be in a different social bubble, I've seen many people use Coinomi and recommend it. But that was a long time ago, maybe it has changed.

A significant problem with Monero is that it requires scanning whole chain, which will get expensive as more users come, pushing people to send view keys to scanning services.

Compared to that, you only need block filters to scan bitcoin and then just handle the channel.

The irony of Monero is that the more people use it the more some privacy breaks and other improves.

If a node guessed it was the full amount passing thru it would be right most of the time. If many transactions are passing through large hubs (because they are well connected and require less hops to the destination = more likely to succeed and cheaper) an adversary could collect quite a lot of info on the network. But sure it existing gives some plausible deniability. If it was made default that would be even better.

>"Monero also requires trusting that the other 14 keys are not held by the same entity or cooperate to deanon you."

You mean 15 decoys? That only applies to senders and every spend exponentially decreases the likelihood of being denon'd. Also, you don't have to trust others not being the same entity/colluding for reciever or amount privacy on Monero (both technically possible with LN if the nodes on your routes are colluding, but very unlikely)

>"This is true for any privacy system and impossible to avoid."

It's not true. Cryptographic accumulators are not really affected by the problem you describe because you're proving you're one of the global set of all transactions instead of a tiny subset - which is what will FCMP be.

I've been around many different Monero communities/forums/groups for years and I've never heard Coinomi before. Not sure who recommended it to you but that is not the norm at all. It's usually Cake, Monerujo, Feather, or the GUI/CLI.

Yes, scanning can be annoying, but that is what guarantees no one but you can see your transactions (any proper LN privacy wallet, like Zeus, also requires scanning). If you use it somewhat often it's not really a big deal. Wallets with periodic background scanning make this a non-problem. You are always caught up (or very close). You should check it out on Cakes new update. It's very new so I'm sure in time more wallets will adopt it.

The only Monero wallet left that holds users viewkeys to eliminate sync time, at the cost of some privacy, is Exodus I believe. There used to be another one MyMonero but it's been defunct for quite a long time.

Block filters only help privacy when querying, not when broadcasting a transaction.

Not sure what you meant by the last part. Generally more people using something means a larger anonymity set.

I've grown to appreciate Lightning more, but there are a lot of nuances to both. We could talk about them forever.

> Multi path payments is optional for every wallet I've tried that even has it available

Which wallets have you tried? It's built into LND and turned on by default. So any wallets based on LND should just do it.

E.g. most custodial wallets as well as most nodes-in-a-box (Umbrel, Start9, etc.), plus many mobile phones like Breez, Zeus, Blixt, Bitkit, and ShockWallet.

Multipath payments are also turned on in electrum by default and I suspect they are turned on in the other implementations by default too

I checked the Core Lightning github and multipath payments are "on" by default there too. See, for example, this issue: https://github.com/ElementsProject/lightning/issues/3926

It involved an error report where a user encountered this entry too many times in their error logs:

"Detected large payment, splitting into 100 sub-payments"

I checked the Eclair github too and multipath payments are "on" by default whenever trampoline routing is used (which is the case in Phoenix, which always uses Acinq as a trampoline node)

https://github.com/ACINQ/eclair/blob/826284cb277c28c7eef14aa275f3d6e3255c8e66/eclair-core/src/main/scala/fr/acinq/eclair/payment/send/TrampolinePaymentLifecycle.scala#L112

Thanks for the info. Appreciate you bringing the receipts.

I mostly use Zeus now when I use Lightning (which isnt very often), and Atomic Multi Path is optional on it. I just realized I was confusing AMP with MPP. They do similar things but seems like AMP is an improvement over MPP. I haven't checked other LN wallets in quite awhile. Good to be proven wrong and see MPP is on by default more than I previously thought 🔥

IIRC MPPs are quite frequent for a while. But TBH I never looked into it closely.

Yes, I mean decoys. You do have to trust them. The only difference is what number of interactions you need to have sufficient confidence that there is a sufficient number of honest participants.

Even with accumulators you're still trusting. The only difference is that the parameter becomes all users which is really good and efficient but effectively homomorphic with just using everything as decoy or using every single LN node in path.

As long as you believe that for some number of participants it's safe enough it's OK.

I heard Coinomi suggested to newbies because it had a bunch of other shitcoins as well as btc.

LN doesn't require scanning comparable with Monero. It only requires block filters which are comparatively smaller and only for channel states, not for every transaction. That's orders of magnitude difference.

In LN broadcast privacy is only an issue for initiators and only if they don't use Tor, which is trivial to enable these days.

More people increase anonset but make scanning more expensive pushing people towards revealing their view keys to third parties. There are also obscure probabilistic attacks that are only possible because anonset is high. But once FCMP is no longer vaporware they indeed cease to exist.

Yes, Super Testnet corrected me on the MPP thing earlier.

Sure, I agree, but decoys only apply to the sender. Receivers are always the anon set of every Monero user since they are only ever seen once on the blockchain as a receiver (effectively ZK).

I think you're technically right about the accumulator thing now that I think about it...if you're the only one using the accumulator, and the rest are colluding adversaries, they would know when it's you. But once you have a handful of honest users you cant be picked out among them. So much better like you said.

Maybe you're right about the LN scanning. It always just felt to me that it took about the same time to sync Zeus compared to my Monero wallet. Maybe I use it more than the average user so don't usually have to wait long. But even so background sync basically eliminates this issue.

Not sure why you think the view keys thing is popular. None but maybe two wallets support giving your view keys up to a third party, they're not popular, and it is pretty frowned upon by the Monero community. I've never seen anyone recommend them. If you really wanted to eliminate sync times, without giving up your view keys to a third party, you could connect to your own LWS or, more realistic for most, simply use Cake and enable background sync. Huge UX upgrade.

> He's wrong about unencrypted receiver (or meant something else)

I meant what I said: monero does not encrypt the receiver. If it did, monero devs could tell me what encryption standard they use (in lightning, we use the Sphinx encryption standard specified in bolt4) and they could point me to the code where the recipient's key gets encrypted (in lightning, that code is here: https://github.com/lightningnetwork/lnd/blob/b068d79dfbd2f583d890fd605953d0d4fb897a27/htlcswitch/hop/iterator.go#L114)

Monero does not encrypt the recipient's public key -- it gets published in plaintext on the blockchain -- so the protocol does not specify any encryption standard for that and there is nothing in the codebase where it gets encrypted.

Maybe technically it's more like hashing? Regardless, the practical effect is the same since it's a string of indecipherable and seemingly random characters that are seen once and never again. Third parties can't link a stealth address to a public address off-chain or to any other stealth address.

It's diffie-helman which does involve hashing but only as a layer of protection and the most significant thing doing the unlinking is the diffie-helman computation.

Alright, that's true. But it's not a good argument against Monero privacy because the link between UTXO and the receiver is still hidden from third parties and the link between receiver and his subsequent receiver is also hidden from the sender. The link between sender's sender and the sender is somewhat obscured, as you said with probability 1/15.

I do agree that LN has better privacy than Monero, but using bad arguments doesn't help anyone.