Yes, but as far as I can see the coinjoin is still a separate transaction with separate fees.
Joe Blow buys a sandwich. Why would joe blow, or the sandwich shop, then also pay to do coinjoin transactions?
Topic: CoinJoin: Bitcoin privacy for the real world - page 25. (Read 294649 times)
I appreciate the thought here with coinjoin, but the fact remains that people need to actually use it, and then people need to actually pay (transaction fees) for it.
CoinJoin transactions are slightly smaller than non-CoinJoin because all parties can share the same transaction header, and thus are actually cheaper than the alternative.
I appreciate the thought here with coinjoin, but the fact remains that people need to actually use it, and then people need to actually pay (transaction fees) for it.
Honestly, I don't think they will. If the manager of a sandwich shop spends 1/10 of 1% of his receipts on coinjoin transactions, he's going to get fired. If you ask naive user Joe whether he's willing to spend an extra fifty cents for some abstract thing like privacy on a legitimate $500 transaction, he's going to say no because he doesn't care enough in the immediate case.
If you want privacy, then you need to fix the protocol so that *EVERY* transaction is a mix, and people *DON'T* have to pay extra for mixing.
My thought on this is that the clients need to prefer producing outputs in "standard" coin sizes (to separate output addresses) such as [1 | 2.5 | 5] * 10^N - for ALL outputs including change - and that whenever possible *both* sides of a transaction need to be providing inputs that add up to at least twice the amount of money that's actually required to change hands.
'Coz honestly, it doesn't matter how good your coinjoin design is if people still have to pay tx fees to use it, because they won't.
Honestly, I don't think they will. If the manager of a sandwich shop spends 1/10 of 1% of his receipts on coinjoin transactions, he's going to get fired. If you ask naive user Joe whether he's willing to spend an extra fifty cents for some abstract thing like privacy on a legitimate $500 transaction, he's going to say no because he doesn't care enough in the immediate case.
If you want privacy, then you need to fix the protocol so that *EVERY* transaction is a mix, and people *DON'T* have to pay extra for mixing.
My thought on this is that the clients need to prefer producing outputs in "standard" coin sizes (to separate output addresses) such as [1 | 2.5 | 5] * 10^N - for ALL outputs including change - and that whenever possible *both* sides of a transaction need to be providing inputs that add up to at least twice the amount of money that's actually required to change hands.
'Coz honestly, it doesn't matter how good your coinjoin design is if people still have to pay tx fees to use it, because they won't.
Furthermore, remember that in CoinJoin all outputs have the same size. So in this case one output is 1.5 BTC to 1Friend, so the other two outputs (going to new addresses of Person A himself) each have 1.5 BTC too. So the sum of all inputs must be at least 4.5 BTC. So Person A must have at lest 4.5 BTC in his wallet although he just wants to transfer 1.5 BTC to 1Friend.
Good point. However outputs don't have to be the same value but could be among a set of values. And with the advent of HD wallets, I could ask my friend for an extended pubkey so I could generate as many addresses of them as I wanted, and I would set up the outputs of the CJ accordingly. For example if the outputs must be powers of two between 2^16 and 2^32 satoshis, I could roughly fit 1.5 BTC into that. (2^27 + 2^23 + 2^22 + 2^21 + 2^20) / 1e8 = 1.49946368.
Michael, your examples indicate bad coin control and insufficient anonymity sets, not in inherent unknown weakness in CoinJoin.
For disadvantage (2):
Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
gmaxwell's "CoinSwap" introduces a framework that enables "secure" mixing in the sense that the mixer can't run with your coins. I believe CoinSwap is better for dedicated mixing than splitting funds into smaller quantities because it does not just spread the risk, it brings it down to just about zero. Additionally, the Tx fees are lower.Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
[...]
I am wondering whether it is possible to combine the CoinSwap and CoinJoin concepts. Idea (Ex. N=3 again):
Traditional CoinJoin:
ConJoin Transaction: inputs = (1Ain, 1Bin, 1Cin), outputs = (1Aout, 1Bout, 1Cout).
New "CoinJoinSwap":
ConJoin Transaction 1: inputs = (1Ain, 1Bin, 1Cin), outputs = (1Xout, 1Yout, 1Zout).
ConJoin Transaction 2: inputs = (1Xin, 1Yin, 1Zin), outputs = (1Aout, 1Bout, 1Cout).
So here 6 participants are involved, namely Persons A, B, C, X, Y, Z.
Contrary to normal CoinJoin, taint is really removed instead of just "hidden".
A CoinSwap-like protocol would have to be defined to make sure that no funds can be embezzled (via hash-locked techniques?), and that no connections between the two CJ transactions can be made from the outside observer. And hopefully, it can be done in a way that there's not a "single-point-of privacy-leak" like in CoinSwap where "Carol can tell about Alice".
I am stopping here, because I did not understand CoinSwap to the last detail yet, but I have the feeling that such combined mechanism could be possible and trying to inspire...
For disadvantage (2):
Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
gmaxwell's "CoinSwap" introduces a framework that enables "secure" mixing in the sense that the mixer can't run with your coins. I believe CoinSwap is better for dedicated mixing than splitting funds into smaller quantities because it does not just spread the risk, it brings it down to just about zero. Additionally, the Tx fees are lower.Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
2nd topic:
Idea how to minimize the likelihood of a CoinJoin sybil attack (i.e. that the N-1 co-participants of my CoinJoin transaction are "3-letter-hostile-organization spies"):
Idea how to minimize the likelihood of a CoinJoin sybil attack (i.e. that the N-1 co-participants of my CoinJoin transaction are "3-letter-hostile-organization spies"):
- I initiate TWO CoinJoin transactions instead of just one, of equal output size, and at about the same time, but I inject them at different points of the network if possible (so that an observer does not know they both origin from me).
- When all co-participants have completed their inputs to reach the number N (here I assume N=10 or so at least), I check if BOTH of my inputs show up amongst these N.
- If yes, I can fairly assume that the CoinJoin server did not get flooded with 3-letter-hostile spying-transactions and also the other N-2 inputs are probably legit, and I will sign my two transactions.
- If no, I must assume that the other N-1 transactions are hostile and my second input has been "squeezed-out" and pushed to the next CoinJoin transactions, and I better refrain from signing and try again later. Or I sign anyway (because my non-signing might get interpreted as a DOS attack) but then initiate another CoinJoin transaction were hopefully both of my inputs will show up then...
This is an interesting way to do so. However, it is vulnerable to having a mixing service that is not used very much, in which case only you and 3-letter organizations are trying to mix at any given time. In this case, you will probably have both your inputs included but are still being tracked. Of course, it would mean quite an expenditure for that organization, especially since they are only keeping track of you. In any case, I see CoinJoin as a casual solution that works to give low anonymity to the Bitcoin network as a whole rather than high anonymity to a limited group of people.
I also acknowledge that the sole existence and integration of CoinJoin in the client SW and its widespread use is reason enough to render an approach of introducing red/blacklistings increasingly useless, and this alone may fully justify CoinJoin. And I think this is the main intention of the OP et al.
But what if the user needs to spend a LARGE amount of BTCs from his wallet? Then it cannot be avoided and the coins get "re-tainted". Of course the user (or wallet client) could initiate two separate transactions (within a short time) to the same output address "1Friend", but this hardly makes any difference (except that an observer could not prove 100% that 1A1out and 1A2out have the same owner, it would only be obvious at 99.99...% certainty.
User could always use CoinJoin again to pay 1Friend, so the inputs to the joint transaction would be 1A1out, 1A2out and some others. No one would know that 1A1out and 1A2out belong to the same person.
A blockchain observer may still wonder why 1A1out and 1A2out are inputs to the same (CoinJoin-like) transaction. I assume that blockchain analysis uses some sort of scoring or probability method, and the hypothesis that 1A1out and 1A2out belong to the same owner will still get a very high score here.
Furthermore, remember that in CoinJoin all outputs have the same size. So in this case one output is 1.5 BTC to 1Friend, so the other two outputs (going to new addresses of Person A himself) each have 1.5 BTC too. So the sum of all inputs must be at least 4.5 BTC. So Person A must have at lest 4.5 BTC in his wallet although he just wants to transfer 1.5 BTC to 1Friend.
So additional constraints are introduced.
Moreover, from this we see that even addresses of Person A's wallet that were formerly independent are now "entangled" in some way. So we could even consider that the taint spreads over yet unassociated addresses, and privacy things get even worse, not better, by this suggestion.
One would have to analyze this much deeper to tell if taint really gets improved here, by taking into account the methods that are used for blockchain analysis techniques... it is certainly not a trivial subject. Approaching it with simple human intuition may lead to fallacies.
For disadvantage (2):
Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
gmaxwell's "CoinSwap" introduces a framework that enables "secure" mixing in the sense that the mixer can't run with your coins. I believe CoinSwap is better for dedicated mixing than splitting funds into smaller quantities because it does not just spread the risk, it brings it down to just about zero. Additionally, the Tx fees are lower.Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
2nd topic:
Idea how to minimize the likelihood of a CoinJoin sybil attack (i.e. that the N-1 co-participants of my CoinJoin transaction are "3-letter-hostile-organization spies"):
Idea how to minimize the likelihood of a CoinJoin sybil attack (i.e. that the N-1 co-participants of my CoinJoin transaction are "3-letter-hostile-organization spies"):
- I initiate TWO CoinJoin transactions instead of just one, of equal output size, and at about the same time, but I inject them at different points of the network if possible (so that an observer does not know they both origin from me).
- When all co-participants have completed their inputs to reach the number N (here I assume N=10 or so at least), I check if BOTH of my inputs show up amongst these N.
- If yes, I can fairly assume that the CoinJoin server did not get flooded with 3-letter-hostile spying-transactions and also the other N-2 inputs are probably legit, and I will sign my two transactions.
- If no, I must assume that the other N-1 transactions are hostile and my second input has been "squeezed-out" and pushed to the next CoinJoin transactions, and I better refrain from signing and try again later. Or I sign anyway (because my non-signing might get interpreted as a DOS attack) but then initiate another CoinJoin transaction were hopefully both of my inputs will show up then...
This is an interesting way to do so. However, it is vulnerable to having a mixing service that is not used very much, in which case only you and 3-letter organizations are trying to mix at any given time. In this case, you will probably have both your inputs included but are still being tracked. Of course, it would mean quite an expenditure for that organization, especially since they are only keeping track of you. In any case, I see CoinJoin as a casual solution that works to give low anonymity to the Bitcoin network as a whole rather than high anonymity to a limited group of people.
But what if the user needs to spend a LARGE amount of BTCs from his wallet? Then it cannot be avoided and the coins get "re-tainted". Of course the user (or wallet client) could initiate two separate transactions (within a short time) to the same output address "1Friend", but this hardly makes any difference (except that an observer could not prove 100% that 1A1out and 1A2out have the same owner, it would only be obvious at 99.99...% certainty.
User could always use CoinJoin again to pay 1Friend, so the inputs to the joint transaction would be 1A1out, 1A2out and some others. No one would know that 1A1out and 1A2out belong to the same person.
...
Input = 1A1out and 1A2out (=1+1 =2 BTC).
...
Input = 1A1out and 1A2out (=1+1 =2 BTC).
...
If the CoinJoin functionality gets implemented within the wallet, shouldn't the the wallet prohibit using 1A1out and 1A2out in the same transaction?
But what if the user needs to spend a LARGE amount of BTCs from his wallet? Then it cannot be avoided and the coins get "re-tainted". Of course the user (or wallet client) could initiate two separate transactions (within a short time) to the same output address "1Friend", but this hardly makes any difference (except that an observer could not prove 100% that 1A1out and 1A2out have the same owner, it would only be obvious at 99.99...% certainty.
...
Input = 1A1out and 1A2out (=1+1 =2 BTC).
...
Input = 1A1out and 1A2out (=1+1 =2 BTC).
...
If the CoinJoin functionality gets implemented within the wallet, shouldn't the the wallet prohibit using 1A1out and 1A2out in the same transaction?
Good to know about the CoinJoin initiative. After reading the thread, I understand the view that it will have more value the more common it becomes in normal use.
I'd just like to clarify what CoinJoin is NOT able to do, to avoid seemingly frequent misunderstandings (and where it is different from traditional mixing services) - and I have a proposal further below.
All CoinJoin transactions considered in my example are "N=3", and I assume that all transactions are of 1 BTC, there is no change involved (unless stated otherwise) and Tx fees are neglected for the sake of simplicity/clarity:
Person A sends 1BTC from Address 1A1in and uses 1A1out as output (change of 1 BTC goes to 1A2in).
Person B sends 1BTC from Address 1B1in and uses 1B1out as output (no change).
Person C sends 1BTC from Address 1C1in and uses 1C1out as output (no change).
At this point, outside taint analysis cannot tell who is the owner of 1A1out/1B1out/1C1out, even if the owners of 1A1in/1B1in/1C1in were perfectly known. So the taint seems to be removed. But in fact the taint is only "hidden" and may re-appear, as we'll see further below!
Now Person A has another coin that he wants to clean, so he engages in another CoinJoin transaction with N=3:
Person A sends 1BTC from Address 1A2in and uses 1A2out as output (no change).
Person X sends 1BTC from Address 1X2in and uses 1X2out as output (no change).
Person Y sends 1BTC from Address 1Y2in and uses 1Y2out as output (no change).
At this point, Person A has 2 BTC in his wallet, namely 1 BTC in 1A1out and 1A2out respectively. No outside observer can know that these are his addresses, even if it was publicly known that 1A1in belongs to him. So it seems that Person A has "cleaned" these 2 BTC.
But now Person A makes a fatal mistake, because he doesn't know how CoinJoin works internally and succumbs to the fallacy that his addresses 1A1out and 1A2out are "perfectly cleaned" (as if he had used a traditional mixing service or an online-wallet-"back-and-forth"-transfer or alike):
He sends over, say 1.5 BTC, to his Friend "F", so the transaction is his:
Input = 1A1out and 1A2out (=1+1 =2 BTC).
Output = 1Friend (1.5 BTC) and 1Achange (0.5 BTC to his own new change address).
Now, for an outside observer of the blockchain it is utmost easy (even manually w/o automated scripts) to re-associate addresses 1A1out and 1A2out with 1A1in and hence with person A. This would not have happened if Person A had done proper (manual) "CoinControl", or if he had mixed his coins with a (trustable!) traditional mixer.
Even worse: If Person B makes the same mistake as Person A, then also the address 1C1out of Person C is 100% tainted again, even if she (Person C) did not make any mistake herself!
This is an argument for choosing greater N (or for cascading MANY CoinJoin transactions of N=2), to reduce the probability of getting re-tainted due to mistakes made by the other CoinJoin participants.
So generally, users of CoinJoin must know that any taint that was (temporarily) removed thanks to CoinJoin gets re-established if the user uses different CoinJoin outputs as common inputs for a future transaction. This taint easily re-appears in the same way even if the user performed a cascade of CoinJoin transactions. So careful manual coin-control is indispensable, and maybe clients will implement algos to support the user in his/her coin-control to try avoid re-establishment of taint that was formerly removed by CoinJoin type of techniques, and warn the user when necessary.
So I would use a different terminology: Instead of saying that CoinJoin (and alike) "remove" the taint, I'd rather say it "hides" the taint, or to keep the picture of "colored" coins:
CoinJoin and alike techniques do not remove a [red/black/violet/blue] taint, but they paint white color over this taint. If the user itself practices bad coin control afterwards (or if the other co-participants of the CoinJoin transaction do so), the white paint covering the taint gets peeled-off and the taint re-appears.
This is a fundamental restriction that all blockchain-based-multi-signature taint removal techniques (bitprivacy, CoinJoin, ZeroCoin) have in common as I understand. So the uninformed user may get a false sense of safety for his/her privacy when using these techniques. The only possibility for complete taint removal (instead of just over-painting the taint) is an "off-blockchain mixer", which of course has other disadvantages:
(1) need to trust that the operator does not make records which it hands over to some "3-or-more-Letters-Org"
(2) need to trust the operator that he does not simply keep my coins.
The first disadvantage (1) can be alleviated by looking where the mixer service is located. If there are some mixers in "free" countries, or in some countries that do not co-operate with each other well (e.g. Country X + Y), I should be quite safe w.r.t. risk (1) if I simply concatenate a mixing in country X followed by a mixing in country Y.
For disadvantage (2):
Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
Of course it would be nice if mixing APIs could be standardized and built into the BTC clients, such that a background job can be scheduled from the client, i.e. user selects addresses and amount for taint removal, plus the mixing increments, and the mixing server should be able to communicate his fee policy and the one-time address per mixing job via the API, while the client communicates mixing jobs (amount, source address, pay-back address(es)) to the mixer etc. The client preferably also is configurable w.r.t. time increments (do not send (n+1)th mixing job over immediately after nth mixing job is done, but wait n seconds, where n is configurable by the user and follows e.g. a random poisson distribution to make timestamp-based blockchain analysis more difficult. The mixing BTC amounts accepted by the mixer per job should not be arbitrary, but a fixed set (e.g. only allow 1*10^n and 3*10^n BTC per job, where n can be [...]), to make blockchain analysis based on tracking equal transfer sizes more difficult. The mixer may also send the return to multiple addresses (as specified by the user client via the API) in multiple transactions, to make tracking more difficult. Another idea is to include a "provably fair gambling element" in the payback strategy of the mixer (whose statistical sigma could be agreed upon with the client via the API), to further randomize the payout and make tracking more difficult (e.g. payback = 100% +/-n% -he% - Tx fee, while "n" is Gaussian distributed with STD=sigma as chosen by the client and sigma<=sigma_max as defined by the mixer, and he(%) is the "house edge" of the mixer's payback randomization service)! Whether the "house edge" of this gambling element is 0% or actually more (i.e. mixer takes extra fee for this randomization/obfuscation element) is up to the mixer policy. The "provably fair" verification of the "gambling randomization" would also have to be part of the API, so that the client can verify that this randomization is really fair. The payout times of the mixer should have a variable delay relative to the incoming payments, to make tracking even more difficult. Etc.)
While writing this, I think it would be good to define a BIP for a mixer-client API that supports all these features *. Does anyone know if this has happened already?
After a while, I assume that an infrastructure of mixers will evolve, similarly to the infrastructure of mining pools that we know today. They can differentiate from each other w.r.t. server location/jurisdiction, fee structure, blockchain trackability defense mechanisms (see examples above), etc.
* If you guys think this makes sense, I may start to work on the definition of such a BIP. Sorry this is OT for CoinJoin (albeit related), but the ideas developed while writing this. Further discussions on this in a separate thread I guess(?), if considered useful.
-------------------------------------------------------------------
2nd topic:
Idea how to minimize the likelihood of a CoinJoin sybil attack (i.e. that the N-1 co-participants of my CoinJoin transaction are "3-letter-hostile-organization spies"):
I'd just like to clarify what CoinJoin is NOT able to do, to avoid seemingly frequent misunderstandings (and where it is different from traditional mixing services) - and I have a proposal further below.
All CoinJoin transactions considered in my example are "N=3", and I assume that all transactions are of 1 BTC, there is no change involved (unless stated otherwise) and Tx fees are neglected for the sake of simplicity/clarity:
Person A sends 1BTC from Address 1A1in and uses 1A1out as output (change of 1 BTC goes to 1A2in).
Person B sends 1BTC from Address 1B1in and uses 1B1out as output (no change).
Person C sends 1BTC from Address 1C1in and uses 1C1out as output (no change).
At this point, outside taint analysis cannot tell who is the owner of 1A1out/1B1out/1C1out, even if the owners of 1A1in/1B1in/1C1in were perfectly known. So the taint seems to be removed. But in fact the taint is only "hidden" and may re-appear, as we'll see further below!
Now Person A has another coin that he wants to clean, so he engages in another CoinJoin transaction with N=3:
Person A sends 1BTC from Address 1A2in and uses 1A2out as output (no change).
Person X sends 1BTC from Address 1X2in and uses 1X2out as output (no change).
Person Y sends 1BTC from Address 1Y2in and uses 1Y2out as output (no change).
At this point, Person A has 2 BTC in his wallet, namely 1 BTC in 1A1out and 1A2out respectively. No outside observer can know that these are his addresses, even if it was publicly known that 1A1in belongs to him. So it seems that Person A has "cleaned" these 2 BTC.
But now Person A makes a fatal mistake, because he doesn't know how CoinJoin works internally and succumbs to the fallacy that his addresses 1A1out and 1A2out are "perfectly cleaned" (as if he had used a traditional mixing service or an online-wallet-"back-and-forth"-transfer or alike):
He sends over, say 1.5 BTC, to his Friend "F", so the transaction is his:
Input = 1A1out and 1A2out (=1+1 =2 BTC).
Output = 1Friend (1.5 BTC) and 1Achange (0.5 BTC to his own new change address).
Now, for an outside observer of the blockchain it is utmost easy (even manually w/o automated scripts) to re-associate addresses 1A1out and 1A2out with 1A1in and hence with person A. This would not have happened if Person A had done proper (manual) "CoinControl", or if he had mixed his coins with a (trustable!) traditional mixer.
Even worse: If Person B makes the same mistake as Person A, then also the address 1C1out of Person C is 100% tainted again, even if she (Person C) did not make any mistake herself!
This is an argument for choosing greater N (or for cascading MANY CoinJoin transactions of N=2), to reduce the probability of getting re-tainted due to mistakes made by the other CoinJoin participants.
So generally, users of CoinJoin must know that any taint that was (temporarily) removed thanks to CoinJoin gets re-established if the user uses different CoinJoin outputs as common inputs for a future transaction. This taint easily re-appears in the same way even if the user performed a cascade of CoinJoin transactions. So careful manual coin-control is indispensable, and maybe clients will implement algos to support the user in his/her coin-control to try avoid re-establishment of taint that was formerly removed by CoinJoin type of techniques, and warn the user when necessary.
So I would use a different terminology: Instead of saying that CoinJoin (and alike) "remove" the taint, I'd rather say it "hides" the taint, or to keep the picture of "colored" coins:
CoinJoin and alike techniques do not remove a [red/black/violet/blue] taint, but they paint white color over this taint. If the user itself practices bad coin control afterwards (or if the other co-participants of the CoinJoin transaction do so), the white paint covering the taint gets peeled-off and the taint re-appears.
This is a fundamental restriction that all blockchain-based-multi-signature taint removal techniques (bitprivacy, CoinJoin, ZeroCoin) have in common as I understand. So the uninformed user may get a false sense of safety for his/her privacy when using these techniques. The only possibility for complete taint removal (instead of just over-painting the taint) is an "off-blockchain mixer", which of course has other disadvantages:
(1) need to trust that the operator does not make records which it hands over to some "3-or-more-Letters-Org"
(2) need to trust the operator that he does not simply keep my coins.
The first disadvantage (1) can be alleviated by looking where the mixer service is located. If there are some mixers in "free" countries, or in some countries that do not co-operate with each other well (e.g. Country X + Y), I should be quite safe w.r.t. risk (1) if I simply concatenate a mixing in country X followed by a mixing in country Y.
For disadvantage (2):
Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
Of course it would be nice if mixing APIs could be standardized and built into the BTC clients, such that a background job can be scheduled from the client, i.e. user selects addresses and amount for taint removal, plus the mixing increments, and the mixing server should be able to communicate his fee policy and the one-time address per mixing job via the API, while the client communicates mixing jobs (amount, source address, pay-back address(es)) to the mixer etc. The client preferably also is configurable w.r.t. time increments (do not send (n+1)th mixing job over immediately after nth mixing job is done, but wait n seconds, where n is configurable by the user and follows e.g. a random poisson distribution to make timestamp-based blockchain analysis more difficult. The mixing BTC amounts accepted by the mixer per job should not be arbitrary, but a fixed set (e.g. only allow 1*10^n and 3*10^n BTC per job, where n can be [...]), to make blockchain analysis based on tracking equal transfer sizes more difficult. The mixer may also send the return to multiple addresses (as specified by the user client via the API) in multiple transactions, to make tracking more difficult. Another idea is to include a "provably fair gambling element" in the payback strategy of the mixer (whose statistical sigma could be agreed upon with the client via the API), to further randomize the payout and make tracking more difficult (e.g. payback = 100% +/-n% -he% - Tx fee, while "n" is Gaussian distributed with STD=sigma as chosen by the client and sigma<=sigma_max as defined by the mixer, and he(%) is the "house edge" of the mixer's payback randomization service)! Whether the "house edge" of this gambling element is 0% or actually more (i.e. mixer takes extra fee for this randomization/obfuscation element) is up to the mixer policy. The "provably fair" verification of the "gambling randomization" would also have to be part of the API, so that the client can verify that this randomization is really fair. The payout times of the mixer should have a variable delay relative to the incoming payments, to make tracking even more difficult. Etc.)
While writing this, I think it would be good to define a BIP for a mixer-client API that supports all these features *. Does anyone know if this has happened already?
After a while, I assume that an infrastructure of mixers will evolve, similarly to the infrastructure of mining pools that we know today. They can differentiate from each other w.r.t. server location/jurisdiction, fee structure, blockchain trackability defense mechanisms (see examples above), etc.
* If you guys think this makes sense, I may start to work on the definition of such a BIP. Sorry this is OT for CoinJoin (albeit related), but the ideas developed while writing this. Further discussions on this in a separate thread I guess(?), if considered useful.
-------------------------------------------------------------------
2nd topic:
Idea how to minimize the likelihood of a CoinJoin sybil attack (i.e. that the N-1 co-participants of my CoinJoin transaction are "3-letter-hostile-organization spies"):
- I initiate TWO CoinJoin transactions instead of just one, of equal output size, and at about the same time, but I inject them at different points of the network if possible (so that an observer does not know they both origin from me).
- When all co-participants have completed their inputs to reach the number N (here I assume N=10 or so at least), I check if BOTH of my inputs show up amongst these N.
- If yes, I can fairly assume that the CoinJoin server did not get flooded with 3-letter-hostile spying-transactions and also the other N-2 inputs are probably legit, and I will sign my two transactions.
- If no, I must assume that the other N-1 transactions are hostile and my second input has been "squeezed-out" and pushed to the next CoinJoin transactions, and I better refrain from signing and try again later. Or I sign anyway (because my non-signing might get interpreted as a DOS attack) but then initiate another CoinJoin transaction were hopefully both of my inputs will show up then...
Pretty embarrassing that the Bitcoin ecosystem can't keep up with a couple year old feature.
This, I don't want to make this off-topic cause coinjoin is a great feature, but P2SH is also another important feature. I am surprised Armory doesn't support it since it uses the bitcoind/bitcoin-qt as a backend. To what extent I don't know but it should be easy to add at least sending to that type of address.
Quote from: etotheipi
Yes, I've resisted updating the interface to support this because changing the supported address formats without exhaustive testing can lead to money-losing bugs. The change is, at its core, quite simple. But making sure it's integrated correctly is not.
After 0.90 is released, I'll do the upgrade to support sending to P2SH addresses for 0.91. When I finally implement multi-sig in the wallets, I'll make sure that the interface works with it naturally.
After 0.90 is released, I'll do the upgrade to support sending to P2SH addresses for 0.91. When I finally implement multi-sig in the wallets, I'll make sure that the interface works with it naturally.
OK that sounds promising. Yeah he working on a whole bunch of features for those new wallets.
Besides, I haven't seen a Coinjoin implementation supporting it! So instead of sending donations to the fund address I send to your personal donation address.
Mine does (as outputs, at least). Using P2SH inputs safely requires a message signing algorithm compatible with multi-sig scriptPubKeys. This is a separate problem that does need to be solved as well.
I came to this thread late and it may have been mentioned before, but the other day over on Twitter @puellavulnerata mentioned an interesting idea that may be combined with this:
https://twitter.com/puellavulnerata/status/401366089159815168
The idea is to use coinbase transactions for mixing. People would send payments to a cooperating miner in the form of large transaction fees and the miner would then add redistribution outputs to its normal list of outputs. One advantage would be that such a transaction would enlist the help of the miners in the (probably anonymous) mining pool. The fact that the transactions with large fees look suspicious while ordinary joint transactions don't would be a disadvantage. I'm not sure if the coinbase idea can be used to improve the CoinJoin system, but I think it's worth thinking about.
https://twitter.com/puellavulnerata/status/401366089159815168
The idea is to use coinbase transactions for mixing. People would send payments to a cooperating miner in the form of large transaction fees and the miner would then add redistribution outputs to its normal list of outputs. One advantage would be that such a transaction would enlist the help of the miners in the (probably anonymous) mining pool. The fact that the transactions with large fees look suspicious while ordinary joint transactions don't would be a disadvantage. I'm not sure if the coinbase idea can be used to improve the CoinJoin system, but I think it's worth thinking about.
This won't work. In case there is a chain re-org, the fee will be grabbed by a different miner
Someone should create a site where you enter a P2SH address, it gives back a traditional address, and when it receives money at the traditional address, it immediately forwards the unconfirmed BTC to the P2SH address. (Unmodified Bitcoin-Qt can do this sort of thing, I think.) Not terribly secure, but better than giving up on advanced features entirely.
If anyone wants me to forward their funds to that just pm me. I have done many escrows and I can do coin control (I have he patch) so you would be able to track it and make sure. You would have send some extra to make sure I have enough for transaction fees.
I came to this thread late and it may have been mentioned before, but the other day over on Twitter @puellavulnerata mentioned an interesting idea that may be combined with this:
https://twitter.com/puellavulnerata/status/401366089159815168
The idea is to use coinbase transactions for mixing. People would send payments to a cooperating miner in the form of large transaction fees and the miner would then add redistribution outputs to its normal list of outputs. One advantage would be that such a transaction would enlist the help of the miners in the (probably anonymous) mining pool. The fact that the transactions with large fees look suspicious while ordinary joint transactions don't would be a disadvantage. I'm not sure if the coinbase idea can be used to improve the CoinJoin system, but I think it's worth thinking about.
https://twitter.com/puellavulnerata/status/401366089159815168
The idea is to use coinbase transactions for mixing. People would send payments to a cooperating miner in the form of large transaction fees and the miner would then add redistribution outputs to its normal list of outputs. One advantage would be that such a transaction would enlist the help of the miners in the (probably anonymous) mining pool. The fact that the transactions with large fees look suspicious while ordinary joint transactions don't would be a disadvantage. I'm not sure if the coinbase idea can be used to improve the CoinJoin system, but I think it's worth thinking about.
Send from the Bitcoin Qt client, I think it's the only client that supports these P2SH address types. (beginning with a 3)
Pretty embarrassing that the Bitcoin ecosystem can't keep up with a couple year old feature. It's not the only thing, some websites will, electrum will, the SX tools will. But armory, nothing bitcoinj based, or blockchain.info will. It's a real bummer because I think that using a multi-signature escrow is the right and proper thing to do here. I don't think I should personally be holding money set aside for this— my computer security is good, but I think no single person should be entrusted with holding non-trivial amounts of other folks money. How many bitcoins have been stolen that could have been avoided if the norm was to use in blockchain escrows for things, but people didn't because of silly wallet compatibility?
(And perhaps people will understand that I'm really not being a rabid bitcoin-qt advocate when I say that I'm not super eager to see lots of alternative implementations, they really do complicate the ecosystem and make new features harder for people to use) [/OT]Besides, I haven't seen a Coinjoin implementation supporting it! So instead of sending donations to the fund address I send to your personal donation address.
Pretty embarrassing that the Bitcoin ecosystem can't keep up with a couple year old feature.
This, I don't want to make this off-topic cause coinjoin is a great feature, but P2SH is also another important feature. I am surprised Armory doesn't support it since it uses the bitcoind/bitcoin-qt as a backend. To what extent I don't know but it should be easy to add at least sending to that type of address.
Jump to: