<p>As an example, let's say that Alice is an attacker trying to learn Bob's wallet using this method. Alice sends 1 satoshi to some address that Bob owns.</p>
<p>At this point in time, Alice does not know anything about Bob's wallet, except that he has 1 sat that she sent him. But the problem is when Bob wants to send Bitcoin.</p>
<p>Now Bob sends some Bitcoin to a merchant, Carol. When he does this, his wallet will look at what UTXOs it can spend, construct a transaction, sign it, and send it. For this example, let's say that his wallet chooses the UTXO for the 1 sat that Alice sent him. Of course he is paying Carol more than 1 sat and he also has to pay transaction fees. So Bob's wallet chooses several other UTXOs to cover the amount being spent and the transaction fee.</p>
<p>When Bob broadcasts his transaction, Alice can see it too. This is where the privacy comes in. Alice can see the 1 sat she sent Bob in this transaction he made. Since that transaction includes other UTXOs from Bob's wallet, Alice learns that Bob had those UTXOs in his wallet. She can now check the addresses for those UTXOs and learn some addresses in Bob's wallet. If Bob was reusing addresses, she can now learn a lower bound to the amount in Bob's wallet.</p>
<p>Furthermore, because she knows those addresses belong to Bob, she can watch for other transactions that spend those address's UTXOs. With those transactions, she can do the same process of examining the inputs and learning additional addresses in Bob's wallet. Because Alice can see many of the transactions Bob makes, she can see who Bob is paying and who is paying Bob.</p>
<p>Bob can mitigate this part by not reusing addresses. If Bob doesn't reuse addresses, then Alice will learn less information because once she learns about some of Bob's addresses in a transaction, Bob will never use those again so there isn't any additional tracing that can be done.</p>
<p>However, there is still the change outputs that Bob's wallet likely made in his transaction. If Alice is able to identify the change outputs in any of Bob's transactions, she will also be able to do the above.</p>
<p>Now this kind of tracking is not unique to the dust spam attack. Anyone can do this kind of tracing with any amount of Bitcoin. It can be done by someone being malicious after having done a normal Bitcoin transaction.</p>
<hr />
<p>The 1 satoshi spam attack becomes more interesting when Alice does it en masse. If Alice sends 1 satoshi to millions of addresses, Alice can learn a lot more.</p>
<p>Suppose Alice looks up every address that has ever been used and sends 1 sat to every single one of them. This will include Bob's addresses. She also sends 1 sat to an address ,<code>Bobs_addr</code>, that she knows belongs to Bob.</p>
<p>Bob has never reused an address. But Alice has now forced him to reuse addresses because she has sent 1 sat to all of his addresses. When Bob makes a transaction, his wallet may be unaware of this attack and may choose to include a couple of Alice's 1 sat UTXOs in a transaction, in addition to the 1 sat at <code>Bobs_addr</code></p>
<p>Now Alice has a transaction that links <code>Bobs_addr</code> with several of Bob's other addresses. Furthermore, because the 1 sat UTXOs belong to addresses that have now been reused, Alice can look up what transactions those addresses were involved in and do the same analysis that I described earlier with the address reuse problem.</p>
<hr />
<p>There are several mitigations to these privacy revealing attacks. These privacy revealing attacks all rely an assumption that all of the inputs in a transaction belong to the same person. This is known as the common input heuristic. To break this assumption, a sender can join up with other people sending money and they all create a transaction together. This is known as a Coinjoin. A Coinjoin transaction has inputs from multiple people, and outputs which go to multiple people. So this breaks the common input heuristic.</p>
<p>Wallets can also be made aware of such dust spam attacks. If the wallet developers know that this is something that occurs, they can program the wallet such that it will never spend reused addresses unless absolutely necessary. If Bob never reused an address and his wallet avoided address reuse, he could prevent Alice from learning anything more about his wallet with her spam attack because his wallet would choose to ignore Alice's 1 sat UTXOs sent to addresses he already used.</p>
<p>In addition to avoiding reuse, if reuse has occurred, the wallet can also choose to spend all UTXOs to the same address at the same time. This prevents being able to link addresses to additional transactions because all of the reuse is spent at the same time.</p>
<p>To prevent Alice from being able to trace Bob's wallet by trying to figure out his change addresses, Bob's wallet can also choose to not make change outputs. His wallet could be using a coin selection algorithm which searches for an input set which exactly matches the amount that Bob is trying to send. Combined with not reusing addresses, avoiding spending reused addresses, and spending reused addresses all at once, this could effectively prevent Alice from learning anything about Bob because the only lead she has into his wallet is where those coins never lead back to Bob.</p>

