Bitcoin Forum
November 13, 2024, 10:22:24 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
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 36 37 38 »
  Print  
Author Topic: CoinJoin: Bitcoin privacy for the real world  (Read 294649 times)
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1104


View Profile
September 11, 2013, 10:24:48 AM
 #141

.... there should be a mechanism how to "RESIGN" mixing large transaction A1+B1+A2 -> X2+Y1+X1+Y2. If both A and B sign this and add a slighly better fee, it will be mined.

You don't actually need a larger fee.  Once the block size limit is hit, "better" means a larger fee per kb.

If miners can swap 2 transactions that are 250 bytes each with 1 transaction that is 400 bytes, then that gives them 100 bytes to use for other fee paying transactions.

This creates the right incentives on both sides.  If your client signs a "resign" transaction, then it can save you fees and the miners have an incentive to use that lower fee transaction instead of the 2 originals, since it pays more per byte.

However, the problem is that someone monitoring all the transactions will see the original transaction and so can link the outputs with inputs.  However, the info wouldn't be included in the block chain.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
gmaxwell (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
October 15, 2013, 07:23:39 AM
 #142

On this general subject, I've been enjoying Peter Todd's dust-b-gone: https://github.com/petertodd/dust-b-gone/

It works with Bitcoin-qt / bitcoind and scans your wallet for tiny coins and signs them off to be joined away... both thwarting dust payment deanonymization attempts and defragmenting your wallet a bit.  I wish Peter would do the last bit of effort to figure out how to produce a windows binary like p2pool has to make it easier for people to use. Smiley

(I've audited it and test it, and I consider it perfectly safe to use as of the current version)
hashman
Legendary
*
Offline Offline

Activity: 1264
Merit: 1008


View Profile
October 15, 2013, 09:12:39 AM
 #143

Thanks for this thread GM et al.!

A couple issues perhaps you can help me with. 

1) Coinjoin as I see it adds some plausible deniability but the taint is still there.  Anonymity is probably not the right word.  If one of the input addresses is considered a red flag, all you've done at the end is generate a little extra work for researchers who now need to follow all the outputs to see who took the money.  As I understand it, the zerocoin protocol does no better.. and in fact to do better is impossible because if we can't follow the money, we don't know it's real.  Trustworthy private mixers on the other hand could offer some real anonymity.  To spell this out further, I have some coins at address 1A and I want them moved to address 1B with no public record of ever having been associated in any way with 1A.  Can coinjoin do that?  No. Can zerocoin?  No.  I guess this is what you meant by certain users able to pay for better anonymity will not bother with coinjoin. 

2) Dust payment deanonymization?  Huh?  All payments / TXs are already public.  How does adding a dust address to somebody's addy change anything?  This cannot be the motivation for a dust-to-old-addresses sender.  There is already a tag marking every address on the blockchain: the address.  I want to hear more about this "R" attack.   
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
October 15, 2013, 09:26:01 AM
 #144

1) Coinjoin as I see it adds some plausible deniability but the taint is still there.  Anonymity is probably not the right word.  If one of the input addresses is considered a red flag, all you've done at the end is generate a little extra work for researchers who now need to follow all the outputs to see who took the money.

The way I see it, this is not true. No amount of extra work will enable researches (or whoever) to prove address X is now the owner of the "red flag coins". Any of the output addresses of the coinjoin tx could be the "real" owner.

Please explain if I'm wrong.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
hashman
Legendary
*
Offline Offline

Activity: 1264
Merit: 1008


View Profile
October 15, 2013, 09:43:35 AM
 #145

1) Coinjoin as I see it adds some plausible deniability but the taint is still there.  Anonymity is probably not the right word.  If one of the input addresses is considered a red flag, all you've done at the end is generate a little extra work for researchers who now need to follow all the outputs to see who took the money.

The way I see it, this is not true. No amount of extra work will enable researches (or whoever) to prove address X is now the owner of the "red flag coins". Any of the output addresses of the coinjoin tx could be the "real" owner.

Please explain if I'm wrong.


You're right, this removes proof that the funds were yours.  You have plausible deniability.  They only could be yours, as your address is one of those publicly associated with the red flag coins.  As you can tell this is somewhat different to the functionality of a tumbler, where at the end of the day your new address is not associated with the red flag coins on the public record.       
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
October 15, 2013, 01:03:58 PM
 #146

