Topic: CoinJoin: Bitcoin privacy for the real world - page 31. (Read 294672 times)

For transactions where I'm not in a rush - and am willing to leave my bc.i client running - think you could add an advanced option where you give the wallet a destination address and a timeout and it waits until someone else is available to do a coinjoin?

That's no better than the two-party case though - you have no idea if anyone else in the p2p network, facilitator or not, is real or part of a sybil attack, and it's still going to be slower to complete a transaction than the two-party alternative.

That's why you use multiple facilitators, and act as act as facilitator yourself 1/N of the time. The implementation I'm working on is fully p2p.

Thank you! This is great news.


I replied to maaku's crowd-fund proposal with similar concerns. In the general case I think blind-signing is a overly complex cryptographic solution looking for a problem. What you describe is just a particularly bad example of how it doesn't actually give you any anti-sybil protection if you don't know who the counterparts to the transaction are. I proposed that two-party mixes be used in the general case. The cryptography required is almost trivial and can be done with existing libraries used for their intended purpose, the user experience is good because the transactions can happen almost as fast as regular ones and it's easy to do the negotiations on the existing P2P network, and finally the anti-sybil resistance claimed is much more honest: we know we can't prevent sybil attacks, but we can make them cost a lot of transaction fees.

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.
 


It uses a hybrid approach mixing with other clients and a pool provided by the server. The advantage to this approach is a) there is no long wait time needed for other clients to join in your transaction (hence easier to bootstrap if usage is low initially) b) the server always has a large pool available which can be used to reduce transaction taint more effectively. Browser extension coming soon.


I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund proposal, outputs are blinded so neither the facilitator nor any of the participants know which outputs belong to any of the others. So the facilitator doesn't have to be trusted, other than to complete the protocol. Genjix's server doesn't use blind signing & anonymous revelation, so I'd imagine you'd be able to trace ownership from the facilitator's logs (I haven't looked at his code, however).

what happens if the facilitator is compromised?

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

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.

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.

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.

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.

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.

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!

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  



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   Seems like coincontrol is getting more and more necessary. 

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.

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.

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.

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.

It is never less than not including their inputs at all.

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.