CC BY-SA 4.0
2021-01-21T19:50:20.973Z
I'm still reading your answer, but I have one major question: how can anyone "send one satoshi to every address" when there is a transaction fee for every transaction? Would not that make this practically impossible for somebody not *insanely* rich? Or even then?
Zathan
CC BY-SA 4.0
2021-01-21T22:05:12.940Z
@Zathan I use that as an example. In practice, attackers will send dust to just several addresses, not all of them. This can also be done in a single transaction with multiple outputs. This greatly reduces the fee required.
Ava Chow
CC BY-SA 4.0
2021-01-21T18:27:50.970Z
2021-01-21T18:27:50.970Z
Ava Chow
<p>If you do payjoin/coinjoin or similar to protect your privacy you try to break the link between your addresses before your transaction and after. This is short term easy but long term not. Lets use a coinjoin mixing transaction as an example.</p>
<ol>
<li>Your addresses before the transaction: 1a, 1b, 1c</li>
<li>You put 1a into a coinjoin transaction and get as output 1d and 1e</li>
<li>Heuristics clusters addresses 1b,1c with other addresses into a wallet A.</li>
<li>Heuristics clusters addresses 1d and 1e with other addresses into a wallet B</li>
<li>If you use tmw, in 2 weeks or in 5 years one address from wallet A as a common input with an address from wallet B then the coinjoin transaction was useless. The tracing goes through the coinjoin. I tested it and even if people mixed several times after each other I was able to link 20% of the output addresses to the inputs using this approach.</li>
</ol>
<p>So if you break the analysis then you need to do it very consistent. You need to make sure the two wallets don't get in touch with each other anymore, even not after years or after 3 times going through a mixer.</p>
<p>The same is valid if you try to break the analysis by exchanging into Monero forth and and back into bitcoin.</p>

CC BY-SA 4.0
2021-01-26T22:11:24.533Z
2021-01-26T22:11:24.533Z
tempo
<ol>
<li><p>I have a wallet.dat in Bitcoin Core. I generate a new receive address. I give it to some random person who knows my identity. They send me 1 satoshi to that address. How exactly can they then &quot;know my Bitcoin balance and exactly who I do business with&quot;?</p>
</li>
<li><p>I have a wallet.dat in Bitcoin Core. Somebody gives me a Bitcoin receive address which I know nothing about. It could be fresh or reused. I send 1 satoshi to that address. How exactly can they then &quot;know my Bitcoin balance and exactly who I do business with&quot;?</p>
</li>
</ol>
<p>In both cases, I'm not interested in what <em>I</em> can do to <em>their</em> privacy, but only what they can do to me.</p>
<p>I just don't get how either of those scenarios would make them know anything about me or learn my Bitcoin balance.</p>
<p>I've tried to ask this question regularly (in numerous variations) for a decade now. Not once have I got a satisfying or conclusive answer.</p>
<p>The reason I again ask is that I just watched a video where, once again, a Bitcoin expert said that this is how it works. Yet it doesn't add up to me, which probably means that I still don't understand Bitcoin.</p>
<p>I would highly appreciate a clear and unambiguous answer! Always in the past, I come away from this kind of discussion with more questions than before...</p>

<privacy>
Can somebody explain this privacy concern with Bitcoin once and for all?
Zathan
# Can somebody explain this privacy concern with Bitcoin once and for all?

(Asked by: username_0 on 2021-01-21)

1. I have a wallet.dat in Bitcoin Core. I generate a new receive address. I give it to some random person who knows my identity. They send me 1 satoshi to that address. How exactly can they then "know my Bitcoin balance and exactly who I do business with"?
2. I have a wallet.dat in Bitcoin Core. Somebody gives me a Bitcoin receive address which I know nothing about. It could be fresh or reused. I send 1 satoshi to that address. How exactly can they then "know my Bitcoin balance and exactly who I do business with"?

In both cases, I'm not interested in what *I* can do to *their* privacy, but only what they can do to me.

I just don't get how either of those scenarios would make them know anything about me or learn my Bitcoin balance.

I've tried to ask this question regularly (in numerous variations) for a decade now. Not once have I got a satisfying or conclusive answer.

The reason I again ask is that I just watched a video where, once again, a Bitcoin expert said that this is how it works. Yet it doesn't add up to me, which probably means that I still don't understand Bitcoin.

I would highly appreciate a clear and unambiguous answer! Always in the past, I come away from this kind of discussion with more questions than before...

**Tags:** privacy


---

## 2 answers

### Answer by username_1 on 2021-01-21. Score: 4

As an example, let's say that Alice is an attacker trying to learn Bob's wallet using this method. Alice sends 1 satoshi to some address that Bob owns.

At this point in time, Alice does not know anything about Bob's wallet, except that he has 1 sat that she sent him. But the problem is when Bob wants to send Bitcoin.

Now Bob sends some Bitcoin to a merchant, Carol. When he does this, his wallet will look at what UTXOs it can spend, construct a transaction, sign it, and send it. For this example, let's say that his wallet chooses the UTXO for the 1 sat that Alice sent him. Of course he is paying Carol more than 1 sat and he also has to pay transaction fees. So Bob's wallet chooses several other UTXOs to cover the amount being spent and the transaction fee.

