Questions About XMR Privacy

Hello, I’ve installed cryptocurrency wallets, but too many questions stuck in my head. These questions may be numerous and silly, I’m really appreciate any help.

Here is my payment flow and questions about XMR:
BTC KYC exchange → BTC Core Wallet → exchange for XMR → Feather Wallet → pay for goods [or exchange back to BTC → Sparrow Wallet → pay for goods]

  1. When spending XMR, do I need to manually select UTXOs/stealth addresses and manually set the change address?

    1. Or can I simply spend the funds and let the wallet automatically select multiple UTXOs and generate a change address, without harming my privacy?
    2. If a transaction requires multiple UTXOs, do I need to consolidate them into a single address first, or can I spend them directly and let the wallet automatically select funds from multiple addresses?
      1. If I consolidate them, should I send them all to the consolidation address at once, or should I send them there one by one?
  2. When receiving XMR from a KYC platform, should I perform churning (sending the funds to another address or another wallet), or can I spend them directly?

    1. When churning, should I use different wallet software, or is it sufficient to send the funds between subaddresses in the same wallet?
      1. Does XMR have a wallet-fingerprint issue similar to BTC? Can an outside observer analyze whether the same wallet software was used?
    2. Should I churn multiple KYC UTXOs all to another address at once, or should I do them one by one?
    3. Should I do churning several times? Would performing more rounds provide greater privacy benefits?
    4. Should I wait for a certain amount of time between multiple churning? What would be a reasonable waiting time?
    5. Once full chain membership proofs are introduced, will churning become completely Useless? If I receive 10 XMR UTXOs from a KYC exchange, I can spend it all in a single transaction without consolidating or churning?
  3. When an XMR wallet software is connected to my own self-hosted Monero node, are transactions broadcast by the wallet software or by the Monero node?

  4. Regarding the process of exchanging XMR back to BTC and sending it to Sparrow

    1. For the “BTC Core Wallet → Feather Wallet” step, I plan to exchange a somewhat larger amount in advance for future purchases, to avoid being linked through transaction amounts
    2. For the “Feather Wallet → Sparrow Wallet” step, would it be a problem to exchange only exactly the amount needed each time and spend the entire amount immediately (avoid dealing with change)? Or would it be better to exchange more BTC in advance and spend only part of it, leaving the rest for future purchases?
  5. When using Whonix + Feather Wallet, do I need to configure Stream Isolation? Which of the following approaches should I use?

    1. Method one: configure it through a SOCKS proxy

    2. Method two: configure it through a Tor proxy

    3. Method three: leave the default settings and let Feather Wallet handle Stream
      Isolation itself, since Feather Wallet is a Tor-friendly application?

  6. Are there any other particularly important precautions or practices I should be aware of? Hello, I’ve installed cryptocurrency wallets, but too many questions stuck in my head. These questions may be numerous and silly, I’m really appreciate any help.

Maybe I’m asking too many questions, and that makes it inconvenient to help.
Would creating multiple separate topics, one for each question, violate the rules?

yes, 20+ new topics would be a bit spammy

I need to ask 10 questions, is that okay?

I’m a long-time Monero dev, and just happened to see this post.

When spending XMR, do I need to manually select UTXOs/stealth addresses and manually set the change address?

Every output on the blockchain is unique and not connected to your address (assuming ECC/ed25519 is not broken). Every “change address” is also unique. You really don’t need to do anything, except for maybe UTXO selection (typically referred to as “coin control”). After FCMP++ fork, coin control is also not needed.

Every transaction contains a public-key for an ECDH operation. This operation allows both wallets (sender and receiver) to “find” the secret keys of the new UTXOs. As hinted at previously, there is no connection to any address that you give to others on the blockchain. The downside is that each wallet must perform cryptographic operations on every transaction to determine if funds were received.

If a transaction requires multiple UTXOs, do I need to consolidate them into a single address first, or can I spend them directly and let the wallet automatically select funds from multiple addresses?

You don’t need to do anything if multiple UTXOs need to be spent. The transaction will have 1 input for every UXTO, and each input will have a unique “ring signature” to obfuscate the real spend.