1) Coinjoin as I see it adds some plausible deniability but the taint is still there.  Anonymity is probably not the right word.  If one of the input addresses is considered a red flag, all you've done at the end is generate a little extra work for researchers who now need to follow all the outputs to see who took the money.

The way I see it, this is not true. No amount of extra work will enable researches (or whoever) to prove address X is now the owner of the "red flag coins". Any of the output addresses of the coinjoin tx could be the "real" owner.

Please explain if I'm wrong.


You're right, this removes proof that the funds were yours.  You have plausible deniability.  They only could be yours, as your address is one of those publicly associated with the red flag coins.  As you can tell this is somewhat different to the functionality of a tumbler, where at the end of the day your new address is not associated with the red flag coins on the public record.      

I understand you reasoning, but I'm not sure this distinction can be made:

If you argue using coin taint, consider that you might also end up with other tainted coins -- let's say some purple coins -- coming from your traditional tumbler. The tumbler doesn't magically give you "clean" coins either (unless it distributed freshly mined ones somehow, and here you can see the upside of buying mining contracts and such, but that's not tumbling, but selling clean coins), but give you coins from other users, likely to have some bad taste to them, too.

So tumbling the coins equally leaves you with nothing more than plausible deniability and a bunch of tainted coins. You might have successfully removed your red taint, but are now stuck with purple taint.

I don't quite see a qualitative difference here.

Maybe we'd have to define more exactly the goal(s) we want to achieve here?

If we want to make bitcoin more anonymous in general, for example, widespread frequent casual use of coinjoin seems to be a very good way.

If we want to specifically and completely remove a certain colored taint from some coins, the use of a traditional "laundry" may be more adequate.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
AnonyMint
Hero Member
*****
Offline Offline

Activity: 518
Merit: 521


View Profile
October 15, 2013, 05:26:57 PM
 #147

I am not sure if anyone mentioned this upthread, but the security of mixing means trusting the other parties to not link their input identity with their output identity (which they could do by not anonymizing their IP address successfully or spending patterns that can be analyzed). Thus the anonymity and privacy obtained is unpredictable.

unheresy.com - Prodigiously Elucidating the Profoundly ObtuseTHIS FORUM ACCOUNT IS NO LONGER ACTIVE
gmaxwell (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
October 15, 2013, 05:29:59 PM
 #148

Thus the anonymity and privacy obtained is unpredictable.
It is never less than not including their inputs at all.
Murphant
Jr. Member
*
Offline Offline

Activity: 38
Merit: 3


View Profile
October 15, 2013, 05:57:45 PM
 #149


If we want to specifically and completely remove a certain colored taint from some coins, the use of a traditional "laundry" may be more adequate.


If we assume that laundries are easily identifiable on the network, I disagree that using one actually removes the taint. If tainted coins enter a laundry, then any coins exiting the laundry from that point on will share some of that taint, including the coins that the original owner of the tainted coins got back. Thus the result is the same as using CoinJoin, although the taint dissipation is executed faster in the laundry case.
gmaxwell (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
October 15, 2013, 06:05:11 PM
Last edit: October 15, 2013, 06:22:30 PM by gmaxwell
 #150

1) Coinjoin as I see it adds some plausible deniability but the taint is still there.  Anonymity is probably not the right word.  If one of the input addresses is considered a red flag,
This is really a question for how _much_ these tools are used. What you're pointing to is that there is an information leak whenever the anonymity set is less than all users of the system. It's actually even worse than that: only a very small fraction of the world uses Bitcoin at all: So even if every transaction were anonymous internally to Bitcoin there would still be an information leak from the fact that you used Bitcoin at all.  The same kind of thing exist for any other anonymity system: Even if Tor was perfect, you'd still be a member of the tiny set of people using Tor (or had even heard of it), and in practice there are far more leaks than that (time of day, subject matter interests, languages spoken, etc).

What this says to me is that trying to draw a hard line at "no information loss" is misguided because no system can actually achieve that when you consider all possible information sources (and, of course, real attackers are not confined to stay within the bounds of your pretty little system: they will consider all possible information sources).

In general I prefer to say these are techniques to improve your privacy. In the conventional understanding of the word privacy we realize that privacy is seldom absolute.  Because of the public ledger Bitcoin's privacy is very fragile.  With current use practices today snooping so simple that webpages automate it for you easily can tell you all kinds of information about who transactions with who, and how much coin they have, how much they're earning, etc. You can't always answers these questions totally cold, but as soon as someone sends you funds you have a piece of yarn to yank on, and often their privacy will more or less completely unravel.

If zero information leak is not generally obtainable then what should we consider private or anonymous?  It depends a lot on the situation and the people involved.  But in considering something as a tool to improve privacy I don't need to draw bright lines: More privacy is better than less (when you actually want non-privacy you can always selectively disclose to the parties you wish to disclose to).

Besides, there are not-quite-privacy related motivations here too: Bitcoin's privacy limitations are a fungibility risk: If blacklisted coins become the norm Bitcoin may become unattractive to trade with because no one wants the risk of finding out they accepted a black coin, or we could potentially lose decentralization because accepting a feed from some centralized blacklisting authority may be the only reliable way to avoid receiving a black coin. Even if coinjoin usage did nothing to make anyone "anonymous" if it made attempts at large scale coin blacklisting cause too much collateral damage and fail at birth, that would be enough justification for it.

My thinking here is if the tools are easy and cheap they can be used very widely. Above all other criteria widespread usage is what makes the difference between your "plausible denyability" and whatever you'd call actual "anonymity". I'm also more generally concerned with more casual levels of privacy:  I don't want the guy at the coffee shop knowing my income or net worth. I don't want my landlord raising my rent because he see that I can afford it. I don't want my inlaws scrutinizing my purchases. Privacy is important to personal autonomy and dignity, and financial privacy can be important to protecting you from thieves and discrimination.

But because these risks are individually low probability and distant I don't want to put my funds at risk or pay a bunch of fees to achieve it. This takes "laundry" services mostly off the table as they have monitoring risk (mostly not my concern), theft risk, and fees. More abstractly, since I think other boring users would also conclude the same thing, I might expect 99% of the funds involved in such a service to be the proceeds of crimes. While recovering my privacy might be worth some risk of being falsely implicated in someone elses crime, paying for the privileged of having a 99% chance of receiving crime involved coins would be a bad deal.  Anonymity systems with only one kind of user really are useful to no one, and to be useful to common boring users overheads like fees and theft risk need to be eliminated.  I believe that relative to the overall scale of the economy criminal activity is small, but that only matters if you have privacy mechanisms the whole economy will participate with.

Quote
How does adding a dust address to somebody's addy change anything?  This cannot be the motivation for a dust-to-old-addresses sender.  There is already a tag marking every address on the blockchain: the address.  I want to hear more about this "R" attack.  
Assuming no coinjoin or shared wallet usage, when a transaction spends two coins paid to different addresses you can make a assumption that the a common party is probably the 'owner' of all the involved keys and the sender of the transaction.  Prior to the transaction you may not have had any information that those three 'identities' (coin1 scriptPubKey, coin2 scriptPubKey, and the party paying you) were one and the same.

When someone transacts in the intended way with a fresh address for every transaction the information leak is minimized: no more interconnection happens than is strictly needed, and the interconnection doesn't snowball.

If, after you've exhausted the funds sent to a particular scriptPubKey, someone sends you a tiny amount of coin to that scriptPubKey and you spend it in a new transaction then whatever linkage they knew carries forward and your deanonymization grows as a sufficiently small payment will only be useful when spent in combination with other coins. After several applications of this its very likely that all addresses in that wallet become publicly interconnected.  Turning a theoretical weakness ("You might not be very private") into an actual one.

Since those payments are necessarily small (when used to attack all users generically) and since they were non-solicited I think giving them away in coinjoin transactions is an elegant countermeasure: Its as least as good as never spending them, but it also sweeps the crud out of the UTXO set and salts the public ledger with misleading information.
AnonyMint
Hero Member
*****
Offline Offline

Activity: 518
Merit: 521


View Profile
October 15, 2013, 06:32:50 PM
Last edit: October 15, 2013, 07:48:16 PM by AnonyMint
 #151

Thus the anonymity and privacy obtained is unpredictable.
It is never less than not including their inputs at all.

Agreed. However, the former can't relied on any more than the latter with any certainty. So what is the point of depending on it?

The only reliable solution is to source your coins in small values, so you don't need to split value. Yet this is not possible if the payer is splitting and paying you numerous times, e.g. an employer. You can launder them to cash or through mining hardware.

Plus all mixers may eventually be tainted. At least mining can't be tainted (assuming the coin forces all miners to anonymize their IP or you don't need to for the level of privacy you need).

Plus subject to DoS attacks if we don't use zero knowledge.

And it would be much more amenable to the law enforcers if we don't mix our coins with potentially illegal activity.

unheresy.com - Prodigiously Elucidating the Profoundly ObtuseTHIS FORUM ACCOUNT IS NO LONGER ACTIVE
hashman
Legendary
*
Offline Offline

Activity: 1264
Merit: 1008


View Profile
October 17, 2013, 09:43:19 AM
 #152

1) Coinjoin as I see it adds some plausible deniability but the taint is still there.  Anonymity is probably not the right word.  If one of the input addresses is considered a red flag,
This is really a question for how _much_ these tools are used. What you're pointing to is that there is an information leak whenever the anonymity set is less than all users of the system. It's actually even worse than that: only a very small fraction of the world uses Bitcoin at all: So even if every transaction were anonymous internally to Bitcoin there would still be an information leak from the fact that you used Bitcoin at all.


