Bitcoin Forum
June 28, 2017, 04:07:57 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
Author Topic: CoinJoin: Bitcoin privacy for the real world  (Read 252766 times)
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
November 16, 2013, 10:11:23 PM
 #261

It's a perfectly valid address. You just need to use Bitcoin-Qt or another sane wallet application.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
1498666077
Hero Member
*
Offline Offline

Posts: 1498666077

View Profile Personal Message (Offline)

Ignore
1498666077
Reply with quote  #2

1498666077
Report to moderator
1498666077
Hero Member
*
Offline Offline

Posts: 1498666077

View Profile Personal Message (Offline)

Ignore
1498666077
Reply with quote  #2

1498666077
Report to moderator
1498666077
Hero Member
*
Offline Offline

Posts: 1498666077

View Profile Personal Message (Offline)

Ignore
1498666077
Reply with quote  #2

1498666077
Report to moderator
POLONIEX TRADING SIGNALS
+50% Profit and more via TELEGRAM
ALTCOINTRADER.CO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1498666077
Hero Member
*
Offline Offline

Posts: 1498666077

View Profile Personal Message (Offline)

Ignore
1498666077
Reply with quote  #2

1498666077
Report to moderator
Carlton Banks
Legendary
*
Offline Offline

Activity: 1680



View Profile
November 16, 2013, 10:12:02 PM
 #262

CoinJoin needs to be nicely implemented in Bitcoin-Qt before any of these ridiculous blacklist proposals take off. So for the next 30 days, I will match donations to the CoinJoin bounty fund (3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk), up to a maximum of 5 BTC. Just donate to that address, and in 30 days I'll donate the difference between the current received amount (16.21420773) and the received amount at that time (max 5 BTC).
Would like to donate 1BTC and possibly more.  blockchain.info says invalid address though.   Angry

Send from the Bitcoin Qt client, I think it's the only client that supports these P2SH address types. (beginning with a 3)

Vires in numeris
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
November 16, 2013, 10:23:12 PM
 #263

CoinJoin needs to be nicely implemented in Bitcoin-Qt before any of these ridiculous blacklist proposals take off. So for the next 30 days, I will match donations to the CoinJoin bounty fund (3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk), up to a maximum of 5 BTC. Just donate to that address, and in 30 days I'll donate the difference between the current received amount (16.21420773) and the received amount at that time (max 5 BTC).
Would like to donate 1BTC and possibly more.  blockchain.info says invalid address though.   Angry

Send from the Bitcoin Qt client, I think it's the only client that supports these P2SH address types. (beginning with a 3)

Electrum does as well.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2226



View Profile
November 16, 2013, 10:24:22 PM
 #264

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?  Sad  (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]

Bitcoin will not be compromised
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
November 16, 2013, 10:30:41 PM
 #265

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.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2702


View Profile
November 16, 2013, 10:34:40 PM
 #266

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
November 16, 2013, 10:42:28 PM
 #267

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.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
November 17, 2013, 12:27:25 AM
 #268

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.
https://github.com/etotheipi/BitcoinArmory/issues/127

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.
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
November 17, 2013, 01:34:07 AM
 #269

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.
https://github.com/etotheipi/BitcoinArmory/issues/127

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.

OK that sounds promising. Yeah he working on a whole bunch of features for those new wallets.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
oakpacific
Hero Member
*****
Offline Offline

Activity: 798


View Profile
November 17, 2013, 08:46:53 AM
 #270

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?  Sad  (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.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
mmeijeri
Hero Member
*****
Offline Offline

Activity: 714

Martijn Meijering


View Profile
November 17, 2013, 09:19:09 AM
 #271

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.

ROI is not a verb, the term you're looking for is 'to break even'.
jl2012
Legendary
*
Offline Offline

Activity: 1624


View Profile
November 17, 2013, 01:56:57 PM
 #272

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.

This won't work. In case there is a chain re-org, the fee will be grabbed by a different miner

Donation address: 1CxPk7mhhe2uCDosQraSMeCdgvwWHfLSQx
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Bitcoin Wizards Wiki: https://8333.info/
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
November 17, 2013, 05:54:35 PM
 #273

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'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Michael_S
Sr. Member
****
Offline Offline

Activity: 278


Bitcoin-Note-and-Voucher-Printing-Empowerer


View Profile
November 17, 2013, 11:35:45 PM
 #274

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 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...

mxmz.in
Full Member
***
Offline Offline

Activity: 123


View Profile
November 18, 2013, 12:54:44 AM
 #275

...
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?
Michael_S
Sr. Member
****
Offline Offline

Activity: 278


Bitcoin-Note-and-Voucher-Printing-Empowerer


View Profile
November 18, 2013, 01:21:57 AM
 #276

...
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?
In my view I'd say "yes". That's what I meant when I said the client (wallet) SW should support the user in his coin control.
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.

dserrano5
Legendary
*
Offline Offline

Activity: 1834



View Profile
November 18, 2013, 10:53:57 AM
 #277

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.

Murphant
Jr. Member
*
Offline Offline

Activity: 35


View Profile
November 18, 2013, 05:41:14 PM
 #278

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.

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...

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.
Michael_S
Sr. Member
****
Offline Offline

Activity: 278


Bitcoin-Note-and-Voucher-Printing-Empowerer


View Profile
November 18, 2013, 08:36:40 PM
 #279

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.
Ok, this might slightly improve it at first glance, but I am not at all convinced that it really does. Maybe it does the contrary.

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.

Michael_S
Sr. Member
****
Offline Offline

Activity: 278


Bitcoin-Note-and-Voucher-Printing-Empowerer


View Profile
November 18, 2013, 08:47:59 PM
 #280

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.
Thanks, I will have a look at CoinSwap...

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...

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 agree this "solution" of mine is far from optimum... I also agree with your last sentence, it can't be pointed out clearly enough that CoinJoin just provides low anonymity, and I think there is high probability that the normal user will succumb to the fallacy that CoinJoin is really providing great anonymity, and it will be communicated by the media etc. in this simplistic way as well, I predict (unless they read this posting). So the users are happy, the NSA is happy, the gov't as well, so everyone is happy. Everybody has peace of mind, and the informed user can still care about his anonymity by CoinControl and other techniques... So everyone is happy.

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.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!