Coin control may be useful because of how ring signatures work. Every “spy” knows that one of outputs listed in the ring was definitely spent, and transactions with multiple inputs leaks some information about associated outputs that never occurs with 1 input transactions.

When receiving XMR from a KYC platform, should I perform churning (sending the funds to another address or another wallet), or can I spend them directly

There is something called the EAE attack. I’m not going to describe it, as the video probably does a better job. If a Youtube link is unacceptable, I’ll dig further to find a better resource.

Like with the coin control mentioned above, EAE should be eliminated by FCMP++, as the information “leak” from the ring signature is no longer available.

When an XMR wallet software is connected to my own self-hosted Monero node, are transactions broadcast by the wallet software or by the Monero node?

Every new transaction ultimately lands on a node, that broadcasts to the network over tor/i2p OR “clearnet” using Dandelion++. If the operator has configured --tx-proxy for their node, then the “first hop” is only tor and/or i2p, otherwise the first hop corresponds to the Dandelion++ algorithm. The Monero community recently ran a simulation of Dandelion++, proving that the privacy claims of the white paper were seen in practice using real Monero nodes.

When using Whonix + Feather Wallet, do I need to configure Stream Isolation? Which of the following approaches should I use?

You’ll probably want to use stream isolation.

Thank you very much!

Is the first hop when broadcasting a transaction handled by the local monerod node?
If a transaction is broadcast through Tor/I2P, is Dandelion++ not needed? Could analyzing the source node make it possible to link multiple transactions to the same source?

When churning, should there be a random delay between transactions? What would be a reasonable interval?

(Before FCMP++ is introduced) since 1-input transactions can be considered completely safe, does that mean KYC UTXOs can be spent directly in 1-input transactions without any churning?
And for multi-input transactions, would simply sending each received UTXO separately to another address of mine complete all the churning? Because the UTXOs have already been isolated through 1-input transactions, would no further action be needed, just let the wallet automatically select UTXOs for multi-input transactions?

Is the first hop when broadcasting a transaction handled by the local monerod node?

Yes, the first hop is handled by the local node. Or more specifically, the node your wallet is connected to. If using LWS (light-wallets), this refers to the node the LWS server is connected to. Each wallet (or LWS server) is only connected to a single node; there is nothing like Electrum wallet in the Monero ecosystem (at least not yet).

If a transaction is broadcast through Tor/I2P, is Dandelion++ not needed?

When the first hop is over Tor/I2P, the receiving (hidden service) node broadcasts to all its peers after randomized delay (i.e. does not run Dandelion++). There’s an ongoing discussion on whether this receiving node should run Dandelion++, but no conclusive decision has been decided.

Could analyzing the source node make it possible to link multiple transactions to the same source?

Yes, aggressive monitoring of the source (first hop) node could leak that two transactions are related. Specifically ISP spying is the most problematic as Monero has not yet deployed TLS on its (non Tor/I2P) P2P connections. P2P spying - where the spy tries to make lots of connections to determine the source - is mitigated by Tor/I2P and Dandelion++ already.

Using public nodes as tx relay, or enable Tor/I2P connections on your private node.

When churning, should there be a random delay between transactions? What would be a reasonable interval?

Despite what I’ve said, you probably don’t want to churn. If you deem it useful for some reason, there are scripts you can find that do it for you, but I am unable to vouch for any of them. My advice is just read the linked answer (i.e. consider not churning or do it once).

(Before FCMP++ is introduced) since 1-input transactions can be considered completely safe, does that mean KYC UTXOs can be spent directly in 1-input transactions without any churning?

Just use Monero like everyone else (no churning). Pick a wallet and a strategy to prevent stolen XMR, then focus on public vs. private node, then just use XMR when you find an opportunity.

As you’ve noticed, once you’ve decided that churning is necessary, it just adds more complications into how. Since I am unable to provide you with specifics for every possible scenario, your choices are (1) don’t worry about it or (2) chase every rabbit hole in the breaking Monero series, starting with the one I linked. Since this probably came off as aggressive, I’ll just mention that the EAE situation is not dependent on the number of inputs, which you can see in the graphic in the linked video. However, you probably aren’t in an EAE situation (my apologies for mentioning it - you’ll need to understand the attack to determine if this affects you).

