<p>First, the common lingo for these "cashback transactions" is "change outputs", and "chain analysis" is a thing whole businesses have sprung up around. There are a few indicators that allow making educated guesses on which outputs may be change, e.g. </p>

<ul>
<li>round numbers (e.g. three outputs with round amounts and one not)</li>
<li>wallet fingerprinting (e.g. all inputs are multisig, only one output is multisig)</li>
<li>address reuse (some wallets send change back to an address previously used by the wallet)</li>
<li>unnecessary input heuristic</li>
<li>probabilistic graph search</li>
<li>…</li>
</ul>

<p>The Bitcoin wiki has a whole section in its article on privacy describing approaches for <a href="https://en.bitcoin.it/wiki/Privacy#Change_address_detection" rel="nofollow noreferrer">change address detection</a>.</p>

CC BY-SA 4.0
2020-06-15T18:09:44.170Z
thank you for the quick answer and the info. So it seems we can only infer with uncertainty from the "properties" of the transaction which ones are the change outputs, given we look only at the transaction itself. Thank you for this. Best, Jen
user101893
CC BY-SA 4.0
2020-06-15T18:14:08.400Z
Yeah, that's right. I see that you're a new user, welcome to the site! I've converted your answer to a comment since you appeared to be replying to my answer rather than actually answering the question. Things work a little different from a forum here, may I invite you to take a glance at our site's [tour]?
Murch
CC BY-SA 4.0
2020-06-15T18:00:27.837Z
2020-06-15T18:11:44.247Z
2020-06-15T18:11:44.247Z
Murch
<p>let me quickly elaborate the question. The structure of a BTC transaction script looks somewhat like the following example</p>

<p>"01000000018190374a5a1feb54fab4417fac1a3d9185de06fd8dcac34822c7cd00083638b1000000006a4730440220237ef9d9a3908f163ee37cc65de642ba1d45e399cde840285cd1658292ee71f902201a2fa3959cf19e64308d64a052526b755e22f2efb941675bc35684de1d90e7dd012103c13dca192f1ba64265d8efca97d43b822ff24db357c13b0e6e0395cf91e9efaeffffffff0248ac0b00000000001976a9140964c6feb963ade6836e722670abbc0147ca5cec88ac08100b00000000001976a914977ae6e32349b99b72196cb62b5ef37329ed81b488ac00000000"</p>

<p>... where the part </p>

<p>"48ac0b00000000001976a9140964c6feb963ade6836e722670abbc0147ca5cec88ac08100b00000000001976a914977ae6e32349b99b72196cb62b5ef37329ed81b488ac"</p>

<p>... specifies the two output addresses that the money from the UTXO(s) is split and sent to. 
Often, as the sum of one or several UTXO's does not perfectly equal the amount that the sender wants to transfer, as last (?) output address he references his own address, in order to receive back his remaining cash. </p>

<p>My question is, is it somehow ONLY from the transaction script structure as above determinable which of the referenced output addresses correspond to the(se) "cashback address(es)"? </p>

<p>I have a few thoughts on this myself: </p>

<p>Of course, the sender might have several addresses / accounts, anyways, then, we have no chance at figuring out whether he is sending money back to himself or not. </p>

<p>Furthermore, I suspect the answer to my question is no, as otherwise, it could be possible to identify one input address of the regarded transaction as the output address that corresponds to the cashback part. This, I guess is exactly intended not to happen, as we want to keep the anonymity of the sender. </p>

<p>Lastly, I am aware that it is possible to identify cashback transactions when you look at the entire history of the blockchain and keep track of which address "holds" what amount of BTC / UTXO's right now. However, in order to do so, you would need to store all the addresses named in previous transactions throughout time, which is quite computationally costly, as you proceed through time in the blockchain. 
Thus, I am asking for a way to quickly identify such cashback transactions. (We can for instance always easily identify the coinbase transaction in a block from the structure of the code.) </p>