I guess I wasn't getting that deep, sorry.  Just pointing out that in coinjoin there is still some fractional taint visible on the blockchain.  If we trade private keys off-chain then we can control money with 0 taint.  Well, 0 taint on blockchain anyway, but still taint in some other ways you describe.  Anyway, more privacy is better so thanks for spelling it out for us Smiley 


Quote

If, after you've exhausted the funds sent to a particular scriptPubKey, someone sends you a tiny amount of coin to that scriptPubKey and you spend it in a new transaction then whatever linkage they knew carries forward and your deanonymization grows as a sufficiently small payment will only be useful when spent in combination with other coins. After several applications of this its very likely that all addresses in that wallet become publicly interconnected.  Turning a theoretical weakness ("You might not be very private") into an actual one.


OK, I hadn't caught the bit about sending the dust to empty wallets only.  Still seems a bit odd but now I understand what y'all been talking about Smiley  Seems like coincontrol is getting more and more necessary. 
Financisto
Hero Member
*****
Offline Offline

Activity: 640
Merit: 771

BTC⇆⚡⇄BTC


View Profile WWW
October 18, 2013, 04:11:52 AM
 #153

Coinjoin is a great idea.

Not because it is theorically brilliant, but because it is rather pragmatic.

It's way uncomplicated in order to implement than Zerocoin alternative.