The one positive thing about Monero - most of its cheerleaders are honest about where it lacks. You’ll find that the breaking Monero series covers everything advanced users would want to know.

And for multi-input transactions, would simply sending each received UTXO separately to another address of mine complete all the churning? Because the UTXOs have already been isolated through 1-input transactions, would no further action be needed, just let the wallet automatically select UTXOs for multi-input transactions?

Spending multiple UTXOs in 1 transaction links them via inclusion in the ring signature. It doesn’t matter how much churning or addresses you use, they are linked.

When I say linked, I do not mean that some third party can immediately determine which outputs in the ring were spent. I just mean that the tracking statistics change when using multiple-input transactions; a good statistician knows that 1 output was spent in each ring, and knows that those two “real” outputs were from the same source.

This is why the Monero Research Lab has determined that FCMP++ is the best path forward - an input can be any previous output on the chain, so the anonymity set foreach input is the maximum possible.

With a number of questions I had about XMR recently too, I feel there should be a XMR/crypto privacy course for people like us. Kind of joking, but for real, there is a potential for a masterclass on this topic.

The thing with Monero, though, is it’s private by default so you don’t need to learn anything to use it privately.

Mastering Monero is outdated but still great.

To be fair, there seems to be “rough edges” with all privacy products. However, from my experience, you can spend forever studying all the “rough edges” while not actually making progress on privacy. The bulk of people just want/need an improvement to the insane surveillance economy that is the default in so many areas.

Using public nodes as tx relay, or allowing incoming Tor/I2P connections on your private node helps with obfuscating related transactions.

I misspoke earlier, and I think it warrants a re-post.

If you use --tx-proxyto enable outgoing transactions over Tor/I2P, this makes it much hard to identify related transactions. Enabling inbound Tor/I2P connections doesn’t really help the user running the node, however, it helps other people needing privacy.

Thank you for your in-depth explanation.

I’m running monerod and Feather in Whonix. Is the transaction-broadcasting process basically: “Feather → 127.0.0.1:18081 → monerod → monerod waits for a random delay and broadcasts the transaction to everyone” ?
If I want to avoid having my source node analyzed by using “Using public nodes as tx relay”, what’s the correct way to do it? Should I normally use the 127.0.0.1:18081 node and manually switch to a public node whenever I send a transaction?
Or does Tor already provide enough protection that I don’t need to worry about this?


Spending multiple UTXOs in 1 transaction links them via inclusion in the ring signature. It doesn’t matter how much churning or addresses you use, they are linked.

Suppose a KYC exchange gives me 10 KYC UTXOs, and I transfer them separately to another address. I would then have 10 non-KYC UTXOs (stealth addresses). If I later spend those 10 outputs in a single transaction, together with another UTXO A.
Can the KYC exchange detect that this transaction happened?
Can they link UTXO A to the original KYC outputs, and then link UTXO A back to my KYC identity?
Most importantly, is what I’m doing in my example actually unnecessary? I could actually just spend the 10 KYC UTXOs together with UTXO A in one transaction, and my privacy would already be sufficiently protected?

Assuming you are using --tx-proxy on your local node, its feather —ssl—> 127.0.0.1:18081/monerod —tor/i2p—> monerod (waiting for delay) —clearnet p2p—> many monerod.

If I want to avoid having my source node analyzed by using “Using public nodes as tx relay”, what’s the correct way to do it? Should I normally use the 127.0.0.1:18081 node and manually switch to a public node whenever I send a transaction?
Or does Tor already provide enough protection that I don’t need to worry about this?

The best is using --tx-proxy with Tor/I2P on your own local node. Maybe toggle disable_noise if you have bandwidth limits or don’t want slight delays (see --help on --tx-proxy).

Suppose a KYC exchange gives me 10 KYC UTXOs, and I transfer them separately to another address. I would then have 10 non-KYC UTXOs (stealth addresses). If I later spend those 10 outputs in a single transaction, together with another UTXO A.
Can the KYC exchange detect that this transaction happened?

You’ll have to internalize how EAE attack works and determine this yourself. It’s certainly possible.