<p>That's about it. I am looking forward to your comments, hopefully someone can shed light on this :)
Thanks!</p>

<p>Best, 
Jen</p>

<transactions><blockchain><script><utxo><change>
Can we determine which one of the referenced outputs corresponds to a cashback transaction in BTC transaction scripts?
user101893
# Can we determine which one of the referenced outputs corresponds to a cashback transaction in BTC transaction scripts?

(Asked by: username_0 on 2020-06-15)

let me quickly elaborate the question. The structure of a BTC transaction script looks somewhat like the following example

"01000000018190374a5a1feb54fab4417fac1a3d9185de06fd8dcac34822c7cd00083638b1000000006a4730440220237ef9d9a3908f163ee37cc65de642ba1d45e399cde840285cd1658292ee71f902201a2fa3959cf19e64308d64a052526b755e22f2efb941675bc35684de1d90e7dd012103c13dca192f1ba64265d8efca97d43b822ff24db357c13b0e6e0395cf91e9efaeffffffff0248ac0b00000000001976a9140964c6feb963ade6836e722670abbc0147ca5cec88ac08100b00000000001976a914977ae6e32349b99b72196cb62b5ef37329ed81b488ac00000000"

... where the part

"48ac0b00000000001976a9140964c6feb963ade6836e722670abbc0147ca5cec88ac08100b00000000001976a914977ae6e32349b99b72196cb62b5ef37329ed81b488ac"

... specifies the two output addresses that the money from the UTXO(s) is split and sent to.
Often, as the sum of one or several UTXO's does not perfectly equal the amount that the sender wants to transfer, as last (?) output address he references his own address, in order to receive back his remaining cash.

My question is, is it somehow ONLY from the transaction script structure as above determinable which of the referenced output addresses correspond to the(se) "cashback address(es)"?

I have a few thoughts on this myself:

Of course, the sender might have several addresses / accounts, anyways, then, we have no chance at figuring out whether he is sending money back to himself or not.

Furthermore, I suspect the answer to my question is no, as otherwise, it could be possible to identify one input address of the regarded transaction as the output address that corresponds to the cashback part. This, I guess is exactly intended not to happen, as we want to keep the anonymity of the sender.

Lastly, I am aware that it is possible to identify cashback transactions when you look at the entire history of the blockchain and keep track of which address "holds" what amount of BTC / UTXO's right now. However, in order to do so, you would need to store all the addresses named in previous transactions throughout time, which is quite computationally costly, as you proceed through time in the blockchain.
Thus, I am asking for a way to quickly identify such cashback transactions. (We can for instance always easily identify the coinbase transaction in a block from the structure of the code.)

That's about it. I am looking forward to your comments, hopefully someone can shed light on this :)
Thanks!

Best,
Jen

**Tags:** transactions, blockchain, script, utxo, change


---

## 1 answers

### Answer by username_1 on 2020-06-15. Score: 1

First, the common lingo for these "cashback transactions" is "change outputs", and "chain analysis" is a thing whole businesses have sprung up around. There are a few indicators that allow making educated guesses on which outputs may be change, e.g.

* round numbers (e.g. three outputs with round amounts and one not)
* wallet fingerprinting (e.g. all inputs are multisig, only one output is multisig)
* address reuse (some wallets send change back to an address previously used by the wallet)
* unnecessary input heuristic
* probabilistic graph search
* …

The Bitcoin wiki has a whole section in its article on privacy describing approaches for [change address detection](https://en.bitcoin.it/wiki/Privacy#Change_address_detection).

> **Comments:**
> **username_0**: thank you for the quick answer and the info. So it seems we can only infer with uncertainty from the "properties" of the transaction which ones are the change outputs, given we look only at the transaction itself. Thank you for this. Best, Jen  
> **username_1**: Yeah, that's right. I see that you're a new user, welcome to the site! I've converted your answer to a comment since you appeared to be replying to my answer rather than actually answering the question. Things work a little different from a forum here, may I invite you to take a glance at our site's [tour]?  

---

