CoinJoin: Bitcoin privacy for the real world

[Peter Todd]

jdillon: I think all your points are reasonable ones.

I'd advise people doing work on this stuff to write robust mechanisms first, and only then follow up with GUI's and other gloss. The experts who should be playing with these tools initially don't need GUI's to do so.

I'd also advise people to release implementations that only work on testnet until enough time has passed to have some hope that the bugs have been shaken out - it's easy to lose money fast with wallet related code and we can't afford to get people burned initially.

[1713866275]

1713866275

[1713866275]

1713866275

[TheButterZone]

Oh come on, who does a live test anywhere near keys with 200 BTC on them? That's staggering confidence.

[genjix]

Hi ppl, this is Pablo, co-implementor of CoinJoin proof of concept with Amir (sorry don't have an account here so writing through Amir's account):

New "release" of CoinJoin, features:

 * Server now has a public "lobby" to serve as meeting point (front page announcing "open" coinjoins)
 * Creator of coinjoin can choose amount, so its no longer just 0.01, now you can join arbitrary amounts
 * The client can now resume the session in different runs, so you can actually run it in several times to finish the coinjoin and wait for other ppl joining (you had to keep it open before).


You can check the video at (shows using the tool and lobby):

 * http://www.youtube.com/watch?v=rr6DeziHdFs

Test server still at:

 * http://7vxb75tbnszhy2go.onion

We keep working on the implementation and more features so donations welcome at: 1H1LP8UhGR5wK9WppBMwewCddwdebYqwwT
(ideas are the ones from his thread including: serverless setup, casual use for joining tx and fees...).

Code at: https://github.com/calafou/coinjoin, free and open source ;-)

Cheers!

[Peter Todd]

Code at: https://github.com/calafou/coinjoin, free and open source ;-)

You need to add a statement as to what license the code is released under; without one the code is not open source as all creative works are copyrighted by default.

[genjix]

You need to add a statement as to what license the code is released under; without one the code is not open source as all creative works are copyrighted by default.

You're right, added COPYRIGHT notice, made it AGPL for now, since this is proof of concept we will think about a more permissive license but we're comfortable with AGPL to encourage a more open ecosystem.

[genjix]

For one thing, the code has rather frightening constructs such as:

call("sx rawscript [ %s ] [ %s ] | sx set-input txfile.tx %s > signed-tx" % (signature, pubkey, input_index))

I would not in the least bit be surprised if there is either a shell exploit already present, or there will be one in the future. In addition there is no license for the code, and it depends on sx/libbitcoin with are AGPL licensed.

About calling external functionality through the shell, we're very aware this is a very dangerous practice, and are working towards more direct access to the libbitcoin functionality for all languages (https://gitorious.org/libbitcoin-bindings or new electrum like protocols implemented for all languages and easy to use) so these dangers won't exist. Just for the proof of concept this is the way that works now for us to keep testing and developing. We welcome all security auditing and will refactor the code to make security more explicit.

Please keep analizing the code and providing feedback, its really appreciated!.

Cheers!

[Mike Hearn]

(edit: deleted/rewrote some stuff about the agpl)

Ideally the implementation would be linkable into regular end user wallets so anyone can run a server, that's the more Bitcoinish way to doit, but the AGPL license prevents that as no existing wallet is licensed that way (and I doubt it will be changing).

This is I think one of the problems with the bounty model. You have very loose requirements and a "we'll make it up as we go along" payout model, you're going to get disappointment and problems, it's just inevitable. Nobody specified the license so now we have one that practically guarantees that server operators and end users are different people, for no good technical reason (ignoring the choice of language and tools which make it hard to ship on things like phones).

[Tom Scholl]

I hereby claim part of this bounty for my work on bitprivacy.

It is MIT licensed, and furthers the goal of making improved transaction privacy a practical reality for Bitcoin users. It might help if you clarify whether funds can be paid for work done before the setting up of this bounty. I'm assuming solutions don't need to be called coinjoin, if this isn't the case you should say.

It's great to see so many people contribute to this bounty.

If you want to help bitprivacy directly, you could try it out and post in the thread.

[CIYAM]

