On twitter, someone wrote this post (slightly modified - original: https://x.com/smspoolnet/status/1941786886902558831):
------------------------
Monero (XMR) > BTC Lightning Network for privacy:
• XMR hides sender, receiver, & amount by default
• All transactions look the same on-chain
• No channel or routing leaks
• No reliance on third parties
• LN privacy is optional & can be broken with analysis
------------------------
My reply:
> XMR hides sender
Not through encryption. It puts them in a list with 15 other random pubkeys and says "one of these is the true sender." Then it publishes that list forever on a blockchain. Chain analysts can often figure out which pubkey is the true spender. In lightning the sender is actually encrypted and nothing is published to a blockchain. This makes it much harder for analysts to identify the sender.
> XMR hides...receiver
Not from the sender. The receiver's XMR address and stealth pubkey are shown to the sender in plaintext, and this makes it possible to do poisoned output attacks to trace monero, i.e. the attacker sends some money to a target and then watches the blockchain to see if the target sends it to someone who knows their identity. This is how many of the targets in the case studies on moneroleaks.xyz got caught. On lightning, by contrast, the sender does *not* know who received the funds, because lightning supports trampoline routing by default, meaning the sender cannot know if the person who *looks* like the recipient is *really* the recipient or just another routing node.
> XMR hides...[the] amount by default
(1) Only part of it. The fee is published in plaintext, and this is useful to chain analysts because they use it for wallet fingerprinting -- e.g. custodial services tend to set higher fees than users of self-custodial wallets do. Lightning, of course, hides the fee better by (a) using encryption so that each routing node only knows the portion of the fee they received (b) not publishing anything about the transaction on a blockchain.
(2) Monero does not hide the mount received from the sender. The sender picks how much to send to the recipient and monero does not support transaction chaining so the recipient cannot modify it. Whereas in lightning, the sender knows how much he *sent,* but due to transaction chaining, he does not know how much the recipient *received.* The recipient may have atomically forwarded all, some, or none of the payment to someone else, and the sender would have no idea. In this respect, LN has better amount privacy than XMR.
> All transactions look the same on-chain
No they don't. Some pay higher fees; some have more inputs; some have more outputs; some use pubkeys as decoys that analysts *know* are decoys (because they control those pubkeys, or their partners do). All of this data is used by analysts for fingerprinting and tracing.
But once again, LN does better here: the data produced by the sender is actually encrypted and padded to 1300 bytes. It looks the same to the routing node as if he was forwarding a payment from someone else. It's *truly* indistinguishable, verifiably, through cryptography.
And that's a major improvement on this metric.
> No channel or routing leaks
Monero uses something with a lot of similarities to routing: dandelion++
They are similar in this respect: both try to hide the sender's ip address by forwarding a packet to someone else, who then forwards it to another node, etc., such that "later" nodes don't know if "prior" nodes are the sender or just another "stem node" (in dandelion++) or "routing node" (in LN). This is actually really good for your privacy, but when LN does it, XMR people call it a leak, whereas, of course, when they do it, it's the best thing since sliced bread.
> No reliance on third parties
There is: if you use dandelion++, the nodes in the stem phase can collude to identify you as either the sender or at least another stem node. This is a leak that LN and XMR both share. But in XMR it's worse, because if you are using a light client (e.g. a phone wallet), you don't actually use dandelion++, instead you pick a random node on the network and use RPC commands to send your transaction, thus doxing your ip address to a random node, possibly one run by chainalysis. That is how one of the people got caught in the Case Studies section of moneroleaks.xyz. Lightning, of course, improves this: you don't pick random nodes on the network to send your transaction to in plaintext, instead you encrypt all your transactions and only show them to a select group of nodes chosen by you when you created your channels. This is way better.
> LN privacy is optional
That's also the case with monero. What wallets do most users pick? Ones like exodus and coinomi and freewallet, which are able to easily log your ip address and associate them with your transactions. (Freewallet is also custodial, so it knows even *more* data.)
Privacy is always optional, and if you're seeking good privacy, LN is the better option.
I am posting a correction thanks to x.com/ofrnxmr, who, on twitter (https://x.com/ofrnxmr/status/1942063609384730641) pointed out a mistake with the following claim:
> if you are using a light client (e.g. a phone wallet), you don't actually use dandelion++, instead you pick a random node on the network and use RPC commands to send your transaction
He said: this is false. You dont use a random node, you use 1 or more nodes that you explicitly choose
I checked in multiple monero wallets and this does indeed seem to be a standard feature. So I was wrong; let this stand as a correction.
> LSPs don't give you privacy from third parties
They do. LSPs cannot identify the sender, the recipient, the amount sent, or any of their users' base layer utxos. That's pretty good.
> All of those cases involve KYC exchanges, colluding with swap services when they swapped to transparent chains like Bitcoin, and opsec mistakes where they revealed their IP address. Nothing to do with transacting on Monero.
You named 3 elements of the traces in the cited cases and then said that "nothing" involved the targets' XMR transactions. But you ignored the other elements of the traces, some of which *did* involve the targets' monero transactions.
- In the case of the Columbian drug dealer, they were unable to get his ip address until *after* they traced his monero from the initial address, past an additional hop (possibly a churn), and *then* he leaked his ip address in a subsequent transaction. To trace the flow of funds through the possible-churn, they had to use the decoy elimination attack, which would not be possible except that monero opts to use decoys instead of encryption to protect sender privacy. That's "something to do with transacting on Monero."
- In the case of Incognito Market, they used (1) the tx time that is revealed in every monero transaction and (2) the amount information that is revealed to the two parties involved. That allowed them to correlate his "buy" transaction with his "sell" transaction despite him moving the funds through a monero wallet before selling them. That's "something to do with transacting on Monero."
- In the Finnish case, the Japanese case, the Archetyp case, and the Bitfinex case, the authorities acquired the targets' private keys. Then they could simply look up their transaction history on the blockchain and trace the flow of funds that way. Why? Because monero provably and permanently links the history of all of your transactions to your private keys. Unlike lightning, monero does not let you delete your transaction history. That's "something to do with transacting on Monero."
So you're wrong. All of the cited cases involve the things you mention *as well as* other things that do involve transacting on monero, and the data leaked by doing so.
On twitter, someone wrote this post (slightly modified - original: https://x.com/smspoolnet/status/1941786886902558831):
------------------------
Monero (XMR) > BTC Lightning Network for privacy:
• XMR hides sender, receiver, & amount by default
• All transactions look the same on-chain
• No channel or routing leaks
• No reliance on third parties
• LN privacy is optional & can be broken with analysis
------------------------
My reply:
> XMR hides sender
Not through encryption. It puts them in a list with 15 other random pubkeys and says "one of these is the true sender." Then it publishes that list forever on a blockchain. Chain analysts can often figure out which pubkey is the true spender. In lightning the sender is actually encrypted and nothing is published to a blockchain. This makes it much harder for analysts to identify the sender.
> XMR hides...receiver
Not from the sender. The receiver's XMR address and stealth pubkey are shown to the sender in plaintext, and this makes it possible to do poisoned output attacks to trace monero, i.e. the attacker sends some money to a target and then watches the blockchain to see if the target sends it to someone who knows their identity. This is how many of the targets in the case studies on moneroleaks.xyz got caught. On lightning, by contrast, the sender does *not* know who received the funds, because lightning supports trampoline routing by default, meaning the sender cannot know if the person who *looks* like the recipient is *really* the recipient or just another routing node.
> XMR hides...[the] amount by default
(1) Only part of it. The fee is published in plaintext, and this is useful to chain analysts because they use it for wallet fingerprinting -- e.g. custodial services tend to set higher fees than users of self-custodial wallets do. Lightning, of course, hides the fee better by (a) using encryption so that each routing node only knows the portion of the fee they received (b) not publishing anything about the transaction on a blockchain.
(2) Monero does not hide the mount received from the sender. The sender picks how much to send to the recipient and monero does not support transaction chaining so the recipient cannot modify it. Whereas in lightning, the sender knows how much he *sent,* but due to transaction chaining, he does not know how much the recipient *received.* The recipient may have atomically forwarded all, some, or none of the payment to someone else, and the sender would have no idea. In this respect, LN has better amount privacy than XMR.
> All transactions look the same on-chain
No they don't. Some pay higher fees; some have more inputs; some have more outputs; some use pubkeys as decoys that analysts *know* are decoys (because they control those pubkeys, or their partners do). All of this data is used by analysts for fingerprinting and tracing.
But once again, LN does better here: the data produced by the sender is actually encrypted and padded to 1300 bytes. It looks the same to the routing node as if he was forwarding a payment from someone else. It's *truly* indistinguishable, verifiably, through cryptography.
And that's a major improvement on this metric.
> No channel or routing leaks
Monero uses something with a lot of similarities to routing: dandelion++
They are similar in this respect: both try to hide the sender's ip address by forwarding a packet to someone else, who then forwards it to another node, etc., such that "later" nodes don't know if "prior" nodes are the sender or just another "stem node" (in dandelion++) or "routing node" (in LN). This is actually really good for your privacy, but when LN does it, XMR people call it a leak, whereas, of course, when they do it, it's the best thing since sliced bread.
> No reliance on third parties
There is: if you use dandelion++, the nodes in the stem phase can collude to identify you as either the sender or at least another stem node. This is a leak that LN and XMR both share. But in XMR it's worse, because if you are using a light client (e.g. a phone wallet), you don't actually use dandelion++, instead you pick a random node on the network and use RPC commands to send your transaction, thus doxing your ip address to a random node, possibly one run by chainalysis. That is how one of the people got caught in the Case Studies section of moneroleaks.xyz. Lightning, of course, improves this: you don't pick random nodes on the network to send your transaction to in plaintext, instead you encrypt all your transactions and only show them to a select group of nodes chosen by you when you created your channels. This is way better.
> LN privacy is optional
That's also the case with monero. What wallets do most users pick? Ones like exodus and coinomi and freewallet, which are able to easily log your ip address and associate them with your transactions. (Freewallet is also custodial, so it knows even *more* data.)
Privacy is always optional, and if you're seeking good privacy, LN is the better option.
"Unusable" except by the folks who arrested monero users in a bunch of different cases
Look at the Case Studies section: moneroleaks.xyz
Yes I do, and since it is a very leaky medium, I criticize monero for putting so much data on it
Please point to something misleading on it
It would fit nicely on Seth's fungibility graveyard
But moneroleaks.xyz is a site about tracing monero, not about tracing bitcoin
Apparently Eclair supports this
After reviewing the bolt12 spec (https://github.com/lightning/bolts/blob/master/12-offer-encoding.md) I find that bolt12 offers are less private than I thought. The spec says a bolt12 offer "MUST set offer_issuer_id to the node's public key" unless it is "connected only by private channels." This design seems like a misguided specification for anyone whose goal is to conceal their node id. I recommend against using any bolt12 generator that reveals your node id. But the spec seems to *want* nodes to do that, so I'm not sure there are any that attempt to conceal that data. Not sure what to recommend here except maybe just don't use bolt12 until its privacy protections improve, or an implementation comes out that avoids revealing your node id.
Apparently I misread the spec. Someone highlighted this set of phrases:
```
if it includes offer_paths:
MAY set offer_issuer_id.
otherwise:
MUST set offer_issuer_id to the node's public key to request the invoice from.
```
Then they pointed out the direct implication: if you include an offer path (aka blinded path) you do not have to set offer_issuer_id at all
So the spec does not say the only exception is if you are connected only by private channels; a broader exception is there: use blinded paths.
Related lyrics, I asked if Eclair's implementation of bolt12 hides your node id when creating a bolt12 offer with blinded paths, and the docs seem to say it does:
```
If you specify blindedPathsFirstNodeId, your public node id will not appear in the offer: you will instead be hidden behind a blinded path starting at the node that you have chosen. You can configure the number and length of blinded paths used in eclair.conf in the offers section.
```
There are lots of larpers in bitcoin, because you aren't a real bitcoiner unless you larp as one
After reviewing the bolt12 spec (https://github.com/lightning/bolts/blob/master/12-offer-encoding.md) I find that bolt12 offers are less private than I thought. The spec says a bolt12 offer "MUST set offer_issuer_id to the node's public key" unless it is "connected only by private channels." This design seems like a misguided specification for anyone whose goal is to conceal their node id. I recommend against using any bolt12 generator that reveals your node id. But the spec seems to *want* nodes to do that, so I'm not sure there are any that attempt to conceal that data. Not sure what to recommend here except maybe just don't use bolt12 until its privacy protections improve, or an implementation comes out that avoids revealing your node id.
I think so, but it might be good to find out why you want to avoid letting them know your node pubkey in the first place. I initially assumed you wanted to do this because bolt12 offers reuse the same pubkey multiple times, which is bad for privacy. But rather than use a proxy, a simpler way to fix that is to make a new bolt12 offer after every payment. Bolt12 generators tend to make a new pubkey for each offer you generate.
No. Maybe I should make a clone of rack.supertestnet.org but for bolt12
Ocean graduated to >1%. The used to be in "other," now they have their own slice of the pie chart
source: https://mempool.space/mining
Hashers, switch to Ocean!
- you make more money
- you filter out spam (if you choose to)
- you have greater control over your blocks
- Ocean currently has almost 10 exahash
- if they get to 14 exahash they will be securely a top 10 mining pool
does Tether have a mining pool that contributes hashrate to Ocean?
does Tether have a mining pool that contributes hashrate to Ocean?
does Tether have a mining pool that contributes hashrate to Ocean?
does Tether have a mining pool that contributes hashrate to Ocean?
Hashers, switch to Ocean!
- you make more money
- you filter out spam (if you choose to)
- you have greater control over your blocks
- Ocean currently has almost 10 exahash
- if they get to 14 exahash they will be securely a top 10 mining pool
Ocean graduated to >1%. The used to be in "other," now they have their own slice of the pie chart
source: https://mempool.space/mining
Follow nostr:nprofile1qqs0x0y2jctuk90hqh78pn2xrn7katezl83ycvl2htvczeywtmr0wsg5xl5w4 for more content like this