I'm gonna pay close attention to this thread and to the development of it.

Keep up the good work.

Cheers!

LIST • ESCROW providers • Ranking & ScoresLIST • FOSS BrainwalletsBTC ⇆⚡⇄ BTCBTC aka BTC: 16MBvhaJoRBxW3Vk6apnvz3UYT9HAgraVS ⚡ PGP: 2680207AA9A1B69FE7A033D80DE0F221074384C4 ⚡ If you think freedom matters, please support the development of these privacy projects→DONATE some sats: TailsQubes OSWhonixVeraCryptPicocryptKryptorSimpleX Chat
n8rwJeTt8TrrLKPa55eU
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
October 19, 2013, 10:37:02 PM
 #154

It looks like blockchain.info is rolling out a CoinJoin service under the name "Sharedcoin Trustless Mixing".  For non-b.i users, piuk says there will be a browser extension eventually available.

Sharedcoin trustless mixing now available for testing

Sharedcoin uses a technique known as coinjoin to provide coin mixing without needing to trust any third party with your funds. The service still relies on a centralised server but that server only co-ordinates transactions without any funds passing through it. The main advantages are significantly less risk for both the user and operator and no requirement to keep any logs.

Anyone interested in testing can login using the following link:

https://blockchain.info/wallet/login?enable_sharedcoin=true

Please test with small amounts only (0.5 BTC max). 0.1 BTC is the minimum send amount. If you experience any errors please record the output from the javascript console.

The current client stages are:

- The client will submit its "offer", which is the inputs it wants mixing and the desired outputs.
- The server waits a certain amount of time for other clients to submit their offers.
- The server combines everyone's offers and creates a "proposal".
- The clients check they are happy with the proposal and signs their inputs.
- The server submits the final transaction.

The entire process takes about 40 seconds.

Features currently supported:

- Variable number of inputs and outputs per client
- Variable input and output values.
- Randomised fees.
- Ability to draw upon reserve funds when no other participants are available for mixing.
- Taint analysis determines the appropriate inputs to mix.

Features planned:

- Multiple iterations using temporary addresses never saved inside wallets.
- Better randomisation of change outputs and splitting of outputs between multiple iterations.
- Better progress indication.
- Documented Client APIs and SDK.

Example sharedcoin transaction:
 https://blockchain.info/tx/72316782bf48d0cd232b888a7b9ea03f88ba79fac28273cd2aa1804683235412?show_adv=true

The amount currently available in the reserve pool is low, this will be gradually increased over time but during the testing phase if anyone manages to manipulate the client to withdraw excess funds from the pool they can keep that amount.

Client source available at: https://github.com/blockchain/My-Wallet/blob/master/sharedcoin.js
Server status can be viewed while testing at: https://api.sharedcoin.com/
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1160


View Profile
October 19, 2013, 10:46:49 PM
 #155

It works pretty well, although currently there's a serious privacy problem because the pool uses compressed keys, while the blockchain.info client only uses compressed keys, even for sharedcoin change. To figure out where the money came from and went you just have to match up uncompressed inputs to uncompressed outputs. In addition to that the pool re-uses addresses, and the client doesn't, so it's pretty easy to figure out which addresses are in the pool and use them to isolate the client addresses.

Having said that, both problems can be easily fixed.


gmaxwell (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
October 30, 2013, 08:00:19 AM
 #156

I guess I wasn't getting that deep, sorry.  Just pointing out that in coinjoin there is still some fractional taint visible on the blockchain.
So, does this make you happy?

I still don't agree that it's quite the amount of qualitative difference you were drawing, but considering that the alternative will potentially gain regular escrow users in their anonymity set, perhaps its more interesting to you.
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
October 30, 2013, 04:17:01 PM
 #157

Quote
Anonymity systems with only one kind of user really are useful to no one, and to be useful to common boring users overheads like fees and theft risk need to be eliminated.  I believe that relative to the overall scale of the economy criminal activity is small, but that only matters if you have privacy mechanisms the whole economy will participate with.
I really like this idea. Simple and practical. It foils the most obvious attempts to correlate addresses and follow money (by using just the blockchain) without requiring users to have to engage in suspicious behaviour such as using a laundry. It can also be automated pretty well.
I'd like to include support for this in the Bitcoin-Qt client, once we figure out how a user friendly interface for this could work.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
gmaxwell (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
October 30, 2013, 04:30:47 PM
 #158

I really like this idea. Simple and practical. It foils the most obvious attempts to correlate addresses and follow money (by using just the blockchain) without requiring users to have to engage in suspicious behaviour such as using a laundry. It can also be automated pretty well.
I'd like to include support for this in the Bitcoin-Qt client, once we figure out how a user friendly interface for this could work.
I suppose one way to go about the interface would be to first add some infrastructure for queued/delayed transactions. E.g. you could tell it {I want to pay 1AAA, with a timeout of N seconds} and it queues it and returns just a locally significant handle instead of a TXID (and in the GUI shows it in some queued transactions tab). This could obviously be used purely locally to merge multiple outputs of your own into a sendmany.  With that in place, I think casual coinjoins (where you're not trying super hard to match values, and only making them where you would have otherwise made a payment) would have no further interface impact except a switch to enable/disable using them to process queued transactions.
Rassah
Legendary
*
Offline Offline

Activity: 1680
Merit: 1035



View Profile WWW
October 31, 2013, 05:33:47 AM
 #159

Did Amir's implementation of this go down? The Tor site is inaccessible. Are there any other places where this is currently usable?
Anon136
Legendary
*
Offline Offline

Activity: 1722
Merit: 1217



View Profile
November 02, 2013, 08:22:44 PM
 #160

what happens if the facilitator is compromised?

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
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 36 37 38 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!