When Bob broadcasts his transaction, Alice can see it too. This is where the privacy comes in. Alice can see the 1 sat she sent Bob in this transaction he made. Since that transaction includes other UTXOs from Bob's wallet, Alice learns that Bob had those UTXOs in his wallet. She can now check the addresses for those UTXOs and learn some addresses in Bob's wallet. If Bob was reusing addresses, she can now learn a lower bound to the amount in Bob's wallet.

Furthermore, because she knows those addresses belong to Bob, she can watch for other transactions that spend those address's UTXOs. With those transactions, she can do the same process of examining the inputs and learning additional addresses in Bob's wallet. Because Alice can see many of the transactions Bob makes, she can see who Bob is paying and who is paying Bob.

Bob can mitigate this part by not reusing addresses. If Bob doesn't reuse addresses, then Alice will learn less information because once she learns about some of Bob's addresses in a transaction, Bob will never use those again so there isn't any additional tracing that can be done.

However, there is still the change outputs that Bob's wallet likely made in his transaction. If Alice is able to identify the change outputs in any of Bob's transactions, she will also be able to do the above.

Now this kind of tracking is not unique to the dust spam attack. Anyone can do this kind of tracing with any amount of Bitcoin. It can be done by someone being malicious after having done a normal Bitcoin transaction.

---

The 1 satoshi spam attack becomes more interesting when Alice does it en masse. If Alice sends 1 satoshi to millions of addresses, Alice can learn a lot more.

Suppose Alice looks up every address that has ever been used and sends 1 sat to every single one of them. This will include Bob's addresses. She also sends 1 sat to an address ,`Bobs_addr`, that she knows belongs to Bob.

Bob has never reused an address. But Alice has now forced him to reuse addresses because she has sent 1 sat to all of his addresses. When Bob makes a transaction, his wallet may be unaware of this attack and may choose to include a couple of Alice's 1 sat UTXOs in a transaction, in addition to the 1 sat at `Bobs_addr`

Now Alice has a transaction that links `Bobs_addr` with several of Bob's other addresses. Furthermore, because the 1 sat UTXOs belong to addresses that have now been reused, Alice can look up what transactions those addresses were involved in and do the same analysis that I described earlier with the address reuse problem.

---

There are several mitigations to these privacy revealing attacks. These privacy revealing attacks all rely an assumption that all of the inputs in a transaction belong to the same person. This is known as the common input heuristic. To break this assumption, a sender can join up with other people sending money and they all create a transaction together. This is known as a Coinjoin. A Coinjoin transaction has inputs from multiple people, and outputs which go to multiple people. So this breaks the common input heuristic.

Wallets can also be made aware of such dust spam attacks. If the wallet developers know that this is something that occurs, they can program the wallet such that it will never spend reused addresses unless absolutely necessary. If Bob never reused an address and his wallet avoided address reuse, he could prevent Alice from learning anything more about his wallet with her spam attack because his wallet would choose to ignore Alice's 1 sat UTXOs sent to addresses he already used.

In addition to avoiding reuse, if reuse has occurred, the wallet can also choose to spend all UTXOs to the same address at the same time. This prevents being able to link addresses to additional transactions because all of the reuse is spent at the same time.

To prevent Alice from being able to trace Bob's wallet by trying to figure out his change addresses, Bob's wallet can also choose to not make change outputs. His wallet could be using a coin selection algorithm which searches for an input set which exactly matches the amount that Bob is trying to send. Combined with not reusing addresses, avoiding spending reused addresses, and spending reused addresses all at once, this could effectively prevent Alice from learning anything about Bob because the only lead she has into his wallet is where those coins never lead back to Bob.

> **Comments:**
> **username_0**: I'm still reading your answer, but I have one major question: how can anyone "send one satoshi to every address" when there is a transaction fee for every transaction? Would not that make this practically impossible for somebody not *insanely* rich? Or even then?  
> **username_1**: @username_0 I use that as an example. In practice, attackers will send dust to just several addresses, not all of them. This can also be done in a single transaction with multiple outputs. This greatly reduces the fee required.  

---

### Answer by username_2 on 2021-01-26. Score: 0

If you do payjoin/coinjoin or similar to protect your privacy you try to break the link between your addresses before your transaction and after. This is short term easy but long term not. Lets use a coinjoin mixing transaction as an example.

1. Your addresses before the transaction: 1a, 1b, 1c
2. You put 1a into a coinjoin transaction and get as output 1d and 1e
3. Heuristics clusters addresses 1b,1c with other addresses into a wallet A.
4. Heuristics clusters addresses 1d and 1e with other addresses into a wallet B
5. If you use tmw, in 2 weeks or in 5 years one address from wallet A as a common input with an address from wallet B then the coinjoin transaction was useless. The tracing goes through the coinjoin. I tested it and even if people mixed several times after each other I was able to link 20% of the output addresses to the inputs using this approach.

So if you break the analysis then you need to do it very consistent. You need to make sure the two wallets don't get in touch with each other anymore, even not after years or after 3 times going through a mixer.

The same is valid if you try to break the analysis by exchanging into Monero forth and and back into bitcoin.


---

