So, in the first post it says that you can get better anonymity when you cascade your outputs.
If i have 5 BTC and find e.g. 3 People who also want to anonymize 5 BTC i can make a CoinJoin transcation tx_1 with them. The first (minor) problem is, that we have to pay transaction fees. So every praticipant have inputs with at least 5.1 BTC (0.1 BTC for fees). If we have that, we can make the transaction tx_1 where the outputs have a value of 5 BTC.
The problem that i see is, that if i want to cascade, say 3 times, i have to pay transaction fees every time.
I see two ways one could do that.
1. The transaction fees for the second transaction, which uses the output from transaction tx_1 is paid only from that output/input. So i have to find participants who want to make a CoinJoin Transaction with an Output of 4.9 BTC (5BTC - 0.1 Fee) which could be hard, or i find participants who want to make a transaction with less than 4.9 BTC. If i allow participants with lower values the rest is send to an change address of mine. But in this case i can't , in the beginning, know how much Bitcoins i have left in the output after say three cascades.
So if i want a cascade of three and at the end i want to have 5 anonymous BTCs the first Input must be 5.3 BTC -> output ist 5.2. The second Input is 5.2 BTC -> output 5.1 BTC. The third Input is 5.1 BTC -> 5.0 output.
I think it could be hard to find participants with exactly the amount of Inputs that i need. Furthermore i have to know in advance how long my cascade has to be and how much bitcoins i want in the end.
2. The transaction fees is paid by another Input.
So Alice makes transaction tx_1 with an Input of 5.1 BTC -> output is 5.0 BTC.
The second transaction tx_2 consists of the Input with 5.0 BTC from the last transaction, and a new Input with 0.1 BTC for my fees.
Assume an attacker who can match all Bitcoin addresses to the person behind these addresses excluding the output addresses used for outputs in CoinJoin transactions.
If Alice uses an address for the transaction fees input , which the attacker can match to Alice, the attacker knows which output of tx_1 belongs to Alice.
Why?
The attacker knows who participates in tx_1 because he knows the persons behind the inputs. The only thing he doesn't knows is, which ouput belongs to which participan. But if one output is used in a second transaction in which Alice pays the fees for, and no other input in that transaction could come from Alice, the only plausible way is, that Alice is the owner of the ouput from tx_1 which is used in tx_2. In that case the anonymity of the CoinJoin Transaction tx_1 is broken.
This even works if the fee Input comes from another CoinJoin transaction. You just have to look at the inputs of the CoinJoin transaction uses for the fee input, if one input matches an address of Alice you can be pretty sure, that the output from tx_1 also belongs to Alice.
So my question is, am i missing something, or is this really a problem when using cascades in CoinJoin. Cause i see no other option than the first case, if you want to use cascades and don't want the anonymity broken by the fees.
I hope you can unterstand what i mean.
Greetings
Duky
I think I have a rough understanding of what you're pondering. I believe that OP has dropped transaction fees from the introduction for simplicity and from the tone it should be clear that he's primarily interested in a little extra privacy as opposed to hardened secrecy.
If we assume the hostile environment of your scenario 2 and desire regular, thorough mixing then I would first think about dropping the "all inputs/outputs should be of the same size" assumption. Of course, we'd have to take care here not to allow varying input/output sizes to reveal too much information. If we want regular mixing we really also ought to tackle the issue of combining outputs (always a pain). Here's a first thought:
Inputs | (5) | Outputs | (110) | |
Party_A: | 1.5671 BTC | 1 x | 1 BTC | |
0.3894 BTC | 29 x | 0.1 BTC | ||
0.0015 BTC | 25 x | 0.01 BTC | ||
Party_B: | 1.5000 BTC | 33 x | 0.001 BTC | |
Party_C: | 0.7082 BTC | 22 x | 0.0001 BTC | |
0.0203 BTC |
I'm afraid I lack the time to explain everything I'm thinking here but I hope this example transaction gives you an idea or two. I'll happily try to tackle a follow-up question if you have one.