-> What are the odds that 10.65656 XMR went to 10 outputs, cycled to another set of 10 outputs, and then that same amount minus fees (which are public) ended up at the same location? Blockchain systems will always have amounts in transactions, which help analysis. Encrypting the amounts (like XMR/ZEC) partially helps privacy, but is not a panacea as sender/receiver know the unencrypted amounts of outputs. This is also why XMR is against transparent pools (as in ZEC) - the user is more likely to “foot gun” themselves and devolve into the madness that is BTC privacy.

Most importantly, is what I’m doing in my example actually unnecessary? I could actually just spend the 10 KYC UTXOs together with UTXO A in one transaction, and my privacy would already be sufficiently protected?

You’re likely best not using Monero at all, or just using it without complications. As an example, this 10 separate UXTO thing is likely creating more problems than its solving.

I run into this general problem with privacy too sometimes. I want it to be absolutely perfect, but ultimately this isn’t realistic at the present moment. And most of the time, it just needs to be better than “I’m just handing over a boatload of information to the surveillance capitalism beast”.

Thanks, I only have one question left.
Do I still need to configure --tx-proxy in Whonix?
Or the protection provided by Whonix already offer enough protection, so there’s no need for any additional configuration?

I’m using Whonix, where all apps are forced to connect through Tor, and I haven’t configured --tx-proxy.
So my connection path be: “Feather —ssl—> 127.0.0.1:18081/monerod —Tor—clearnet p2p —> many monerod”?
It seems like there’s no public monerod relay compared to using --tx-proxy?


This is the command I’m currently using to start monerod (using torsocks to apply Whonix Stream Isolation to monerod):
DNS_PUBLIC=tcp TORSOCKS_ALLOW_INBOUND=1 torsocks '$MONERO_DIR/monerod' --data-dir '$DATA_DIR' --prune-blockchain --sync-pruned-blocks --p2p-bind-ip 127.0.0.1 --no-igd --hide-my-port --pad-transactions

If I were to configure --tx-proxy + --proxy, maybe I should change it to:
DNS_PUBLIC=tcp '$MONERO_DIR/monerod' --data-dir '$DATA_DIR' --prune-blockchain --sync-pruned-blocks --p2p-bind-ip 127.0.0.1 --no-igd --hide-my-port --pad-transactions --tx-proxy=tor,socks5://10.152.152.10:9158,16 --proxy=socks5://10.152.152.10:9158

A good help to understand how ring signatures work in monero is to use Monerovis.com blockchain explorer for monero. Click on any transaction, then select any of they decoy inputs which will take you to the transaction where this utxo was originally created. Click this output pubkey to view the decoy map.

This Might not be related to your question Directly , but will help you understand the current structure and tracebillity.

Wow, I didn’t expect to be a Monero book there, I’m glad to see one, I may look at it if the oldness is not a big obstacle.

Speaking of learning Monero, I wouldn’t say there’s nothing to learn. You have to run your own node to be certain about your privacy, there is matter on buying XMR privately, and in fact the whole OP’s post shows you can have a lot of questions. These are things to learn, though sure for some people only a small part of it is necessary.

Do I still need to configure --tx-proxy in Whonix?

Some people still run --tx-proxy in this situation, particularly if they want to leave “noise” enabled. This is where null-zeroes are sent at periodic, slightly randomized intervals. If you’d run monerod with disable_noise, then the benefits are harder to quantify.

Currently the biggest difference is Dandelion++ vs hidden services, with hidden services having received far more scrutiny in concept and code. Presumably this is why people still run --tx-proxy in your situation. Otherwise, I can’t think of any benefits.

So my connection path be: “Feather —ssl—> 127.0.0.1:18081/monerod —Tor—clearnet p2p —> many monerod”?

Not exactly. Your local monerod instance will send using Dandelion++ in this situation, so instead of --> many monerod it becomes --> single monerod --> single monerod --> etc until eventually a “fluff” node is reached, which then switches to many monerod. Dandelion++ is an “overlay network” within the general P2P network.

-> This may change as we are investigating using Dandelion++ even with the hidden service mode. I mentioned this previously.