I created CIYAM Open (https://ciyam.org/open) to solve this silly bounty problem.

Instead of people racing to hack out the *first* solution (typically badly written) you instead ask for people to bid (going to be renamed *dib* soon) as to when they will come up with a quality solution - if their bid/dib is accepted then they are not competing against anyone apart from themselves (to complete the task by the deadline they provided themselves).

The first 10 projects to be listed on CIYAM Open can be fee free for life so if you are serious in getting a project done *properly* I would be happy to help out.

CIYAM Open also allows people to donate at either the Project, Project Area or specific Project Task level.

[grau]

Uh. Does someone have a bug to report for a tool from this thread?  (If you want you can report to me in pgp email anonymously.)

More likely someone had the wrong assumption on the value of a referred output.

These errors would be avoided by implementing SIGHASH_WITHINPUTVALUE https://bitcointalk.org/index.php?topic=181734.0

How many people need to burn themselves until we add this? Remembers me the history of introducing wallet encryption.

[Lauda]

Very interesting. I'm going to keep an eye out.

[Peter Todd]

(edit: deleted/rewrote some stuff about the agpl)

Ideally the implementation would be linkable into regular end user wallets so anyone can run a server, that's the more Bitcoinish way to doit, but the AGPL license prevents that as no existing wallet is licensed that way (and I doubt it will be changing).

Wallets aren't the only thing that matters: businesses will want to use this tech as well to keep their own finances private. The AGPL is IMO right out for that application - even the LGPL is problematic.

This is I think one of the problems with the bounty model. You have very loose requirements and a "we'll make it up as we go along" payout model, you're going to get disappointment and problems, it's just inevitable. Nobody specified the license so now we have one that practically guarantees that server operators and end users are different people, for no good technical reason (ignoring the choice of language and tools which make it hard to ship on things like phones).

The bounty fund will pay out as funds are available according to the signers best judgment for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.

Emphasis mine.

Sounds like the intent was for people to make a proposal, do work, and potentially collect a reward. That means there aren't any requirements until a proposal is made. As for donators, they should recognize that they are putting their faith in gmaxwell, theymos and sipa's best judgement. (something I myself am quite confident in)

Now if it was going to be undefined, I'd suggest they say that in 9 months or something funds to to whomever has made the most actual impact to getting CoinJoin technology actually used in this space. As jdillon suggested proposals that integrate into existing wallet software are most important there.

[Mike Hearn]

So far bitprivacy looks very interesting. I haven't reviewed the code at all, but the readme makes it sound like the kind of thing that's integratable directly into MultiBit or other wallets.

Support for Tor/fidelity bonds etc is all well and good but even a DoSable v1 would be a good upgrade for users today.

[maaku]

The bounty fund will pay out as funds are available according to the signers best judgment for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.

Emphasis mine.

Sounds like the intent was for people to make a proposal, do work, and potentially collect a reward. That means there aren't any requirements until a proposal is made.

I actually read that completely differently - that the bounty specifically requires support for the cryptographic anonymizing protocols that were proposed and discussed in the first few posts of this thread. Nevertheless, some clarity from he judges would be appreciated.

[gmaxwell]

I intended it as "make a proposal, do work, receive some baconreward". Obviously, if people want to appear with fully formed solutions they should get rewards too.  My main criteria is that work done be actually usable by someone for something, we're awash with ideas around here (myself included): so show me the code.  I am very much in support of the spirit here of just getting some stuff published and getting people trying it... this means both simple tools that don't implement a more complete vision, and more powerful ones too. The whole idea is to flow some funds from people who want to see this exist to people who are working on making it exist and everyone leaving happy, and so I think exposing a lot of really exacting procedural requirements isn't a grand idea.  (Also, it's likely the case that I didn't foresee all the things that needed to be done in my post. Please: solve problems I didn't know existed too.)

(And yes, I need to pay out some bounties to the work done by people so far ... I'm afraid that it's probably going to wait until this weekend before I can try out the tools and talk to the other signers! (and feedback from donors and other people who've tried the stuff out!))

[marcus_of_augustus]

I intended it as "make a proposal, do work, receive some baconreward". Obviously, if people want to appear with fully formed solutions they should get rewards too.  My main criteria is that work done be actually usable by someone for something, we're awash with ideas around here (myself included): so show me the code.  I am very much in support of the spirit here of just getting some stuff published and getting people trying it... this means both simple tools that don't implement a more complete vision, and more powerful ones too. The whole idea is to flow some funds from people who want to see this exist to people who are working on making it exist and everyone leaving happy, and so I think exposing a lot of really exacting procedural requirements isn't a grand idea.  (Also, it's likely the case that I didn't foresee all the things that needed to be done in my post. Please: solve problems I didn't know existed too.)

(And yes, I need to pay out some bounties to the work done by people so far ... I'm afraid that it's probably going to wait until this weekend before I can try out the tools and talk to the other signers! (and feedback from donors and other people who've tried the stuff out!))

This just the right sentiment to get us moving forward .... without wanting to pee in the OS punchbowl (forewarned is forearmed), it is also probably worth keeping in mind that there is likely a rather large pot of funding waiting in the wings with an eye towards commercialisation of the CoinJoin tech (or similar), whether it be through proprietary s/ware packaging or fees for a pay-per-tx models or whatever.

[gmaxwell]

A couple minutes ago Phantomcircuit directed me to this writeup, which I'd not see before. It's a great proposal and does better from a privacy perspective of my earlier suggestions of ZC + TOR or Cham+Tor.  And it's not especially new either! here we see the problem with just pumping out theory and not implementations: The activity in this thread is already more practically useful than that year old blog post.

In any case, they propose using multi-party computation to SORT a list of pubkeys provided by the participants.  This accomplishes two things:  Blinds the participants to whos keys is whos but makes sure that everyone knows that the pubkeys all came from the participants.  Using chaum accomplishes only the latter but would depend on using tor (or the like) to prevent participants from learning the mapping.  This is somewhat non-ideal if we want to be super paranoid about such things since tor is very vulnerable to timing analysis.

I'd looked into using MPC for this before but I was overthinking it and expecting the MPC to do too much and it didn't seem practical. It did not occur to me that we only needed a _sort_ to hide the correspondence.

So to make this real you need a multi-party computation system that can implement a sort:   Here you go: http://viff.dk/   to use it build it then run

./apps/generate-config-files.py 127.0.0.1:10001 127.0.0.1:10002 127.0.0.1:10003
then
./apps/sort.py  --no-ssl player-1.ini
./apps/sort.py  --no-ssl player-2.ini
./apps/sort.py  --no-ssl player-3.ini

(It appears to be a bit python bitrotted and doesn't actually work for me ATM)

The sort.py script is setup for three players providing inputs, and they pick random values to sort (with an array of size .. all of this can easily be adjusted.

The protocol requires log2^2(N) communications between all the participants. You'd have every player provide a pubkey, at the end they all get a sorted list and learn nothing about who sent what.

Downsides:

* Thats a boatload of communication for a lot of participants, especially since you'd still run this over tor to hide the inputting parties IPs. This means that you probably have to have all parties online and communicating in realtime... if people are only logging on once per day, an 8 party operation would take 10 days I think. (log2^2(N))

* The MPC implementation in viff only has security against passive attackers e.g. they might snoop but they follow the protocol.  VIFF has some code for a different kind of MPC which is secure against active attackers but I've never been able to get it to work before (in particular, it doesn't seem to have a comparison operator... which.. uh. sort really needs).

* Also, this is all expensive enough that it's probably not helpful for preventing DOS even if the activity model does let you detect which party is misbehaving.

Upside: no depending on TOR for hiding the mapping between parties, and stronger fundamental security than tor, to keep players identity secret from each other.

(Also downside— will take work to go implement this in an actual system )

[AnonyMint]

That is if there is no cost to having multiplexed transactions, unlimited number of public keys, and the delays and limited time windows of CoinJoin or the blockchain + hash check bloat of Zerocoin. I am also thinking of a Visa-scalable block chain. Your naive users will never be using Bitcoin any way, because the blockchain can't scale. By making CoinJoin popular, you will have further cemented Bitcoin's inability to modify the block chain design in this respect (although there may be a way to scale the block chain with multiplexed transactions and unlimited public keys, I am still studying this).

If there is no cost, I am not against it. I am arguing it is lower priority, not that it isn't worth considering if it fits into the big picture goals.

...
...
...

Look at the above. I am happy to have the world know I am giving 5BTC to this effort, and I am happy for Gregory Maxwell to know that it is me where the money is coming from. But why should I give the whole world insight into my finances? With CoinJoin I won't have to use something as convoluted as encrypting an access key, and the proposals above share a common thread of being such that all the actual complexity can be hidden away in software with a sufficiently sophisticated implementation.

So why not have a separate individual BTC pool of capital for those purposes where you explicitly want to be public? Else send him a paypal to his email address. (Personally I wouldn't be announcing publicly my ownership of Bitcoin, because I think the governments are going to demand capital gains taxes in arrears, when they declare it isn't money rather a good like gold).

My upthread solution basically was to use high-latency mix-net (which doesn't exist!) and always be anonymous, else use the centralized banking system.

One problem with my proposed solution is the fungibility of taint. I had not read the linked thread prior to writing the above, thus didn't realize the gravity of the numerous mentions of "taint" in the OP.

I suppose there are rare cases where you want to give your identity to someone trusted but not the identity of the merchant to your bank. But that hardly seems like a compelling use case to justify such convoluted systems as proposed for CoinJoin.

Another problem with my proposed solution is although it does protect our privacy, but it doesn't protect our anonymity in an important use case, which I had mentioned as quoted above. Note some prior discussion that privacy and anonymity are related but not the same. The case is we want to be anonymous to the banks, i.e. we don't want all our payment history to be known to anyone (perhaps for legal, criminal, and free speech liability reasons), yet we have no choice but to reveal our identity to the merchant in order to use the service. An example is participating in a videochat forum (without a physical disguise) on some topic which is considered amoral, illegal, or threatening in some jurisdictions but not in others. For example paid sex videochat is illegal in some countries but not in others, but I am sure there are many other legitimate examples which are less offensive to readers here.

Without coin laundries, the only way to solve the above is to rely on the merchant to keep your public key secret. The merchant could even set up a server which receives the payment proof via BitMessage (and returns an access code which can be used on the merchant's website), so that the public key storage server's location can't be known by anyone other than the merchant. However the problem is that relying on the merchant is inherently insecure.

Also even if the payer doesn't care about his anonymity and privacy, the merchant might, so taint issue is also to a lesser degree about knowing who to pressure to reveal information about the merchant, i.e. the merchant might protect the identity of his customers well but the customers might not automatically protect their own identities well.

I am now looking at adam3us (Adam Back)'s ring signature suggestion. What are the tradeoffs of a ring signature approach?

I will re-read this thread and the other one to see if I find the answer. If there is anything to add to what has been already written in the two threads, please do. Especially to make the discussion more readily comprehensible for someone who is mathematical but not well studied in cryptography terminology ("oracles", etc.).

[Mike Hearn]

A couple minutes ago Phantomcircuit directed me to this writeup, which I'd not see before.

That's unfortunate - I pointed this out in my reply to your first post up thread:

https://bitcointalk.org/index.php?topic=279249.msg2985704#msg2985704

The advanced crypto part isn't necessarily that advanced and doesn't require ZK proof systems. Such protocols were already designed:

http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/

It just requires secure multi-party sorts, which is a more well studied subset of general MPC.

Perhaps I should have put the last part of my post first.

[AnonyMint]

Don't you need tor or something to prevent everyone from learning everyone's IP?

Any transaction privacy system that hopes to hide user's addresses should start with some kind of anonymity network. This is no different. Fortunately networks like Tor, I2P, Bitmessage, and Freenet all already exist and could all be used for this. (Freenet would result in rather slow transactions, however)

As far as I know, Tor and I2P are low-latency mix-nets. Only a HIGH-latency (with random delays and orderings of relay) mix-net is robust against timing traffic analysis. I2P mentions possible high-latency support coming in version 3, but is that realistically coming very soon?

So really they don't necessarily insure anonymity against a formidable adversary such as intelligence agencies.

Also Tor limits hops to 3, and the security of mix-nets is related to the probability that at least one hop isn't compromised. Also all peers don't relay in Tor, thus Tor's servers are subsidized and some think they are already a tool of the intelligence agencies. Good performance, low-latency anonymity apparently isn't economic.

I have not studied BitMessage and Freenet. Do they offer the complete solution?

Is BitMessage using onion or garlic routing along with high-latency relaying?