Bitcoin is often promoted as a tool for privacy but the only privacy that exists in Bitcoin comes from pseudonymous addresses which are fragile and easily compromised through reuse, "taint" analysis, tracking payments, IP address monitoring nodes, web-spidering, and many other mechanisms. Once broken this privacy is difficult and sometimes costly to recover.

Traditional banking provides a fair amount of privacy by default. Your inlaws don't see that you're buying birth control that deprives them of grand children, your employer doesn't learn about the non-profits you support with money from your paycheck, and thieves don't see your latest purchases or how wealthy you are to help them target and scam you. Poor privacy in Bitcoin can be a major practical disadvantage for both individuals and businesses.

Even when a user ends address reuse by switching to BIP 32 address chains (http://bitcoinism.blogspot.com/2013/07/reclaiming-financial-privacy-with-hd.html), they still have privacy loss from their old coins and the joining of past payments when they make larger transactions.

Privacy errors can also create externalized costs: You might have good practices but when you trade with people who don't (say ones using "green addresses") you and everyone you trade with loses some privacy. A loss of privacy also presents a grave systemic risk for Bitcoin: If degraded privacy allows people to assemble centralized lists of good and bad coins you may find Bitcoin's fungibility destroyed when your honestly accepted coin is later not honored by others, and its decentralization along with it when people feel forced to enforce popular blacklists on their own coin.

As I write this people with unknown motivations are raining down tiny little payments on old addresses, presumably in an effort to get wallets to consume them and create evidence of common address ownership.

I think this must be improved, urgently.

This message describes a transaction style Bitcoin users can use to dramatically improve their privacy which I've been calling CoinJoin. It involves no changes to the Bitcoin protocol and has already seen some very limited use spanning back a couple of years now but it seems to not be widely understood.

I first publicly described this transaction style in a whimsically-named thread— "I taint rich! (https://bitcointalk.org/index.php?topic=139581.0)"— where I focused on a specific side effect of these transactions, with an expectation that people would see the rest of the implications on their own.

Explicit beats implicit, and even people who understand the idea have had some questions which could use answering. Thus this post.

A Bitcoin transaction consumes one or more inputs and creates one or more outputs with specified values.

Each input is an output from a past transaction. For each input there is a distinct signature (scriptsig) which is created in accordance with the rules specified in the past-output that it is consuming (scriptpubkey).

The Bitcoin system is charged with making sure the signatures are correct, that the inputs exist and are spendable, and that the sum of the output values is less than or equal to the sum of the input values (any excess becomes fees paid to miners for including the transaction).

It is normal for a transaction to spend many inputs in order to get enough value to pay its intended payment, often also creating an additional 'change' output to receive the unspent (and non-fee) excess.

There is no requirement that the scriptpubkeys of the inputs used be the same; i.e., no requirement that they be payments to the same address. And, in fact, when Bitcoin is correctly used with one address per payment, none of them will be the same.

When considering the history of Bitcoin ownership one could look at transactions which spend from multiple distinct scriptpubkeys as co-joining their ownership and make an assumption: How else could the transaction spend from multiple addresses unless a common party controlled those addresses?

In the illustration 'transaction 2' spends coins which were assigned to 1A1 and 1C3. So 1A1 and 1C3 are necessarily the same party?

This assumption is incorrect. Usage in a single transaction does not prove common control (though it's currently pretty suggestive), and this is what makes CoinJoin possible:

The signatures, one per input, inside a transaction are completely independent of each other. This means that it's possible for Bitcoin users to agree on a set of inputs to spend, and a set of outputs to pay to, and then to individually and separately sign a transaction and later merge their signatures. The transaction is not valid and won't be accepted by the network until all signatures are provided, and no one will sign a transaction which is not to their liking.

To use this to increase privacy, the N users would agree on a uniform output size and provide inputs amounting to at least that size. The transaction would have N outputs of that size and potentially N more change outputs if some of the users provided input in excess of the target. All would sign the transaction, and then the transaction could be transmitted. No risk of theft at any point.

In the illustration 'transaction 2' has inputs from 1A1 and 1C3. Say we beliece 1A1 is an address used for Alice and 1C3 is an address used for Charlie. Which of Alice and Charlie owns which of the 1D and 1E outputs?

The idea can also be used more casually. When you want to make a payment, find someone else who also wants to make a payment and make a joint payment together. Doing so doesn't increase privacy much, but it actually makes your transaction smaller and thus easier on the network (and lower in fees); the extra privacy is a perk.

Such a transaction is externally indistinguishable from a transaction created through conventional use. Because of this, if these transactions become widespread they improve the privacy even of people who do not use them, because no longer will input co-joining be strong evidence of common control.

There are many variations of this idea possible, and all can coexist because the idea requires no changes to the Bitcoin system. Let a thousand flowers bloom: we can have diversity in ways of accomplishing this and learn the best.

FAQ:

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)

However, gumming up "taint analysis" and reducing transaction sizes doesn't even require that the users be private from each other. So even without things like tor this would be no worse than regular transactions.

Don't the users learn which inputs match up to which outputs?

In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their input and output information to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.

More complicated implementations are possible where even the server doesn't learn the mapping.

E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.

Similar things can be accomplished with various zero-knowledge proof systems.

Does the totally private version need to have a server at all? What if it gets shut down?

No. The same privacy can be achieved in a decentralized manner where all users act as blind-signing servers. This ends up needing n^2 signatures, and distributed systems are generally a lot harder to create. I don't know if there is, or ever would be, a reason to bother with a fully distributed version with full privacy, but it's certainly possible.

What about DOS attacks? Can't someone refuse to sign even if the transaction is valid?

Yes, this can be DOS attacked in two different ways: someone can refuse to sign a valid joint transaction, or someone can spend their input out from under the joint transaction before it completes.

However, if all the signatures don't come in within some time limit, or a conflicting transaction is created, you can simply leave the bad parties and try again. With an automated process any retries would be invisible to the user. So the only real risk is a persistent DOS attacker.

In the non-decentralized (or decentralized but non-private to participants) case, gaining some immunity to DOS attackers is easy: if someone fails to sign for an input, you blacklist that input from further rounds. They are then naturally rate-limited by their ability to create more confirmed Bitcoin transactions.

Gaining DOS immunity in a decentralized system is considerably harder, because it's hard to tell which user actually broke the rules. One solution is to have users perform their activity under a zero-knowledge proof system, so you could be confident which user is the cheater and then agree to ignore them.

In all cases you could supplement anti-DOS mechanisms with proof of work, a fidelity bond, or other scarce resource usage. But I suspect that it's better to adapt to actual attacks as they arise, as we don't have to commit to a single security mechanism in advance and for all users. I also believe that bad input exclusion provides enough protection to get started.

Isn't the anonymity set size limited by how many parties you can get in a single transaction?

Not quite. The anonymity set size of a single transaction is limited by the number of parties in it, obviously. And transaction size limits as well as failure (retry) risk mean that really huge joint transactions would not be wise. But because these transactions are cheap, there is no limit to the number of transactions you can cascade.

In particular, if you have can build transactions with m participants per transaction you can create a sequence of m*3 transactions which form a three-stage switching network (http://en.wikipedia.org/wiki/Clos_network) that permits any of m^2 final outputs to have come from any of m^2 original inputs (e.g. using three stages of 32 transactions with 32 inputs each 1024 users can be joined with a total of 96 transactions). This allows the anonymity set to be any size, limited only by participation.

In practice I expect most users only want to prevent nosy friends (and thieves) from prying into their financial lives, and to recover some of the privacy they lost due to bad practices like address reuse. These users will likely be happy with only a single pass; other people will just operate opportunistically, while others may work to achieve many passes and big anonymity sets. All can coexist.

How does this compare to zerocoin (http://zerocoin.org/)?

As a crypto and computer science geek I'm super excited by Zerocoin: the technology behind it is fascinating and important. But as a Bitcoin user and developer the promotion of it as the solution to improved privacy disappoints me.

Zerocoin has a number of serious limitations:

It uses cutting-edge cryptography which may turn out to be insecure, and which is understood by relatively few people (compared to ECDSA, for example).

It produces large (20kbyte) signatures that would bloat the blockchain (or create risk if stuffed in external storage).

It requires a trusted party to initiate its accumulator. If that party cheats, they can steal coin. (Perhaps fixable with more cutting-edge crypto.)

Validation is very slow (can process about 2tx per second on a fast CPU), which is a major barrier to deployment in Bitcoin as each full node must validate every transaction.

The large transactions and slow validation also means costly transactions, which will reduce the anonymity set size and potentially make ZC usage unavailable to random members of the public who are merely casually concerned about their privacy.

Uses an accumulator which grows forever and has no pruning. In practice this means we'd need to switch accumulators periodically to reduce the working set size, reducing the anonymity set size. And potentially creating big UTXO bloat problems if the horizon on an accumulator isn't set in advance.

Some of these things may improve significantly with better math and software engineering over time.

But above all: Zerocoin requires a soft-forking change to the Bitcoin protocol, which all full nodes must adopt, which would commit Bitcoin to a particular version of the Zerocoin protocol. This cannot happen fast—probably not within years, especially considering that there is so much potential for further refinement to the algorithm to lower costs. It would be politically contentious, as some developers and Bitcoin businesses are very concerned about being overly associated with "anonymity". Network-wide rule changes are something of a suicide pact: we shouldn't, and don't, take them lightly.

CoinJoin transactions work today, and they've worked since the first day of Bitcoin. They are indistinguishable from normal transactions and thus cannot be blocked or inhibited except to the extent that any other Bitcoin transaction could be blocked.

(As an aside: ZC could potentially be used externally to Bitcoin in a decentralized CoinJoin as a method of mutually blinding the users in a DOS attack resistant way. This would allow ZC to mature under live fire without taking its costs or committing to a specific protocol network-wide.)

The primary argument I can make for ZC over CoinJoin, beyond it stoking my crypto-geek desires, is that it may potentially offer a larger anonymity set. But with the performance and scaling limits of ZC, and the possibility to construct sorting network transactions with CJ, or just the ability to use hundreds of CJ transactions with the storage and processing required for one ZC transactions, I don't know which would actually produce bigger anonymity sets in practice. E.g. To join 1024 users, just the ZC redemptions would involve 20k * 1024 bytes of data compared to less than 3% of that for a complete three-stage cascade of 32 32-way joint transactions. Though the ZC anonymity set could more easily cross larger spans of time.

The anonymity sets of CoinJoin transactions could easily be big enough for common users to regain some of their casual privacy and that's what I think is most interesting.

How does this compare to CoinWitness (https://bitcointalk.org/index.php?topic=277389.0)?

CoinWitness is even rocket-sciency than Zerocoin, it also shares many of the weaknesses as a privacy-improver: Novel crypto, computational cost, and the huge point of requiring a soft fork and not being available today. It may have some scaling advantages if it is used as more than just a privacy tool. But it really is overkill for this problem, and won't be available anytime real soon.

Sounds great! Where is it?

Theres the rub: There exist no ready made, easy-to-use software for doing this. You can make the transactions by hand using bitcoin-qt and the raw transactions API, as we did in that "taint rich" thread, but to make this into a practical reality we need easy-to-use automated tools.

Luke has written up some sketches a protocol (https://gist.github.com/luke-jr/5409899) which would enable establishing joint transactions over the regular Bitcoin network.

The Bitcoin-qt RPC system provides everything someone needs to write a side-car applet (including the ability to lock txouts to prevent them from being spent out from from under it) that participants in such a system. But the fact that so many users use centralized webwallets today which can spy on them will ultimately limit the userbase for these tools.

Personally, most of my coding brain capacity is spent on other things which are even more important to me. And what I could spare on Bitcoin is spent on more core and security things— if I work on anything wallet related anytime soon it will likely be improving the privacy behavior of coin selection... But moreover:

Anyone who builds this is going to be accused of enabling criminal activity, it doesn't matter if any actual criminals use this or not: Criminal activity sells headlines. Being a Bitcoin core developer already fills my quota for accusations of this kind, especially my quota for risk that I'm not even paid for. :)

In reality, real criminals don't need CoinJoin if they have even the slightest clue: They can afford to buy privacy in a way that regular users cannot, it's just a cost of their (often lucrative) business.

Joe-criminal can go out and buy 120% PPS mining to get brand new coins, or run his money through a series of semi-sham high cashflow gambling businesses for a 50% cut, they can afford the cost of seeking out and interfacing with these seedy services... Joe and Jane doe? Their names are up in neon on blockchain.info. It might not seem great to them, but if there a high cost of fixing it they simply won't, because the cost of fixing it is very concrete and the cost or privacy loss is speculative and distant. They might just need to give up bitcoin and switch to something almost totally private: cash... Regular users need efficient and inexpensive privacy if it is to help them at all.

I know that making such a tool doesn't fit into the get-rich-quick mold of many Bitcoin businesses, but the importance is self-apparent and the simplest versions of this don't require very deep technical wizardry. I think the "political" risk of improving people's privacy is a real one that you should carefully consider, but around these parts I see people sticking their names on some rather outrageously risky stuff. I'd hoped the "taint rich" thread would be enough to inspire some community action, but perhaps this will be.

In order to further incentivize work in this space there is now a multisignature escrow bounty fund:

3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk (bitcoin:3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk) (yes, Bitcoin addresses can also start with a 3)

This is a two-of-three multisignature escrow with myself, Theymos, and Pieter Wuille as signers. To release any coin sent to this address at least two of these people must sign the transaction.

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.

Please feel free to contribute to the above address to support work on this infrastructure.

Multisig address construction details:

Code:

Key from Theymos:-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256

Here is a public key of mine, usable for the CoinJoin bounty fund:02d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b-----BEGIN PGP SIGNATURE-----

(As an aside: ZC could potentially be used externally to Bitcoin in a decentralized CoinJoin as a method of mutually blinding the users in a DOS attack resistant way. This would allow ZC to mature under live fire without taking its costs or committing to a specific protocol network-wide.)

This is an extremely interesting idea. Could you elaborate on how the Zerocoin transaction stages map to the stages of CoinJoin transaction creation?

This is an extremely interesting idea. Could you elaborate on how the Zerocoin transaction stages map to the stages of CoinJoin transaction creation?

For non-decenteralized coincoin, you simply pass around a transaction and sign it. It's a single sequence and an atomic transaction, you'd make two loops through the users, one to discover the inputs and outputs, and another to sign them. There really aren't stages to it.

Making a decenteralized CoinJoin secure, private, and resistant to DOS attack (people refusing to sign in order to make it fail) is trickier... for the privacy and dos attack resistance you can use ZC:

Presume the participants for a transaction are sharing some multicast medium and can all communicate. They need to accomplish the task of offering up inputs (txid:vout) for inclusion in the transaction and then, in an unlinkable way, providing outputs to receive their coins.

Each participant connects and names bitcoin input(s), an address for change (if needed), and the result of performing a ZC mint transaction to add to the ZC accumulator. They sign all this with the keys for the corresponding inputs proving its theirs to spend.

Then all the parties connect again anonymously and provide ZC redeem transactions which specify where the resulting bitcoins should go.

On their original connections all parties can now see the redeem transactions and are convinced that they were provided by the correct parties, and that they themselves will be paid. So they all sign the transaction.

If a party fails to sign, everyone else is convinced that its because they are jamming the process (intentionally or maliciously) and then can all ban (ignore in the future) whatever costly identity they used to enter the mix, or — if there is no other mechanism— that particular txin which they used.

This isn't the only way to do this in a decentralized manner, the way to do it with blind signatures is fairly similar:

Each participant connects, names Bitcoin input(s), an address for change (if needed), a key for blind signing, and a blinded hash of the address they want paid. They sign all this with the keys for the corresponding inputs proving its theirs to spend.

Each participant then blind signs the blinded hashes of all participants (including themselves).

Each participant then reconnects anonymously and discloses their unblinded values and all the signatures. Because all the participants can see all the signatures, they know all are authentic. They sign, and if they refuse to sign everyone is convinced that the refusing signer is attempting to jam and bans them.

The most obvious difference between the two techniques is that the blind signing requires N^2 signatures, and potentially three communication phases (submit, blindsign, redeem) instead of two (mint, redeem) if you wanted this process to span more than a single event.

As I said above, I generally think the non-decenteralized versions of these transactions will be implemented and commonly used first, simply because they're so much less work to do.

In order to further incentivize work in this space I'd like to create a multisignature escrow bounty fund.

Theymos has agreed to be a cosigner with me and I'm currently looking for a third party. (Unfortunately, many of the people I'd normally ask would like to be potential bounty recipients, and I'd rather reduce the possible conflict of interest)

The bounty fund would pay out of this fund 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.

I'll update this post when I have it ready.

I'd like to help out with this if possible. I have little BTC to put into such a bounty fund, nor am I a programmer. Let me know what I can do to help.

Take a look also here: https://bitcointalk.org/index.php?topic=200952.0 I think this is a similar concept, which is currently being worked on already (and I think even a test-net some-what-working version already exists).

This is a really nice writeup, thanks Gregory. Such ideas have been kicked around informally for a while:

https://bitcointalk.org/index.php?topic=175156.msg1829259#msg1829259

see the part about p2p mixing protocols ... but it's good to have a name and a formal writeup.

The examples of how ordinary, everyday privacy leaks can cause people problems are great. I think I've named the "people learning each others salaries" one before, but birth control is an interesting one.

I think adding a rendezvous mechanism to the P2P network makes sense. It's already a broadcast network after all. So perhaps the right design is not to try and do absolutely everything over the existing P2P network but rather allow people to announce rendezvous points (Tor hidden services?) over the broadcast channel and then allow nodes to set announcement filters like they set Bloom filters today. If you are an SPV/leaf node on the network you wouldn't hear announcements until you request them. Other nodes would relay them all.

The difficult part is that you need a lot of traffic to make this work. Current tx volumes don't even reach one per second. So to accumulate enough users for a mix, you'd need to wait a while. It's fine for some kinds of payments that aren't time sensitive, but it's not going to work today for restaurant bills.

If I were doing it, I'd want to do the bulk of the implementation in bitcoinj of course, just because that's what most users are going to end up using (given current trajectories). It also has the advantage that using a managed language like Java eliminates entire classes of security holes, always a concern when writing financial software.

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

FWIW I'll try implementing a "coin dust" collector this weekend that just does makes SIGHASH_NONE|ANYONECANPAY signatures for the dust in your wallet and sends them to a central collection point.

Regarding mixing in general if you can split up the mix protocol into separate stages of "I want these txouts", "I'll sign for those txouts", make broadcasting those requests use up a limited resource, and finally have a P2P flood fill network where finding the originator of a message is hard you can easily make a system that is both anonymous and DoS resistant. If we add a messaging layer to Bitcoin where messages are paid for somehow, perhaps by fees paid, this can be easily developed into a automatic 'coinjoin' system for every transaction made. In addition if you can add expiry times to 'txout requests' when peers connect you can give them the outstanding requests, which means allows nodes that just connected to their peers to quickly make a transaction even if they weren't online while the request was made.

What's really nice about this implementation is that while on the one hand it's a mixer, on the other hand it's also just a DoS-resistant way of making transactions smaller by getting multiple parties together to make them. It doesn't require any dedicated "rendezvous" points that may find their actions legally frowned upon, nor does it require a separate system (like Tor) be installed to talk to those points. The general purpose messaging layer could be useful for other things too - it'd be easy to use it for alerts for instance.

Rough technical sketch:

1) Create the messaging layer

1.1) Define NODE_MSG to signal that a node will relay messages. Define "message" inventory type and add to ppszTypeName. Optional: define "realms" of messages split up by a UUID or something.

1.2) Write code to maintain an inventory of such messages. Basically this will look kinda like the mempool, and there will be some time period for which old messages are expired, as well as a limit on total messages stored.

1.3) Relay those messages to peers/respond to getdata requests. If "realms" are supported, a bloom filter to select which realms a peer is interested in is useful.

2) Make DoS-attacks expensive

2.1) For every mempool tx, record the scriptPubKeys spent, and take the fees of the tx and proportion them to those scriptPubKeys.

2.2) Add a way to for messages to be signed by scriptPubKeys, and reduce the "balance" of fees recorded for each message. (amount sacrificed per msg should be configurable) Note that it may be necessary to only allow for fees to be used from transactions that have been actually mined - not sure how much that opens up attacks.

2.3) Other methods, PoW, fidelity bonds etc. possible too.

3) Add mix protocol

2.1) Define "I want these txouts" and "I'll sign for these txouts" messages.

2.2) Add logic for the announce/sign sequence, along with options for the user to decide how fast they want the tx to be generated. Typically after a few seconds I'd expect the program to give up and just sign the txouts it already has, thus creating a non-mixed tx. Note how if you need more than one txout in a given transaction this can still be a privacy improvement, because you can arrange so that the txin/txout set is still indistinguishable from a two-party tx.

2.3) Add better logic to make sure the fee-paying tx's used don't break anonymity - you wouldn't want to use the same scriptPubKey for txout announce and signature announce. Also clever crypto can help here too - but that can be added later. Remember that timing is a potential anonymity breaker too, so randomize it, and also randomly sometimes wait for the other party to broadcast signatures, or sometimes broadcast signatures yourself.

2.4) Long-term: add more SIGHASH options to make it easier to specify what txin's and txouts a signature applies too on a set basis, rather than the current inflexible options available.

4) Add prioritization so that blocks always get priority over message data and are transferred around the network fastest. Note how having non-blockchain data actually helps the overall resistance to traffic analysis for the whole system by providing a constant stream of data for which latency is less important to hide the data for which latency is more important.

Another fun one: with realms you can port completely different applications, like IRC chat, to run over this basis concept. Only nodes that are interested in a particular application, or are willing to lend bandwidth to allow users of that application more anonymity, need to relay messages for a given realm, which keeps the whole system scalable. Needs some work to actually find peers for a given realm, but that's just a matter of extending the address gossip functionality.

FWIW I'll try implementing a "coin dust" collector this weekend that just does makes SIGHASH_NONE|ANYONECANPAY signatures for the dust in your wallet and sends them to a central collection point.

That basically sends the dust to anyone who wants it? How does that help?

People appear to have been sending very large numbers of addresses dust as a way to break anonymity. Granted, they also may have been doing it as a way to get signatures from scriptPubKeys due to the 'R' re-use issue, but the script would use bitcoind to spend the dust which is known to not be vulnerable.

Also there's lots of pretty much unspendable dust out there from Satoshidice and others, and again such a script can help.

2.1) Define "I want these txouts" and "I'll sign for these txouts" messages.

Since everyone has to pay for the service, if it fails, everyone loses. However, the DOS attacker loses faster?

The "currency" for paying for message relay is effectively coin-age?

No, it's fees paid by previous transactions.

Now that does raise the question of where do those fees come from if you haven't made a transaction in awhile? One decent option is in fact to spend coin-age by signing to a txout that you don't actually intend to spend, however that's open to DoS attack by entities that simply have a lot of Bitcoins. Fidelity bonds are another option.

As an aside, the actual process of spending credit should include a field for the current balance of credit prior to that spend, and the hash of the previous time this credit was used to make double-spending credit not possible. This is particularly important with the coin-age or fidelity bond version, because there it's quite possible for nodes to securely give their peers the current status of the credit balance based on smallest balance left.

The transaction would be flooded in stages, everyone gets version 1 then version 2 then version 3 and so on.

Eventually someone signs and that ends the mixing.

Signing the transaction early also acts as a DOS attack.

I'm actually thinking that mixes should have a small number of participants, usually two or three. Remember that we want the process of creating a tx to be as fast as possible, and multiple rounds of mixes wind up with just as much anonymity as fewer rounds with more participants in each round.

The economics of the DoS attack are such that the attacker wastes only a small integer multiple less fees than the target(s), and the targets are already spending the fees anyway. IE the defenders already have the resource, fee paying transactions, that the attacker has to buy specifically to launch the attack.

There would also be a requirement that "cleaned" coins have standard sizes. You pay for something and you get 2 change payments, a cleaned standard value coin and the remainder.

Standard sizes do not have to be a requirement actually. Suppose Alice has 2BTC and wants to send 1.5BTC to Bob: she can announce that she wants a 1.5BTC txout with Bob's scriptPubKey, and a 0.5BTC txout to a change address and broadcast that. Now suppose Charlie has 0.75BTC and simply wants to mix some of it, but doesn't really care how much. He can note that Alice has a 0.5BTC txout, and broadcast a request to make a transaction with her txouts, as well as a 0.5BTC txout to one of his addresses, and a 0.25BTC txout to a change address of his.

When the final transaction gets mined there are two 0.5BTC txouts - but who's are they?

Even in the general case where you have an Alice and a Bob who both want to send money it's often hard to figure out whose inputs and outputs are whose. Do the txouts belong to the same person, and they were just paying multiple people? Which of the multiple txins was actually owned by who?

It's easy to make the task of following the transaction graph very difficult without trying provided a lot of people are combining their transactions.

Also there's lots of pretty much unspendable dust out there from Satoshidice and others, and again such a script can help.

True. People might be willing to throw it away.

Quote

I'm actually thinking that mixes should have a small number of participants, usually two or three. Remember that we want the process of creating a tx to be as fast as possible, and multiple rounds of mixes wind up with just as much anonymity as fewer rounds with more participants in each round.

True, and as you say, it isn't about perfection, it just increases the effort.

If the goal is a simple way to regain anonymity, why are there counter-proposals to make regaining it more complex? Just curious.

I'm not sure what you're referring to, but in general I think a lot of people have not thought the fungibility implications through, and are also confusing privacy and anonymity because they are intimately related, especially where pseudoynmity is used to achieve privacy. Anonymity is fundamentally hard, and consider anonymity improvements a side effect of good privacy. If you want to go around telling someone which transactions are yours, you still can. And, an interesting point of that is that it's not at all incompatible with what is proposed here. Even if you're happy telling a particular set of people all about your transactions, that doesn't imply you also want the whole world to know.

If the goal is a simple way to regain anonymity, why are there counter-proposals to make regaining it more complex? Just curious.

I'm not sure what you're referring to, but in general I think a lot of people have not thought the fungibility implications through, and are also confusing privacy and anonymity because they are intimately related, especially where pseudoynmity is used to achieve privacy. Anonymity is fundamentally hard, and consider anonymity improvements a side effect of good privacy. If you want to go around telling someone which transactions are yours, you still can. And, an interesting point of that is that it's not at all incompatible with what is proposed here. Even if you're happy telling a particular set of people all about your transactions, that doesn't imply you also want the whole world to know.

I'll accept that, but the counter-proposals/additions to your initial proposal do nothing to keep the complexity for the user down. As an end user who is looking for ease of use and decent privacy, some of the other schemes here, unless done transparently, are just too much to keep up with.

I'll accept that, but the counter-proposals/additions to your initial proposal do nothing to keep the complexity for the user down. As an end user who is looking for ease of use and decent privacy, some of the other schemes here, unless done transparently, are just too much to keep up with.

My proposal can be 100% automated - the user doesn't even need to know it's happening behind the scenes.

It's also not really any different in spirit from what gmaxwell suggested in the first place - I've only fleshed out details with a particular way to do it.

This seems overly complicated. Is there any reason why Bitcoin isn't private enough as it is?You presented a hypothetical situation which has not occurred yet. It's not perfectly private but compared to credit cards and banks its very private. It's almost as private as cash.

I edited that post down from a longer (4000 word?) version which included some specific examples that I had some personal involvement in: The (third?) ozcoin thief, who was identified by sending funds to a wallet service that reused addresses (and ultimately had those funds clawed back), and a person who had an insecure brain wallet found by a whitehat, ultimately tracked down and contacted due to a mining pool which reused addresses.

There are many other examples of privacy in Bitcoin being weak— one only needs to spend a few minutes browsing through bc.i's public block explorer interface (http://blockchain.info/) to see real names attached to transactions (found by spidering webforums) and frequently accurate IP addresses (associated by connecting to many nodes), and from there you can find additional related addresses with the taint analysis button. Or look at the academic research (http://arxiv.org/abs/1107.4524) "Bitcoin is not inherently anonymous. It may be possible to conduct transactions is such a way so as to obscure your identity, but, in many cases, users and their transactions can be identified." (papers on Bitcoin are of, ahem, highly variable quality— but the point remains, Bitcoin's privacy as it is today is not very good).

The privacy gap between Bitcoin and cash for most users is enormous, enough so that we have an explicit warning on Bitcoin.org (http://bitcoin.org/en/you-need-to-know):

Quote from: bitcoin.org

"Some effort is required in order to protect your privacy with Bitcoin. All Bitcoin transactions are stored publicly and permanently on the network, which means anyone can see the balance and transactions of any Bitcoin address. However, the identity of the owner cannot be associated with their Bitcoin address until personal information is revealed by the owner during an exchange. This is why it is recommended for Bitcoin owners to use many different Bitcoin addresses; in fact, you should create a new one each time you receive money. This is especially important for public uses such as websites. You might also want to consider hiding your computer's IP address with a tool like Tor so that it cannot be logged."

Ignorance of these limitations makes the situation worse because without being acutely aware of the risk you will transact in ways that leaks more information about you and the parties you trade with.

I'm actually thinking that mixes should have a small number of participants, usually two or three. Remember that we want the process of creating a tx to be as fast as possible, and multiple rounds of mixes wind up with just as much anonymity as fewer rounds with more participants in each round.

If it was locked to 2 participants, then you could use something like

flip a coin

If heads, send a broadcast with "I'll pay for <my outputs>".If tails, wait for a broadcast and then broadcast to 50% of peers "I'll pay into mix(<other's outputs> <my outputs>)"

(Tails needs a timeout)

wait until you receive tx with all outputs broadcast from 1/3 of peers [ * ]

Wait 5 to 15 seconds at random from that point to broadcast tx with signed inputs that pay to the full set of outputs [ ** ]

One or other of the 2 participants can broadcast the full transaction to the network.

The fee would have to be agreed in advance. Each participant would pay half the fee.

I still think standard coin sizes would help with the mixing. However, the trick where you create a coin to mix with a person's change address is a good idea.

You could actually mix with both pieces.

I send 0.1BTC and 0.01BTC change. The other person might buy something for 0.9 BTC with change of 0.1, 0.01 and <remainder>. They get their change mostly mixed and would still be paying a tx fee.

[ * ] If you send the broadcast, then this is 1/3 of the nodes you didn't send it to. This could be restricted to outbound nodes.This syncs both participants to have the same start time.

As I understand the problem-to-solve is that if someone reveals your identity for any transaction then any other spends from the same public key are associated with your identity and any spends (inputs) from other public keys to the same transactions as the identified public key are with high-likelihood associated with your identity.

The CoinJoin solution is dual pronged in that if a greater percentage of blockchain transactions are inputs from multiple parties, then the high-likelihood case is reduced in likelihood for all users of the blockchain that don't use CoinJoin. The second prong is the mixing of parties for a transaction using CoinJoin protects the identity of the public keys for the parties spending using CoinJoin.

Note the first prong is an improvement even when someone reveals your identity for all the input public keys of a transaction, because you may use one of those public keys later with other uncompromised public keys in other transactions that were not revealed.

However, CoinJoin is unnecessary if no one ever knows your identity.

If you must provide your identity, then why are you using Bitcoin and not your credit card, cash, money order, paypal, etc?

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. Credit card numbers can be stolen but in the relatively rare event, most of the time your issuer will remove any unauthorized charges. If identity theft is your concern, then again why are you providing your identity.

And against the NSA and the government, plausible deniability is not a defense (http://blog.jim.com/economics/bitcoin-as-a-speculative-bet.html/comment-page-1#comment-342152) (btw jim is James A Donald, first person ever publicly recorded as interacting with Satoshi). So if they know your IP then they can compel you to unmix all the mixing stages.

Thus, I view zerocoin and CoinJoin as a lower priority than a high-latency Chaum mix-net (or dc-net), which we don't have available today (https://bitcointalk.org/index.php?topic=227287.msg2958176#msg2958176).

If you are littering your identity all over the web, then nothing is going to help you.

What I most like about this concept is its simple engineering pragmatism. You know, ZeroCoin solves exactly one problem really well, but it solves it so well because they pushed the envelope so far in one particular direction. From an academic point of view it makes for great papers and clever theory, but the history of cryptography is littered with empty and disused ivory towers, and in any case often those towers lack railings.

I have to wonder how many of the people pushing ZeroCoin so hard even recognize that it needs a mix net or a standard way of getting your transactions to those you are paying to be useful?

AnonyMint: You come so close to being pragmatic in how you recognize the need for mixers for communication. But then you miss so badly, like it or not, normal users will make mistakes that reveal their identity, and CoinJoin can help make those mistakes less devastating. In any case it is usually not the boogeyman of three-letter-agencies who the users of CoinJoin would be trying to protect themselves from, but individuals and businesses who simply want to use Bitcoin with the same level of financial privacy they enjoy in with the convention banking system.

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.

AnonyMint: You come so close to being pragmatic in how you recognize the need for mixers for communication. But then you miss so badly, like it or not, normal users will make mistakes that reveal their identity, and CoinJoin can help make those mistakes less devastating. In any case it is usually not the boogeyman of three-letter-agencies who the users of CoinJoin would be trying to protect themselves from, but individuals and businesses who simply want to use Bitcoin with the same level of financial privacy they enjoy in with the convention banking system.

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.

If we aren't concerned about the bogeyman who can see everyone's IP address or deposit viruses on our machine, then employing a high-latency Chaum mix-net with a standalone machine (e.g. Rasberry PI running L4 Linux) isn't that crucial. Then the only way users reveal their identity is by:

1. Explicitly giving it to the recipient.

2. Using the same browser for both entering their spending public key and browsing the internet, e.g. Google's cookies.

3. Use Windows 8

Did I miss any?

If we are concerned about more sophisticated harvesting of identity (which I am, because of Anonymity or Regulation (https://bitcointalk.org/index.php?topic=160612.msg2930989#msg2930989) and more), then with a high-latency Chaum mix-net built in for all incoming transactions, the above two pitfalls still apply.

And even with CoinJoin or Zerocoin, the above three pitfalls still apply.

I still don't see how CoinJoin or Zerocoin practically gain the naive user anything. Either the user stops giving up their identity by not doing the above three items, or they don't.

I understand the concept that IF users only give up their identity by mistake infrequently, thus delinking the block chain can in theory recover from such user error. However, I think users do what they do habitually.

P.S. CoinWitness is interesting because it can move the multiplexing of transactions off the blockchain, so then people employing decentralized mixing don't burden the block chain design. However, if a future design limits public keys, still need to support in the blockchain some way to retire and regenerate public keys for those coming out the other side of the offline mixer. (EDIT: note that last sentence might not be true, if the output can pay to existing key which is not yourself.)

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

You are conflating use cases of BTC, just because you want it to be more convenient in one way, yet you potentially make it less capable in another way (for someone who is considering any possible blockchain design for the future) by choosing that convenience over other considerations.

Another potentially useful idea I had in this space is CoinJoin software for doing matching charitable contributions.

E.g. you announce "I'll pay ~1 BTC to the EFF if 10 other people do too" and form a joint transaction with a single output. This may be fun, socially beneficial, and improve user privacy because even 1 TX output transactions couldn't be assumed to reveal common ownership of the input keys. Likewise, common donation outputs could be used to receive jagged change ediges in other kinds of join transactions which would otherwise be data revealing.

I have one suggestion that among others uses Secure Multiparty Computation (SMPC). https://en.wikipedia.org/wiki/Secure_multi-party_computation

Step one: Peer finding is done using a DHT network. This can be done inside I2P or Tor if you want to for increased anonymity. You might want to do reputation tracking where nodes uses public-key based pseudonyms (if you reuse a pseudonym, you must make sure to not spend inputs that can be tied to you personally more than just once (or rather not more often than the average, some identifiable inputs might by chance be involved with the same 3rd party multiple times) with that pseudonym since it otherwise can be directly correlated with your pseudonym).

To make verification of inputs simple and quick, each client keeps an updated Merkle tree hash of all currently valid spendable outputs in the blockchain (basically those that not have been spent yet) in this form: [Address]-[Transaction ID]-[Amount of BTC].

The SMPC uses cryptography to emulate a trusted 3rd party computer, running code all participants have agreed on. Unless a majority of the participants collude (Sybil attacks are a potential issue, be careful about who you run this with), no participant can get any other information out of it than they are *supposed* to get out of it.

Now, everybody puts in their transactions and their private keys for them. The SMPC checks if all participants really have the correct private keys for the (valid) previous outputs they claim as inputs through checking what addresses they correspond to, what transaction ID was claimed and how many bitcoins are claimed, and checks this data against the Merkle hash tree.

It then checks that the outputs aren't larger than the inputs. A transaction is then generated with all the user provided inputs and outputs, and signs it with all the private keys.

The signed transaction is given as an output to all the participants, and any one of them can publish it (or all of them at once).

Nobody can know which transactions came from whom, other than that they know their own. Out comes a signed Bitcoin transaction that includes them all in one. Either everything gets signed properly or it exits with an error. The protocol doesn't allow the generated transaction to be created in any other way than the correct way. All user specified outputs will be included, all user specified inputs will be included, no user can specify larger outputs than inputs (unless everybody agrees), etc...

The only major risk here is that of a Sybil attack (a large number of colluding nodes), and the major risk in here is private-key disclosure, the second is identifying which pseudonym spent what input. I hope that we can get around that somehow. One possible way is to not have the private keys provided to the SMPC, but to use simply prove you have the private key through signing a challenge of some sort, where the challenge can be a random number that is a checksum of all random numbers provided as inputs by the participants, so you only need one signature per participant. The SMPC would then only output an unsigned transaction, where all participants needs to sign it. The question then is how they all share their signatures with the other participants, ideally they should be able to hide that it came from them. Chaumian blinding could maybe be used in this step.

If you decide to not use blinding (to just pass on your signature), and not use any permanent pseudonym of any kind, then you'll have a risk of DoS attempts through both doublespend attempts (making the generated transaction invalid) and through canceled SMPC runs at the last step (thus wasting CPU power).

My intent is to make the system as automatable and fast as possible while maintaining full security.

I don't see any reason to hand your private key over to the SMPC, the point of this thread is that our transaction design is already such that users can separately sign a transaction. You could use SMPC to build the transaction to sign, and then everyone signs. This would be less brittle, e.g. sybils don't get your private key they can only jam the process or get a user unfairly banned. OH you say that at the end.

I don't follow why you think you need signature privacy at the end? You could use a homorphic mix, or just use SMPC to do the combine (e.g. two phases)... but the signatures only show ownership of an input, and the input side is normally not considered as private.

I'm not aware of any general production scale implementations of SMPC, it would be very exciting for a lot of things— are you aware of any system that could be realistically tasked with signing bitcoin transactions with commodity hardware separated by consumer internet connections?

I don't see any reason to hand your private key over to the SMPC, the point of this thread is that our transaction design is already such that users can separately sign a transaction. You could use SMPC to build the transaction to sign, and then everyone signs. This would be less brittle, e.g. sybils don't get your private key they can only jam the process or get a user unfairly banned. OH you say that at the end.

I don't follow why you think you need signature privacy at the end? You could use a homorphic mix, or just use SMPC to do the combine (e.g. two phases)... but the signatures only show ownership of an input, and the input side is normally not considered as private.

I'm not aware of any general production scale implementations of SMPC, it would be very exciting for a lot of things— are you aware of any system that could be realistically tasked with signing bitcoin transactions with commodity hardware separated by consumer internet connections?

gmaxwell: Yes, in the last part of that comment, that's what I suggested.

If a pseudonym is reused often, then correlation could be used to link all inputs with the pseudonym that provided them. This could the be further used to see if outputs from mixed transactions that the pseudonym in question has been part in often has some outputs in common, thus deanonymizing users who use this frequently for the same outputs (assuming the recipient has repeating or non-individual payment/donation addresses, which is common).

I've read that SMPC has been used IRL successfully for auctions for farms selling their goods. Can't remember the source. SMPC should be possible to run on most hardware. There's multiple implementations of it, some in Java and some in C.

How would a homomorphic mix work?

Two-round SMPC could certainly work, where the inputs simply are the individual signatures plus the previously unsigned transaction, creating a properly signed transaction.

If a pseudonym is reused often, then correlation could be used to link all inputs with the pseudonym that provided them. This could the be further used to see if outputs from mixed transactions that the pseudonym in question has been part in often has some outputs in common, thus deanonymizing users who use this frequently for the same outputs (assuming the recipient has repeating or non-individual payment/donation addresses, which is common).

Ah okay, yes the anti-dos pseudonym tracking is why I had suggested the method of using the input coin itself as the identity.

Quote

I've read that SMPC has been used IRL successfully for auctions for farms selling their goods. Can't remember the source. SMPC should be possible to run on most hardware. There's multiple implementations of it, some in Java and some in C.

A specialized for doing a meet in the middle auction (e.g. a few comparison operations and an arithmetic average) is a whole other of magnitude less complex than running a complete transaction processing program in it. Going and figuring out where the state of the art is in that space has been on my todo list.

Quote

How would a homomorphic mix work?

Every participants has a key for a homomorphic encryption scheme (which can be decrypted or encrypted in arbitrary order). Each party encrypts their signature with everyones key, the signatures are grouped up and passed around, with each peer permuting their order and applying a re-encryption operation. At the end they all decrypt in sequence and you get a mixed output. The downside is that people can silently jam the mix by replacing or corrupting data during reencryption. To prevent this you need to do cut and choose (e.g. mix 10000 times, commit to all of them, one gets picked as the real mix output and you reveal the rest) and that takes a lot of bandwidth.

As an aside— I hope the cryptowizardy for the decenteralized versions of this aren't scaring people off. Part of the merit of CoinJoin as an idea is that there are braindead simple ways of using these ideas that don't require cryptomagic and are only somewhat compromised compared to what you can do with maximal magic. I personally find the magic very exciting, but I find actual systems that people can use even _more_ exciting. I hope people will work at this space from both ends.

I don't see how that would help countering DoS, you won't likely be reusing inputs so there can't be reputation tracking.

Quote

A specialized for doing a meet in the middle auction (e.g. a few comparison operations and an arithmetic average) is a whole other of magnitude less complex than running a complete transaction processing program in it. Going and figuring out where the state of the art is in that space has been on my todo list.

It was a bit more than that IIRC. It was highest bid wins, with winner paying the price set by the second highest bid, and it was NOT just two or three participants, it was a LARGE auction. A very large amount of offered goods and bids.

Besides for risk of sybil+correlation attacks (which can be partially countered through reputation tracking), I like my SMPC scheme.

I don't see how that would help countering DoS, you won't likely be reusing inputs so there can't be reputation tracking.

You don't reuse your inputs if the transaction completes successfully. Basically having an available (potentially aged) input of sufficient size that has not been used to jam the mix is a scarce resource that would limit attackers. The network already rate-limits people's ability to create new outputs as part of its own dos protection. This isn't the greatest anti-DoS possible, though you could add PoW to it too if you wanted, but in the lightweight schemes the harm of jamming the mix is very low, so the protection doesn't have to be especially great.

Note that attackers don't actually have to spend that input if they disrupt the protocol. They can use the same one over and over, even many times simultaneously.

PoW could be an option where participants can set a minimum PoW accepted and a maximum PoW they're themselves willing to perform. So for example if 10 people all have 2^15 work within their range of acceptable PoW (one has 2^15 as their lowest, another as their highest, they'll all generate a common input for PoW and start working on it. Then they start this scheme with the SMPC. That would indeed make the attack costly for somebody trying to break the scheme for as many as possible (DoS) and would make Sybil very costly.

Note that attackers don't actually have to spend that input if they disrupt the protocol. They can use the same one over and over, even many times simultaneously.

You're missing my point. If you detect them disrupting the protocol the participants blacklist that input and never participate with it again (ideally the protocol would be such that they got proof of the disruption that they could show to others). But since success consumes the input you don't have a problem with long term identity linking. Yes, simultaneous is a possible but even in the worst case a given input could only be used to jam each group of users once. If recovering from a jamming is just a few packet round trip times and signature operations to redo the mix, this isn't so bad.

In any case, I've probably given you enough of my thoughts on this. Go out and code. Practice trumps theory. As I said in my initial post, I suspect that it might be better to just start out with very weak dos protection and then adapt to the actual threats rather than trying to predict all possible threats in advance. Unlike a global consensus system there is no great harm in evolving this technology.

It isn't certain that you'd be able to tell WHICH input that the attacker used, at least not with my scheme where you hide who's using what input. Revealing who's using what input might not be optimal if a user want to use inputs already tied to himself AND some inputs that aren't already, and doesn't want the unlinked ones to become linked to him.

Also, it's hard to convince other that the attacker maliciously broke the scheme where none of the participants has any long-term pseudonym, thus it's hard to blacklist that one input. Also, a single input can STILL be used many times simultaneously, even if not many times in a row.

I don't have enough experience with programming, and absolutely not of crypto implementations, to be able to make a proper proof-of-concept of this, sorry. I'm hoping that somebody else *who does* will find this interesting enough to implement.

So far I'm thinking that my two-round version SMPC scheme with initial PoW before starting SMPC would be pretty decent, where you'd remember which pseudonyms that mixing has worked with in the past. Participants that don't supply PoW is ignored, and to stop a sybil attack where many nodes don't do PoW to try to make you calculate PoW for nothing you'd connect to multiple dozens of random nodes at once.Edit: If the SMPC was given bad inputs, it would also reveal who it was that gave it the bad inputs (if it were to finish, but giving bad inputs + interupting the SMPC is just wasteful from an attacker's point of view).

And by the way, I'm one of those who wants the system to be as solid as possible in advance. Nobody deploys bad encryption algorithms and try to patch the algorithm as flaws is found. Not that I think that the other suggestions is bad, but I don't want people to get screwed over because somebody forgot to consider a simple attack that a little bit more analysis would have revealed and maybe shown how to stop.

And by the way, I'm one of those who wants the system to be as solid as possible in advance. Nobody deploys bad encryption algorithms and try to patch the algorithm as flaws is found. Not that I think that the other suggestions is bad, but I don't want people to get screwed over because somebody forgot to consider a simple attack that a little bit more analysis would have revealed and maybe shown how to stop.

Dos attacks on systems which don't require flag day updates are categorically different from cryptographic breaks. I fear the approach you are advocating would result in us getting nothing at all. (but, I certainly would welcome it if someone wanted to actually work on it!)

The risk of DoS in many of these cases could make the entire scheme unusable for as long as it's decentralized, as you can't really effectively ban the attacker. If the attacker can run 20x as many fake nodes as there are real nodes and abuse the scheme to only spend a trivial amount of computing power and bandwidth, while making the real users waste lots of it, then the system is trivially rendered unusable. Just throw a botnet at it and it's dead.

That's why I'm thinking hard on DoS prevention.

Edit: Also, regarding change addresses: You should split up your change in several parts. If everybody does that and thus generally also refers to multiple inputs for the transaction as a result, then correlation based on the BTC sums is much harder.

Edit: https://bitcointalk.org/index.php?topic=12751.msg315793#msg3157931 - So somebody else had the same basic idea over 2 years ago. Although my version (who originally was almost identical to his) now accounts for various types of possible attacks.

As far as I can tell, genjix's implementation is neither decentralized nor private, correct? The hard parts are still left to be done.

Also genjix should keep in mind this isn't a "one-time" bounty:

Quote

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.

A simple scheme to enhance privacy without modifying the protocol.I like it a lot.

By the way, there's a lot of confusion around zerocoin: http://themisescircle.org/blog/2013/08/22/the-problem-with-altcoins/Is it a bitcoin upgrade? I doubt the overhead deserves it.Is it a merged mined altchain with a coin fungible with btc? No way.Will it become an altcoin? Probably.Sorry, I don't want to move the thread to another direction, just wanted to note how less problematic this solution is.

Tor service. You can take down hidden services, but Silk Road and all the other services are still running around since 2+ years. Code is opensource so you can setup your own services. Users just paste the URL into the software. It's not really centralised. An analogy: BitcoinSpinner uses the BitcoinSpinner server, but in Electrum you choose your server and can setup your own.

Extensible. Adding the p2p mechanism for exchanging data can easily be done. Replace the ServerInterface class methods in client.py with your own: https://github.com/calafou/coinjoin/blob/master/client.py Then the URL in the software becomes a shared secret. We designed the software with this in mind.

More technical info: http://sx.dyne.org/anontx

We've delivered usable software, simple for grandma (money goes in, money goes out), requires no blockchain or bitcoind, easy to install and trustless. We followed gmaxwell's instructions as our guidepoint and went further. And we delivered the product fast.

In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their inputs and outputs to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.

note: Our implementation of the server is in stages and does not know the mapping so it's better even.

This is an extremely interesting idea. Could you elaborate on how the Zerocoin transaction stages map to the stages of CoinJoin transaction creation?

For non-decenteralized coincoin, you simply pass around a transaction and sign it. It's a single sequence and an atomic transaction, you'd make two loops through the users, one to discover the inputs and outputs, and another to sign them. There really aren't stages to it.

...

As I said above, I generally think the non-decenteralized versions of these transactions will be implemented and commonly used first, simply because they're so much less work to do.

note: we do a 4 step process where the outputs and inputs are loaded separately, so the server doesn't know the mapping between them

I think adding a rendezvous mechanism to the P2P network makes sense. It's already a broadcast network after all. So perhaps the right design is not to try and do absolutely everything over the existing P2P network but rather allow people to announce rendezvous points (Tor hidden services?) over the broadcast channel and then allow nodes to set announcement filters like they set Bloom filters today. If you are an SPV/leaf node on the network you wouldn't hear announcements until you request them. Other nodes would relay them all.

Why have servers at all? With I2P it would also be really easy to use DHT to set things up. Instead of a unique URL you could have a unique random string of any kind. Or even fully random peer selection.

Take a look also here: https://bitcointalk.org/index.php?topic=200952.0 I think this is a similar concept, which is currently being worked on already (and I think even a test-net some-what-working version already exists).

This seemingly got lost. Can anyone explain what the difference of the proposed scheme here is to what seems to be already implemented?

Uh. Does someone have a bug to report for a tool from this thread? (http://blockchain.info/tx/4ed20e0768124bc67dc684d57941be1482ccdaa45dadb64be12afba8c8554537) (If you want you can report to me in pgp email anonymously.)

Take a look also here: https://bitcointalk.org/index.php?topic=200952.0 I think this is a similar concept, which is currently being worked on already (and I think even a test-net some-what-working version already exists).

This seemingly got lost. Can anyone explain what the difference of the proposed scheme here is to what seems to be already implemented?

I spent a month working on a peer-to-peer Bitcoin privacy solution back in May, it's called BitPrivacy (https://bitcointalk.org/index.php?topic=200952.0).

It's aim is a fully decentralized solution providing strong privacy, and as such it is more ambitious and complicated than genjix's CoinJoin.

A decentralized solution spreads the legal risk over everyone running nodes - I'd rather be a developer of privacy software than someone running a privacy service. I spent a couple of days reading the laws of my country (UK), and they are surprisingly broad.

Technically the plan is to have a peer-to-peer network over Tor. Privacy is achieved by everyone writing their inputs to the network; when all are supplied they make a new Tor connection & write their outputs.

Some things I didn't get round to:- Peer discovery & running a well-known node - you have to enter an IP to connect to- Adding a command-line switch for ProdNet (an easy code change)- Tor

You can download the jar file right now, and join some testnet coins between N wallets. There is a thorough description of the protocol at DETAILS.md (https://github.com/dustyneuron/bitprivacy/blob/master/DETAILS.md), and the threat model and defenses are in THREATS.md (https://github.com/dustyneuron/bitprivacy/blob/master/THREATS.md). The code quality is rough, but it does have some test cases. Forks, code-plundering, etc all welcome!

I actually put in a grant request to the Foundation for this. I don't think I'll ever get it, at least it gave me an incentive to document everything.

I'd like the administrators of this bounty to make clear some conditions for a large portion of the reward to be given:

Testing - It has been rumored that the recent 200BTC fee transaction was the result of a failed CoinJoin transaction. Regardless of whether or not that is true, unittests and good coding practices should be taken into account.

# of users - Take into account the # of potential users. Solutions applicable for a larger % of the total Bitcoin userbase are much more important than solutions not so widely applicable. Solutions that can be used 'by default' are far more valuable than ones that can-not.

Licensing - Part of being widely applicable is the license of the software. I am in RMS's camp here, and while normally it makes sense to use restrictive open-source licenses in a tit-for-tat scenario, like him I too believe that sometimes getting the idea as widely used as possible is the right approach. Note that RMS has specifically said this in relation to Bitcoin's MIT license. Implementations should use licenses no more restrictive than LGPL.

As the largest individual contributor to date I hope my words are taken seriously.

Yes, I am writing this in response to Amir's proof-of-concept, which is nice to see happen quickly for people to play with, but to see it reported in Bitcoin Magazine already as "and today, two Bitcoin developers in Spain have come up with a solution." very much bothers me given how far it is from a complete solution.

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.

tl;dr: I would be happy to see Amir and co receive a token BTC for their efforts, but they have to put a lot more work in for what they have done to be worth more than that.

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.

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

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.

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.

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

I hereby claim part of this bounty for my work on bitprivacy (https://bitcointalk.org/index.php?topic=279249.msg3029760#msg3029760).

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.

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.

Uh. Does someone have a bug to report for a tool from this thread? (http://blockchain.info/tx/4ed20e0768124bc67dc684d57941be1482ccdaa45dadb64be12afba8c8554537) (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.

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

Quote

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.

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.

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!))

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.

A couple minutes ago Phantomcircuit directed me to this writeup (http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/), 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

(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 8).. 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 :))

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 (https://bitcointalk.org/index.php?topic=175156.msg1832954#msg1832954). 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 (https://bitcointalk.org/index.php?topic=175156.msg2384771#msg2384771) 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 (https://bitcointalk.org/index.php?topic=175156.msg2361587#msg2361587). 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.).

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?

First of all it has to be recognized that in a truly decentralized environment that are almost no protections against sybil attackers; the best you can do is make a sybil attack expensive. Because of this a n-party-mix with fancy cryptography is equivalent to an iterated 2-party mix. (even in an n-party-mix n-1 of the parties might be a sybil attacker) This is not true for the non-decentralized case, such as a mix where access is controlled by possession of a bitcointalk account, or a good OTR reputation.

Secondly in a 2 party mix the other party automatically knows what txins and txouts you are contributing to the mix by process of elimination. There's nothing you can do about that. However you can ensure that only that party knows, provided your counter-party doesn't reveal the info.

Thirdly the anti-dos limited resource should be denominated in Bitcoins, not proof of work or some other similar scheme; you want a large-scale attacker to have costs as similar as possible to a small-scale attacker and PoW functions are very susceptible to large improvements due to optimization. For Bitcoin's that optimization has already happened.

So, building on my previous thoughts earlier in this thread, I'm proposing the following basic mix protocol, here between Alice and Bob:

1) Announce: Alice states that she wishes to create a transaction.

2) Reply: Bob replies with the txins and txout he wishes to add to the transaction.

3) Sign: Alice signs her txins and sends the signatures to Bob.

4) Broadcast: Bob signs his txins, and broadcasts the transaction.

Step 1 happens in the clear; steps 2 and 3 can be encrypted to the pubkeys of the respective receivers.

For anti-DoS the act of broadcasting these messages can be made expensive by requiring the senders to include a nLockTime'd transaction spending a txin to a scriptPubKey the sender controls. Usually this txin would be used in the mix, although technically it doesn't have to be. The key idea here is that by broadcasting such a tx the sender is guaranteed to spend some tx fees somehow, either in the nLockTime'd tx, or in a different tx with the same txin. The actual amount of fees required per KB of data broadcast can be adjusted automatically by supply and demand.

Note how since tx fees are what is being used you automatically have sybil resistance: an attacker trying to be the counter-party to a large % of total traffic will need to either spend, or have access to the privkeys of, a large % of all the transactions being done on Bitcoin itself. While any individual transaction may get unlucky and fall victim to an eavesdropper, overall there is a significant privacy benefit.

As for the broadcast medium, like I suggested above, putting this data on the Bitcoin P2P network itself makes the most sense to ensure the widest possible usage. Similarly re: usage, note how the only cryptographic primitive used in the above protocol that is not currently used by Bitcoin wallets is asymmetric encryption. Being only two parties transactions can go through quickly when counter-parties are available, and they can timeout and fallback to standard transactions otherwise. Bandwidth usage is a small multiple of the transactions themselves; potentially less if return-path routing of the replies can be made to work properly.

FWIW I'm planning on implementing this, either directly in the satoshi client, or as a prototype in python-bitcoinlib. It's a good complement to more complex schemes utilizing multi-party cryptography primitives for mixes among semi-centralized groups.

What about DOS attacks? Can't someone refuse to sign even if the transaction is valid?

Yes, this can be DOS attacked in two different ways: someone can refuse to sign a valid joint transaction, or someone can spend their input out from under the joint transaction before it completes.

However, if all the signatures don't come in within some time limit, or a conflicting transaction is created, you can simply leave the bad parties and try again. With an automated process any retries would be invisible to the user. So the only real risk is a persistent DOS attacker.

In the non-decentralized (or decentralized but non-private to participants) case, gaining some immunity to DOS attackers is easy: if someone fails to sign for an input, you blacklist that input from further rounds. They are then naturally rate-limited by their ability to create more confirmed Bitcoin transactions.

I don't see any way for the DoS adversary to spend the input before the joint transaction completes, if the joint transaction is atomic in the current block. If the joint transaction has been populated to all mining pools, then the input is disallowed by those pools to be double-spent in another transaction in the same block. If there is a competing PoW fork which didn't grab the joint transaction, then which ever fork wins will unwind the transactions of the losing fork(s). Am I missing something or was your point specific to limitations of Bitcoin (and not any altcoin in general)?

If those who want to participate in the joint transaction must sign with their private key to prove they have the funds available, before the set of payers (participant signers) is selected, then they can be fined for not signing the joint transaction. Am I missing something?

I do not know what Bitcoin miners do when they see double-spend attempts in the same atomic block. I am thinking they should submit these to the blockchain under some special transaction which fines the payer.

I guess one issue is that for example with ring (group) signatures, the identity of the signers of the outputs is not known, so if the sum of the outputs doesn't match the sum of the inputs, then it is not known whom to penalize for oversubscribing (DoS) the outputs. We don't want a bijective mapping between inputs and outputs.

This is not decentralized in the sense that the blockchain is a central ledger, but it is meta-decentralized in the sense that PoW input entropy is.

We received information about spam or abuse from paramount@copyright-compliance.com.Please take all necessary measures to avoid this in the future.

Furthermore we request that you send a short response within 24 hours to us and tothe complainant. This response should contain information about how this couldhappen and what you intend to do about it.

How to proceed:- Solve the problem- Send a response to us: Use the following link:http://abuse.hetzner.de/statements/?token=gdfsdfggdghhdddghhdg- Send a response by email to the complainant

A technician will check the data and coordinate further proceeding. If we receivedmultiple complaints, the situation can lead to a server blocking.

Important note:When you reply to us, please leave the abuse ID [AbuseID:djkdfkdgfsf] unchanged in thesubject line.

Irdeto USA, Inc. (hereinafter referred to as "Irdeto") swears under penalty ofperjury that Paramount Pictures Corporation ("Paramount") has authorized Irdeto toact as its non-exclusive agent for copyright infringement notification. Irdeto'ssearch of the protocol listed below has detected infringements of Paramount'scopyright interests on your IP addresses as detailed in the below report.

Irdeto has reasonable good faith belief that use of the material in the mannercomplained of in the below report is not authorized by Paramount, its agents, or thelaw. The information provided herein is accurate to the best of our knowledge. Therefore, this letter is an official notification to effect removal of the detectedinfringement listed in the below report. The Berne Convention for the Protection ofLiterary and Artistic Works, the Universal Copyright Convention, as well asbilateral treaties with other countries allow for protection of client's copyrightedwork even beyond U.S. borders. The below documentation specifies the exact locationof the infringement.

We hereby request that you immediately remove or block access to the infringingmaterial, as specified in the copyright laws, and insure the user refrains fromusing or sharing with others unauthorized Paramount's materials in the future.

Further, we believe that the entire Internet community benefits when these mattersare resolved cooperatively. We urge you to take immediate action to stop thisinfringing activity and inform us of the results of your actions. We appreciateyour efforts toward this common goal.

Please send us a prompt response indicating the actions you have taken to resolvethis matter, making sure to reference the Notice ID number above in your response.

If you do not wish to reply by email, please use our Web Interface by clicking onthe following link:http://webreply.copyright-compliance.com/WebReply?webreplyhash=a1fd4ac345b02bfd8ccde04dafbefbb2

Nothing in this letter shall serve as a waiver of any rights or remedies ofParamount with respect to the alleged infringement, all of which are expresslyreserved. Should you need to contact me, I may be reached at the below address.

Note: The information transmitted in this Notice is intended only for the person orentity to which it is addressed and may contain confidential and/or privilegedmaterial. Any review, reproduction, retransmission, dissemination or other use of,or taking of any action in reliance upon, this information by persons or entitiesother than the intended recipient is prohibited. If you received this in error,please contact the sender and delete the material from all computers.

This infringement notice contains an XML tag that can be used to automate theprocessing of this data. If you would like more information on how to use this tagplease contact Irdeto.

I guess one issue is that for example with ring (group) signatures, the identity of the signers of the outputs is not known, so if the sum of the outputs doesn't match the sum of the inputs, then it is not known whom to penalize for oversubscribing (DoS) the outputs. We don't want a bijective mapping between inputs and outputs.

The only solution to this I see is to use divide-and-conquer to find the adversary (identity tied to the public key committed to the input). By dividing the set size in half and repeat, eventually the adversaries are discovered or they relent and complete the transaction. This is why a mandatory tx fee is important, so as to deplete their capital if they send to themselves.

The output signatures come at step 2, before step 3 where all sign their inputs, thus recursively repeating this operation is less time costly than being able to DoS step 3.

Just an idea - what if we moved the mixing service to miners as a part of the job they do?

- users would broadcast special half-baked transaction (just inputs)- miners would somehow form the queue of unsigned inputs into mixing "batches" and provide a way how to query current batches- users would broadcast their signatures of the batch- when the batch is signed by all parties, its moved by miner into the current block, if after some timeout it is not signed (few blocks?), its dumped

This would reuse existing Bitcoin p2p network and add new message type(s). The transaction will remain the same, no need for fork. It will allow easy integration into existing clients.

Just an idea - what if we moved the mixing service to miners as a part of the job they do?

- users would broadcast special half-baked transaction (just inputs)- miners would somehow form the queue of unsigned inputs into mixing "batches" and provide a way how to query current batches- users would broadcast their signatures of the batch- when the batch is signed by all parties, its moved by miner into the current block, if after some timeout it is not signed (few blocks?), its dumped

This would reuse existing Bitcoin p2p network and add new message type(s). The transaction will remain the same, no need for fork. It will allow easy integration into existing clients.

Thanks for copying my idea upthread, and you added an idea of how to integrate without a fork. I can't comment if that will work or not.

Note that attackers don't actually have to spend that input if they disrupt the protocol. They can use the same one over and over, even many times simultaneously.

PoW could be an option where participants can set a minimum PoW accepted and a maximum PoW they're themselves willing to perform. So for example if 10 people all have 2^15 work within their range of acceptable PoW (one has 2^15 as their lowest, another as their highest, they'll all generate a common input for PoW and start working on it. Then they start this scheme with the SMPC. That would indeed make the attack costly for somebody trying to break the scheme for as many as possible (DoS) and would make Sybil very costly.

Upthread earlier today I proposed a fee for not completing the transaction. I guess you are not proposing that because of timeouts when the participant can't complete but not due to malice?

Thus you propose PoW an a resource cost, hoping this will rate limit.

Hmm. But the rate limiting has to be severe enough that the adversary can't basically shut down transactions (if all are going to be mixed by default which is what I want) entirely, so I am thinking there needs to be a much more severe cost on the adversary.

All costs that fall on the adversary will also fall on the honest participants, but asymmetrically because the adversary will always incur the cost and the participant will only incur it on network timeout.

It isn't certain that you'd be able to tell WHICH input that the attacker used, at least not with my scheme where you hide who's using what input. Revealing who's using what input might not be optimal if a user want to use inputs already tied to himself AND some inputs that aren't already, and doesn't want the unlinked ones to become linked to him.

So if my understanding is correct, a ring signature is comprised of the N public keys and N + 1 large random values (N + 3 for ECDSA), for each signer so (N + 1)^2 plus the N public keys total if each participant is only sending to one output. In practice, they will send to more than one output to hide correlation of input and output amounts.

Yet if my thinking is correct, these large signatures don't need to be stored in the blockchain permanently. This signature only needs to be shown as evidence to all near-term PoW peers for what goes permanently into the blockchain, which are spends for each input to a special public key (which can't spend any other way) which has "spends" corresponding to each output in the signature. So it appears this would require a soft-fork of Bitcoin, because the participants can't send to a normal public key.

No, thats incorrect. Putting ring signatures in transactions would require a hard fork, and under our current security model would require storing the large signature.

Moreover, ring signatures would not be useful in the blockchain. Adam suggested (https://bitcointalk.org/index.php?topic=175156.msg2361587#msg2361587) (uh thanks for pointing to that, I missed that post!) using a ring signature for exactly the same purpose that I suggested blind signing: it would be a mechanism external to the blockchain that participants would communicate the set of outputs to each other without identifying the source. If someone were to try to do what you're suggesting it would enable any of the participants in the transaction to steal the coins. This is exactly the opposite of what we want.

As an aside would you mind adding a link particular ECC ring signature scheme that you're looking at? A reasonably efficient ECC ring signature scheme would be useful to have, and might result in a faster and more compact implementation than the blinded signature approach (esp with many participants). Though I'm not sure how to prevent DOS attacks in such a scheme, since if you get too many outputs you can't tell which party was the cheater, though perhaps some ring signature system would in the event of failure have a way to deanonymize the users so they could determine who produced the extra output.

No, thats incorrect. Putting ring signatures in transactions would require a hard fork, and under our current security model would require storing the large signature.

If there exists a secure proof (the group signature, plus the spend transactions signed by all participants) that total of inputs match the total of outputs and all peers have agreed on this by accepting the block, then we don't need to keep that proof around in the blockchain. We can just keep the spend transactions to a key and spends from that key to the outputs. This would be a special key that the miner can not spend any other way than to providing the matching secure proof. If you disagree, please kindly explain why and not just assert I am wrong without any explanation. I assume you are correct, but I need to see why? Thank you in advance for helping me to understand.

Moreover, ring signatures would not be useful in the blockchain. Adam suggested (https://bitcointalk.org/index.php?topic=175156.msg2361587#msg2361587) (uh thanks for pointing to that, I missed that post!) using a ring signature for exactly the same purpose that I suggested blind signing: it would be a mechanism external to the blockchain that participants would communicate the set of outputs to each other without identifying the source.

Yes, but I am explaining how I am thinking we can use the miner to help out in a special way as I have described upthread.

As an aside would you mind adding a link particular ECC ring signature scheme that you're looking at? A reasonably efficient ECC ring signature scheme would be useful to have, and might result in a faster and more compact implementation than the blinded signature approach (esp with many participants). Though I'm not sure how to prevent DOS attacks in such a scheme, since if you get too many outputs you can't tell which party was the cheater, though perhaps some ring signature system would in the event of failure have a way to deanonymize the users so they could determine who produced the extra output.

Upthread, I described a divide-n-conquer strategy for identifying the adversarial DoS participant.

I just pulled up the first thing on Google, not sure if it is applicable, Anonymous signcryption in ring signature schemeover elliptic curve cryptosystem (http://www.signcryption.org/publications/pdffiles/chung-wu-lai-jcis06-CSI-38.pdf)

If there exists a secure proof (the group signature, plus the spend transactions signed by all participants) that inputs match the outputs and all peers haveagreed on this by accepting the block, then we don't need to keep that proof around in the blockchain. We can just keep the spend transactions to a key and spends from that key to the outputs. This would be a special key that the miner can not spend any other way than to providing the matching secure proof. If you disagree, please kindly explain why and not just assert I am wrong without any explanation. I assume you are correct, but I need to see why? Thank you in advance for helping me to understand.

This is oftopic, I was trying to avoid the Bitcoin 101 in this thread.

The security model of Bitcoin is that nodes do not trust the network. The network is anonymous parties and could be chalk full of sybils, so we consider it malicious at all times. We verify _everything_ for ourselves that can be— the one thing that cannot be is transaction ordering. Because everything is verified the potential for gain in sybil attacking or lying about the ordering is small. Under what you're suggesting miners could steal arbitrary coins from third parties at the expense of mining a few blocks (whatever depth you require to permit hiding the proof). This isn't the security model we've adopted, and it's one that might unhinge the economic alignment of miners.

As to why it would be a forking change— you want the Bitcoin network to allow the spending of coin based not on the current signature types allowed but on a new ring type. These transactions would look like theft to the existing network and so they can't be supported without a hardfork to relax the rules.

Quote

How so? The participants sign to a special key that can't be spent any other way (blockchain will forbid it).

A ring signature specifies N keys and then provides a signature which could have been provided by any of the N. I may have been misunderstanding what you were suggesting but it sounded like you were saying that a transaction would be signed by a ring signature over its inputs. This means that without your consent I could take a coin of mine, and a coin of yours, and write a transaction paying to two addresses of mine, and provide a ring signature ... and steal your coin.

If instead you mean that it would also require the individual scalar signatures. Then there is never any reason to have the ring signature in the blockchain, the participants could just perform it externally and sign conditionally on it passing.

I pushed the beginnings of a framework for a CoinJoin implementation using RSA blinded signature operations. It's written in Python and under the MIT license:

https://github.com/maaku/coinjoin

So far it's a storage layer for the various objects and message involved in the protocol, some simple primitives for the blinding operations, and a few utilities for pulling outputs from JSON-RPC. I'm working on more primitives that I will probably add next week, including tools for creating messages at various stages, and eventually getting this running over BitMessage.

If there exists a secure proof (the group signature, plus the spend transactions signed by all participants) that inputs match the outputs and all peers haveagreed on this by accepting the block, then we don't need to keep that proof around in the blockchain. We can just keep the spend transactions to a key and spends from that key to the outputs. This would be a special key that the miner can not spend any other way than to providing the matching secure proof. If you disagree, please kindly explain why and not just assert I am wrong without any explanation. I assume you are correct, but I need to see why? Thank you in advance for helping me to understand.

This is oftopic, I was trying to avoid the Bitcoin 101 in this thread.

I think maybe I am the one teaching you Bitcoin 101 here... (yes I know you are a Bitcoin core dev and all due respect is accorded to you)

The security model of Bitcoin is that nodes do not trust the network. The network is anonymous parties and could be chalk full of sybils, so we consider it malicious at all times. We verify _everything_ for ourselves that can be— the one thing that cannot be is transaction ordering. Because everything is verified the potential for gain in sybil attacking or lying about the ordering is small.

I don't know why you mention Sybil attacks, since miner reputation is irrelevant.

The attacker must have 51% of the difficulty to be dishonest in order to cheat against the others who respect the protocol. Miners have an incentive to ignore what does not match the group signature proof, because other miners will ignore them, and they would waste effort doing PoW on a fork that the majority rejects.

That is basic Bitcoin 101 stuff. I think you are conflating the need to verify the transaction chain with my point. The transaction chain must be verified, because it is the way to make sure a more recent spend did not occur.

Under what you're suggesting miners could steal arbitrary coins from third parties at the expense of mining a few blocks (whatever depth you require to permit hiding the proof). This isn't the security model we've adopted, and it's one that might unhinge the economic alignment of miners.

The miner(s) can not steal anything unless they have 51% of the difficulty as explained above.

Admittedly this is worse than now, where a 51% attack can't spend other people's coins. But if you have a 51% attack, then you've got big problems any way. And as soon as a few coins are misspent, everyone will realize the network is compromised. Just keep the group signature proof in the blockchain long enough for the participants to file a public claim in the media. So lets say 1000 blocks?

As to why it would be a forking change— you want the Bitcoin network to allow the spending of coin based not on the current signature types allowed but on a new ring type. These transactions would look like theft to the existing network and so they can't be supported without a hardfork to relax the rules.

Apology I did not make it clear that I wasn't disputing your point about hard fork.

How so? The participants sign to a special key that can't be spent any other way (blockchain will forbid it).

A ring signature specifies N keys and then provides a signature which could have been provided by any of the N. I may have been misunderstanding what you were suggesting but it sounded like you were saying that a transaction would be signed by a ring signature over its inputs. This means that without your consent I could take a coin of mine, and a coin of yours, and write a transaction paying to two addresses of mine, and provide a ring signature ... and steal your coin.

If instead you mean that it would also require the individual scalar signatures. Then there is never any reason to have the ring signature in the blockchain, the participants could just perform it externally and sign conditionally on it passing.

I am saying that N participants (inputs) can make M signatures for outputs, where M >= N. If the total BTC of outputs != total BTC of inputs, then the N participants don't sign their inputs. Reset and try again.

When they don't match, that is a DoS, someone is trying to cheat. I explained upthread how to use divide-n-conquer to isolate the malicious participant(s).

At one point in the conversation I brought up CoinJoin and what it makes possible and his immediate reaction was, "That will have to be stopped."

They can't even be distinguished. Short of a complete lockdown (and a total failure of the system) there is no way to block the activity or even reliably measure how much of it is going on.

I don't think this actually presents much concern to authorities— they manage to survive in a world where cash and other asset transfers leaves few records already. When tax authorities question you to make sure you're paying your taxes, they'll ask to see your books same way it works with anything else... and nothing in this thread will protect someone there, at least in the US the responsibility is on the taxpayer to show they paid their taxes. But in any case, the political debate is moot... just due to the technological inevitability of this: I've tried to think of a way to prevent it, and I cannot.

The miner(s) can not steal anything unless they have 51% of the difficulty as explained above.

Admittedly this is worse than now, where a 51% attack can't spend other people's coins. But if you have a 51% attack, then you've got big problems any way. And as soon as a few coins are misspent, everyone will realize the network is compromised. Just keep the group signature proof in the blockchain long enough for the participants to file a public claim in the media. So lets say 1000 blocks?

And even there may be a solution to this 51% attack that enables the miners spending the coins. We keep a merkel hash of these signatures forever, so the spenders (or bitarchive.org ... does it exist?) can keep copies of the signatures and later prove if the miners have cheated. This would serve for rebuilding the blockchain manually, because with a 51% attack, the Bitcoin world is fubar anyway.

At one point in the conversation I brought up CoinJoin and what it makes possible and his immediate reaction was, "That will have to be stopped."

They can't even be distinguished. Short of a complete lockdown (and a total failure of the system) there is no way to block the activity or even reliably measure how much of it is going on.

I don't think this actually presents much concern to authorities— they manage to survive in a world where cash and other asset transfers leaves few records already. When tax authorities question you to make sure you're paying your taxes, they'll ask to see your books same way it works with anything else... and nothing in this thread will protect someone there, at least in the US the responsibility is on the taxpayer to show they paid their taxes. But in any case, the political debate is moot... just due to the technological inevitability of this: I've tried to think of a way to prevent it, and I cannot.

Precisely, the political debate is moot. Because the technology is economically superior and demands this solution, it is inevitable. In fact, I would not be surprised to see a successful CoinJoin functionality implemented in an alternate client before the end of the year, e.g. as coderrr's coin selection patch was. And this will only be Gen 0 for anonymising tools ...

The modern State needs to abandon their utopian panopticon matrix ambitions and go back to doing proportional policing relevant to a free society, for many reasons too numerous to mention.

Besides, this is a Development & Technical section ... suffice it to say, CoinJoin and other anonymising tools are inevitable ... just like Judgement Day.

CoinWitness is even rocket-sciency than Zerocoin, it also shares many of the weaknesses as a privacy-improver: Novel crypto, computational cost, and the huge point of requiring a soft fork and not being available today. It may have some scaling advantages if it is used as more than just a privacy tool. But it really is overkill for this problem, and won't be available anytime real soon.

After further thought off-chain transactions with CoinWitness is insecure, i.e. bringing off-chain transaction back on to the blockchain at par is insecure. How can we be sure there wasn't a double-spend?

This is analogous to trying to operate multiple blockchains with a fixed value between them.

If coins are allowed to be moved between blockchains at par (no market exchange variance) and the blockchains don't exchange coins at par with any blockchains that don't adhere, the problem remains that 50% attacking the blockchain with the lowest PoW difficulty will infect with ill effects the blockchains with higher PoW difficulty.

After further thought off-chain transactions with CoinWitness is insecure, i.e. bringing off-chain transaction back on to the blockchain at par is insecure. How can we be sure there wasn't a double-spend?

This is explained in the CoinWitness post, it's as secure as you wish to make it. It's also offtopic. Please stay on-topic and if you want to talk about that please post in that thread.

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

Can't MIT licensed wallets be relicensed under the AGPL?

The AGPL says that the user is allowed to access the source code; even while interacting with a remote server.

The remote server should not be directly connected to a live wallet anyway.

hi,i'm thinking about coinjoin transactions and how they are supposed to be indistinguishable from normal transactions.

some notes:a) the number of participants of a coinjoin transaction must be variable. otherwise, if _all_ coinjoin transactions contain 55 inputs, then that's a pretty strong distinguisher.

b) the distinguishability of the coinjoin transaction is equal to its weakest link. that is, if two people in a coinjoin tx use input addresses that have been reused and can be linked to their identity, then the whole coinjoin tx has been busted.

i also wonder whether building a decentralized coinjoin system is as easy as some people here believe it is.i think it's a good idea to design it and state its threat model before standarizing coinjoin.otherwise, we will be stuck with the centralized coinjoin variant, where anyone can join the public channels and log the mixes.

b) the distinguishability of the coinjoin transaction is equal to its weakest link. that is, if two people in a coinjoin tx use input addresses that have been reused and can be linked to their identity, then the whole coinjoin tx has been busted.

Interesting point... though it depends on the specifics: Perhaps the transactions linking them to their identities were the CJ ones and the later apparent CJ is just a single person.

Don't let me overstate the indistinguishably too much, there are many potential transaction pattern side channels (e.g. from the use of compressed or uncompressed public keys, for example, down to what times of day transactions happen) but at a low level these transactions are not fundamentally unusual.

Quote

i also wonder whether building a decentralized coinjoin system is as easy as some people here believe it is.i think it's a good idea to design it and state its threat model before standarizing coinjoin.otherwise, we will be stuck with the centralized coinjoin variant, where anyone can join the public channels and log the mixes.

I think it's pretty hard, not in the overall components but in all the details. My expectation is that there will be multiple systems for some time, if not forever, offering differing properties and tradeoffs. The harm from the anonymity set reduction that would result from that may be partially addressed by users that use multiple tools, and from them making their transactions look externally indistinguishable.

Even in the centralized model think it can be fairly easily arranged so that random non-participating observers can't tell what txins are in flight, e.g. a meeting point host is selected an inputs are only revealed to it. Maaku has also already implemented chaum blinded signatures, so the input-output correspondence can be hidden from the meeting point.

I think there are different application and threat models in flight here. For me the most important in the short term are the weakest ones— just getting a non-trivial number of joint transactions in use in order to disrupt the analysis for all users (including ones who've never used CJ) will be a big practical improvement.

I have done some work previously on the problem and came up with a (theoretical) solution that is quite analogous to CoinJoin but that uses a fixed network off 2-party txs instead of a potentially bigger one. You can see the video herehttp://www.youtube.com/watch?v=6hc8qaR_Fok&list=PLUOP0P68GJ3BGjfqoLLnzAefk3ZzXQtJ7&index=35but as there is a lot of what I am talking about that has already been discussed here, I would like to simply upload the pdf. Is there a website similar to pastebin where I can do that for pdfs? I also have a more detailed description of the network that might be of interest here that is also in pdf format.

Someone previously proposed using Secure Multiparty Computing before to implement CJ, but one must realise that SMC is only a set of tools. E.Z.Yang proposed one specific implementation using sorting, which is a cool idea, but according to Yang himself is currently not feasible in practice. In his own words, "The big obstacle is that secure multiparty sorting is somewhat difficult to implement with large keys (since integer comparison operations tend to only handle a few bits at a time)." The hunt is still on to find an efficient way to use SMC to solve the problem.

I am quite excited that people are working on making this work and will be trying the programs proposed here when I can.

Edit:Link to the video's pdf: https://www.dropbox.com/s/nvkvo1dl3xif87v/PresentationBitcoin2013.pdf

It isn't certain that you'd be able to tell WHICH input that the attacker used, at least not with my scheme where you hide who's using what input. Revealing who's using what input might not be optimal if a user want to use inputs already tied to himself AND some inputs that aren't already, and doesn't want the unlinked ones to become linked to him.

Send all inputs to one key first.

I don't see how that solves anything. You just openly linked your own inputs together yourself, then.

Someone previously proposed using Secure Multiparty Computing before to implement CJ, but one must realise that SMC is only a set of tools. E.Z.Yang proposed one specific implementation using sorting, which is a cool idea, but according to Yang himself is currently not feasible in practice. In his own words, "The big obstacle is that secure multiparty sorting is somewhat difficult to implement with large keys (since integer comparison operations tend to only handle a few bits at a time)." The hunt is still on to find an efficient way to use SMC to solve the problem.

I am quite excited that people are working on making this work and will be trying the programs proposed here when I can.

General SMC/MPC (myself I usually abbreviate it as SMPC) does exist. But it seems to be less efficient than specific ones like for sorting. I am eagerly waiting for efficient general SMPC to become usable for average joes. :)

As I write this people with unknown motivations are raining down tiny little payments on old addresses, presumably in an effort to get wallets to consume them and create evidence of common address ownership.

I don't quite understand this. These dust are being sent to old addresses. That means that whomever has the private key that can spend the money at the old txout can also use that same key to spend the money at the new "tiny little payment" txout?

So if the dust is spent, there is evidence that the old address represents someone who is still paying attention and still has the key to that old money. That seems like something important to know in trying to assess the real currency supply (ie, someone wants to estimate how much bitcoin has been lost). That is not particularly dangerous or adversarial; it's just good sense to know.

But it is dangerous to privacy, because if dust sent to multiple different addresses is gathered together into one account, that could be taken for evidence that the different addresses are in fact controlled by the same person?

Do I understand the threat right?

The correct solution then for the account holder, is to use the 'dust' and the 'old account' with the same key both as txin for a new transaction, with a single output. There is no harm in letting someone know that the money has not been lost and that its owner is still paying attention, but consolidating the dust together with the account whose key it shares should do no harm to privacy.

Is there any reason why that solution would be the wrong thing for the account holders to do?

This seems overly complicated. Is there any reason why Bitcoin isn't private enough as it is?You presented a hypothetical situation which has not occurred yet. It's not perfectly private but compared to credit cards and banks its very private. It's almost as private as cash.

I edited that post down from a longer (4000 word?) version which included some specific examples that I had some personal involvement in: The (third?) ozcoin thief, who was identified by sending funds to a wallet service that reused addresses (and ultimately had those funds clawed back), and a person who had an insecure brain wallet found by a whitehat, ultimately tracked down and contacted due to a mining pool which reused addresses.

There are many other examples of privacy in Bitcoin being weak— one only needs to spend a few minutes browsing through bc.i's public block explorer interface (http://blockchain.info/) to see real names attached to transactions (found by spidering webforums) and frequently accurate IP addresses (associated by connecting to many nodes), and from there you can find additional related addresses with the taint analysis button. Or look at the academic research (http://arxiv.org/abs/1107.4524) "Bitcoin is not inherently anonymous. It may be possible to conduct transactions is such a way so as to obscure your identity, but, in many cases, users and their transactions can be identified." (papers on Bitcoin are of, ahem, highly variable quality— but the point remains, Bitcoin's privacy as it is today is not very good).

The privacy gap between Bitcoin and cash for most users is enormous, enough so that we have an explicit warning on Bitcoin.org (http://bitcoin.org/en/you-need-to-know):

Quote from: bitcoin.org

"Some effort is required in order to protect your privacy with Bitcoin. All Bitcoin transactions are stored publicly and permanently on the network, which means anyone can see the balance and transactions of any Bitcoin address. However, the identity of the owner cannot be associated with their Bitcoin address until personal information is revealed by the owner during an exchange. This is why it is recommended for Bitcoin owners to use many different Bitcoin addresses; in fact, you should create a new one each time you receive money. This is especially important for public uses such as websites. You might also want to consider hiding your computer's IP address with a tool like Tor so that it cannot be logged."

Ignorance of these limitations makes the situation worse because without being acutely aware of the risk you will transact in ways that leaks more information about you and the parties you trade with.

Okay here is a potential attack which is enabled by anonymity in the Bitcoin network.

Let's say I'm a government agency and I decide to exploit the fact that Bitcoin allows anonymous transactions. What I could do is covertly corrupt and take over entire countries utilizing anonymous transactions. I could initiate a covert operation where my government prints unlimited amounts of fiat currency, then it's agents go and buy Bitcoins and then these agents can now bribe any politician anywhere in the world. For sake of argument let's say the currency is the dollar and the agency is the CIA.

What is to stop that agency from playing Santa and bribing anyone and everyone with unlimited ability to buy Bitcoins or mine them? In this case being anonymous would allow for copious amounts of political corruption and opulence at the expense of democracy itself.

Now for a less conspiracy based attack, how about we look at Satoshi Nakamoto himself? A private citizen who has a million Bitcoins? If we make the network anonymous what is to stop him from taking over entire countries politically? He would essentially gain almost Jesus like power over countries where he would be able to bribe any politician, any private citizen, with anonymous payments into their Bitcoin wallets.

In a pseudo-anonymous world we would know at least that someone we suspect to be Satoshi Nakamoto or affiliated with the early blocks are spending coins and we would know what amounts and other little details so that we could limit corruption via transparency. How can we limit corruption in a world where the 1% can spend anonymously?

Despite the myth and rumor, cash is not anonymous. You cannot get cash from an ATM without being on camera. You cannot accept cash from another person without them potentially finding out your identity or seeing your face. If you send cash to a politician in the mail your finger prints and other evidence will be left behind. Bitcoin is different because if it becomes anonymous then any billionaire in the 1% could decide to buy a state political system and systematically bribe politicians with anonymous Bitcoin rewards and there would be no way to counter this except with a fork.

Ultimately I think anonymity seems to be more a reaction to government overreach but not a long term solution to government corruption. If you put in anonymity then the corruption may become more hidden, and governments wont lose any power. Governments will be able to finally get involved in manipulating the Bitcoin economy and network. They'll be able to do it covertly with operatives, but there is nothing to stop a government from doing this.

For that reason I think more thought on the philosophical level should go into how to implement anonymity in a way which it cannot easily be exploited by the bad guys or have unintended consequences. If corruption is why our governments are bad, enabling it is only going to make it worse. I think for myself what I want is the ability to buy something privately and not have what I buy be known, but I don't necessarily need my transactions hidden. Anyone can know my pseudonym spent X amount of Bitcoins, just so long as they don't know what I spent it on.

If people want to know what I spent it on they'll have to ask personally. That is private information. Secret is a different matter because then I wouldn't even be able to tell you. So how do we set things up so that if I wanted to help fight against corruption or clear myself in an investigation I can do so while also maintaining my anonymity? I think pseudo-anonymity would allow me to do it easiest because I could digitally sign my receipts detailing what I purchased and it could be released in the future to clear myself of any wrongdoing.

I think as long as the user has the ability to be pseudo-anonymous while also having the ability to do record keeping, then if there is an incident then Alice has detailed records of all her transactions and what she purchased which she can give to Gordon to prove her innocence. If she does not have this information then she cannot prove her innocence to Gordon and that is an existential danger to Alice. I'm interested in lowering the risk to Alice (who represents the user who is using Bitcoin for legitimate purposes). I don't want to help Mallory or Eve.

At one point in the conversation I brought up CoinJoin and what it makes possible and his immediate reaction was, "That will have to be stopped."

They can't even be distinguished. Short of a complete lockdown (and a total failure of the system) there is no way to block the activity or even reliably measure how much of it is going on.

I don't think this actually presents much concern to authorities— they manage to survive in a world where cash and other asset transfers leaves few records already. When tax authorities question you to make sure you're paying your taxes, they'll ask to see your books same way it works with anything else... and nothing in this thread will protect someone there, at least in the US the responsibility is on the taxpayer to show they paid their taxes. But in any case, the political debate is moot... just due to the technological inevitability of this: I've tried to think of a way to prevent it, and I cannot.

Precisely, the political debate is moot. Because the technology is economically superior and demands this solution, it is inevitable. In fact, I would not be surprised to see a successful CoinJoin functionality implemented in an alternate client before the end of the year, e.g. as coderrr's coin selection patch was. And this will only be Gen 0 for anonymising tools ...

The modern State needs to abandon their utopian panopticon matrix ambitions and go back to doing proportional policing relevant to a free society, for many reasons too numerous to mention.

Besides, this is a Development & Technical section ... suffice it to say, CoinJoin and other anonymising tools are inevitable ... just like Judgement Day.

When we design these technologies we should look at use cases. In my thinking the user worth protecting in my use case models is Alice. Alice is the user who wants to use these technologies for legitimate purposes, who wants her privacy to buy books without Eve or Mallory knowing everything she buys without a warrant.

Gordan (the government agent) wants to investigate Mallory (the malicious user). if he has a warrant he should be able to go to Alice and get information from Alice to reconstruct the events. He will want to know what she purchased, when, what Bitcoin addresses she owns, etc. The addition of anonymity on the network puts an additional burden on Alice to keep records of everything she purchases. It also will make it much more likely that she'll be contacted by Gordon as part of an investigation.

The solution I offer is to make detailed record keeping easy and simple. These records should be good enough that if investigators do have a warrant that you can show that you're not a threat. This is necessary to protect Alice by lowering her risk of being falsely accused and it helps save Gordon time because he wont have to worry about as many false positives.

Mallory and Eve are the problem characters. Eve wants to wiretap everyone without a warrant or reason and just snoop around. Mallory wants to hack everyone or use the Bitcoin network for malicious purposes such as pursuit of political power, as part of a crime network, or perhaps a government plot or conspiracy.

Alice justs wants to be able to buy books and not have everyone know what book she's buying and when. If there is a warrant Alice is willing to provide the information to clear herself and prove she's not involved with terrorism. The point here is that any design has to make it easy for the user to deal with different plausible scenarios. The default user is Alice, but Mallory or Gordon could also be users of the Bitcoin network.

The idea I have is to empower Alice to collect and store her own digital fingerprint and digital trail. This trail could be useful if she's ever questioned by Gordon. It should have as much or as little detail as deemed necessary to legally clear herself and the amount of detail in the records should be set by Alice but it is clear to me that there can be no invisible transactions in a secure system.

The transactions have to be recorded somewhere by someone. It does not have to be recorded by Eve though. So when you take transactions off the public ledger, in my opinion you must record transactions on a private ledger of your own. This means Alice can have anonymous transactions, but she's going to have to keep detailed records of account of each of these transactions, because someday she's may have to explain those transactions. The assumption people have is that Alice will be able to have anonymous transactions without any added responsibility, that is very unlikely. In my opinion it means more responsibility on Alice.

It's going to reach a point eventually where if Alice cannot explain every transaction by providing her private ledger to Gordon during the investigation, that she could be jailed. As a result it may become just as important to backup your transactions and digital details as it is to backup your wallet. Right now it's all handled by Bitcoin itself so no one is forced to religiously record every transaction they make.

Nothing being discussed here is a "put in", this thread is about existing functionality which is fundamental to Bitcoin and has been there since day one, if not widely recognized.

Quote

while also having the ability to do record keeping, then if there is an incident then Alice has detailed records of all her transactions and what she purchased which she can give to Gordon to prove her innocence. If she does not have this information then she cannot prove her innocence to Gordon and that is an existential danger to Alice. I'm interested in lowering the risk to Alice

I don't think it's even possible to construct a system in the context of Bitcoin that doesn't have a property of permitting strong personal record-keeping. It would certainly be difficult to accomplish, and I don't think anyone currently wants such a system. I agree with you that the ability to keep records is important, and the fact that users can (and should) keep their own private records which could potentially be discovered as part of some lawful process is, in fact, one of the arguments that I give as to why privacy does not have an excessive risk of harm to society.

But it is dangerous to privacy, because if dust sent to multiple different addresses is gathered together into one account, that could be taken for evidence that the different addresses are in fact controlled by the same person?

Do I understand the threat right?

The correct solution then for the account holder, is to use the 'dust' and the 'old account' with the same key both as txin for a new transaction, with a single output. There is no harm in letting someone know that the money has not been lost and that its owner is still paying attention, but consolidating the dust together with the account whose key it shares should do no harm to privacy.

Is there any reason why that solution would be the wrong thing for the account holders to do?

You understand the concern there. And your proposed solution is a correct one but for two issues: It doesn't reflect the behavior of current wallet software, and making additional payments in that 1:1 manner takes more space and pays more transaction fees. A third option of just ignoring unsolicited payments, though this would have some long term adverse impacts on the system.

The solution I offer is to make detailed record keeping easy and simple.

You're not offering any solutions at all as far as I can tell you're just blathering about philosophy of design, like too many of us here no doubt ..... at some point it comes down to "code it or it didn't happen".

Also your approach of trying to dream up and cover every possible use case is futile. In the end, the coders get to decide what gets experimented with and the market gets to decide what gets adopted. My position is that strongly anonymous money is economically superior so the market will prefer to use it. I've seen zero evidence or research from the advocates for traceable (stasi) money that this is not the case. Ask yourself if you really want to know what that $100 bill in your wallet was used for before you owned it? Would you throw it away if you knew it had once been used to buy cocaine or pay for a hooker or a child slave? Money is money, an economic good, try not to confuse it with other technologies which it is not.

My position is that strongly anonymous money is economically superior so the market will prefer to use it.

I am not sure why that position could be argued with. There are three main costs attached with current currencies and payment systems: time, money and privacy.

Bitcoin and implementations like CoinJoin simply decrease those costs in spite of price controls like price floors such as linking identity to account/credit card, etc. with Coinbase and ACH accounts.

And if Bitcoin does not relentlessly drive down those costs then some substitute good will arise that will drive down those costs and the result, everything else being equal, will be decreased demand for Bitcoin and increased demand for the substitute because it has a lower cost but equal or greater utility.

Luckybit:Ask yourself if you really want to know what that $100 bill in your wallet was used for before you owned it? Would you throw it away if you knew it had once been used to buy cocaine or pay for a hooker or a child slave? Money is money, an economic good, try not to confuse it with other technologies which it is not.

It's not my business to know that. I'm not asking for a stasi coin where I know what everyone purchased. Thats not the case I was making. I'm saying if we go anonymous then each of us will have an increased level of responsibility. We will have to keep track of all of our own purchases and when the investigators question us we will have to give them that information. We will have to explain receipt by receipt and in detailed records what we did with our coins. We will basically be required to report our economic activity just as banks are required to do so now because we will essentially be our own personal banks.

I admit that is better than the way things are now where everything we purchase with a credit card is automatically known to the whole world. They know what books we read, what movies we watch, and more without having to have a warrant or any reason to know it. No one is supporting their ability to snoop on us without a warrant.

At the same time it was also made clear to me that Bitcoin is not private enough. I'm in agreement that Bitcoin needs greater privacy protection. The question is how do we do it in a smart way. Do it in the wrong way and the whole experiment could fall apart. In my opinion the right way is we have anonymous purchases but also an pseudo-anonymous way to report our purchases if there is an investigation.

Imagine there is an incident and you want to be pro-active to separate yourself from the child trafficking incident? The way to do this would be to upload pseudo-anonymously your transaction details complete with notes on what you purchased to the investigator and digitally sign it. This would rule you out immediately.

The only concern I have about it is minimizing the risk of false positives and of people getting sucked into incidents in dragnets. The investigators have a job to do, we want privacy. I don't see why we have can't both win.

The solution I offer: We must regulate ourselves and be at least as responsible as traditional banks are now.This would mean we will have to keep track of whatever records/pseudo-identities necessary to help in whatever investigation. Just as ISP's are now required to keep records, and banks are required to keep records, if we each become our own ISP through a meshnet and we each become our own bank through peer to peer Bitcoin it actually means with this increase in freedom we will also have an increased responsibility. It's an unavoidable consequence of growing up as a new technology. Our transaction logs right now aren't very detailed, but in the future it will probably be a situation where every single Bitcoin transaction you make produces a detailed digital receipt which gets encrypted and emailed to your email address. Right now if you conduct transactions on Wallet A and then delete the wallet then all those transactions from that pseudo-identity are lost? No they are stored on the public ledger but what is lost is your connection to it.

Then you do transactions from wallet B and wallet C, and lets say you actually save transaction details here? Well then you have all the various off-chain transactions and websites with built in wallets, ultimately its messy.

At some point pressure will build to create a unified pseudo-identity management system where a user creates a persistent pseudo-anon master wallet identity and all the additional extra pseudo-identities are branched from that similar to the master password in Mozilla. Then the user could basically sign in once with the master identity and select any of the different pseudo-identities with their own wallets as a completely different identity. It does not change the fact that if something goes wrong they will have to own the master identity and all the pseudo-identities branched from it. The investigators looking for a specific wallet address could rule them out quick.

Yeah, you seem pretty lost. The technology is not going to do what you want ... sorry. There was time when ISPs and banks weren't required to keep records (I don't think you would remember it), the world was definitely a better place then. These are requirements that were brought in by the police state surveillance grid that you recognise as malignant, but not their methods ....

I think it's kind of moot in any case. Being able to keep good records on your own, privately, is an essential feature to offer— just the basis of good book keeping. Your political motivations for doing so (or not) really aren't important for the technology.

The solution I offer: We must regulate ourselves and be at least as responsible as traditional banks are now.This would mean we will have to keep track of whatever records/pseudo-identities necessary to help in whatever investigation.

First of all, that's not a solution, and secondly, the pseudo-problem you're trying to solve is not under the scope of Bitcoin.

Bitcoin is a currency, not a surveillance protocol. So the improvements on Bitcoin should be made in the direction of the former and not the direction of the latter.

It is not the responsibility of users of currency to facilitate the investigations of third parties. Though I reject the idea that anyone should assist the investigations of any presumed authority that claims to be a "monopoly on violence."*

For the same reason I reject the idea that a fully anonymous Bitcoin is "less responsible" than a pseudonymous Bitcoin.

The records that participants voluntarily keep are for their use only, and exist to prevent fraud and extortion, not to hold people accountable for transactions deemed unethical by the local oligarchy's inquisitors.

It is further beyond ridiculous to want to avoid bribes to oligarchs because you fear that bribery will cause them to abuse power. Even if you naively thought politicians would be beneficent rulers without the influence of bribery, the political structure of governing cannot be cured of the ignorance that causes the majority of the damage.

If you doubt this, consider the knowledge that politicians of the world possess. Name the politician that is a professional in the fields of medicine, road construction, gumball manufacturing, carpentry, and aeronautics. Name for me one politician for whom it cannot be said is an intellectual infant in the vast majority of all fields he claims to be arbiter of.

If any particular oligarchy is indistinguishable from a mob of infants deciding on arbitrary matters, then it hardly matters if their intentions are good or evil. Their actions can only be inept, heavy-handed, short sighted, and destructive.

TLDRThere will always be Luddite puerile power mad oligarchs in the world, that's not Bitcoin's problem.

One thing to be aware of is the potential lack of security even using Tor right now, so one should be using Tor 2.4 or later even though it is alpha. See below. Once CoinJoin is live, one should be aware of Tor versions for best practices in privacy.

One thing to be aware of is the potential lack of security even using Tor right now, so one should be using Tor 2.4 or later even though it is alpha. See below. Once CoinJoin is live, one should be aware of Tor versions for best practices in privacy.

One thing to be aware of is the potential lack of security even using Tor right now, so one should be using Tor 2.4 or later even though it is alpha. See below. Once CoinJoin is live, one should be aware of Tor versions for best practices in privacy.

I propose a specification of the CoinJoin protocol. It is not yet implemented, but if you find the work-flow sound it would not be hard to make an IRC bot with the sx command line utilities as a proof-of-concept.

The idea is a P2P network where a thread is relaying all transactions. Another thread is in charge of the mixing.

A first, simple implementation would be an IRC bot which sends and listens to encoded transactions. Of course this approach would not be P2P, but a public channel in a hidden IRC server provides several advantages:

-Easy implementation: IRC servers already exist. Bots enter to the channel #coinjoin (for example) and speak there. -Soft trust system: - If we trust the IRC server (for large values of 'trust') and only registered nicks are allowed to talk in the channel, a Sybil attack will be difficult. - We can chat (privately or publicly) with some users and thus allow them to prove their identity (by signing a given message, telling you a private joke, etc.)

The concept is composed by two parts (threads):

1) Communications thread: In the case of the IRC server architecture, it has the method "sendTransaction" and "listenToTransaction". The first one "chats" in the channel and the latter listens to transactions and stores them in memory.

2) The actual mixing part: Its work-flow is showed in the link [1]. It has been designed with yEd (http://www.yworks.com/en/products_yed_download.html) and the file (if you want to edit it) is [2] . The main points are:

- It handles "change" addresses. If you want to mix 47 BTC, it will be a pain (really!) to make 47 inputs of 1 BTC and mix the separately. This approach allows you to send the 47 BTC as input, recover 1 BTC (for example) mixed and your 46 BTC back (of course, not mixed! In order to avoid confusion, this change address is the same as the input address). Fees are deduced from the change address, and thus you can serialize this method trivially as many times as you want.

- Random decisions to avoid an attacker that listens how the transaction is constructed to map inputs with outputs. Each time transactions are composed in a different order.

- If something goes wrong (bad signature, peer not responding, etc.) the output is discarded and the process restarted.

I agree that it might not be ideal, but it does not compromise the anonymization. It is not intended to be pretty, but useful, and to decrease the chance of the user making mistakes.

If you obtain an explicit change address from the user there won't be any confusion or mistakes. And it does reduce privacy— otherwise a third party is still unsure about the ownership of the change, if less unsure than they are about the other outputs.

Are you planning on writing software that does this? if not, the debate is kind of moot.

1) Why is there a change address?Because more often than not the user has more coins than the standard amount to mix (for example, 1 BTC).

2) Why is the same as the input address?Because it makes clear that these funds are NOT mixed. Not only slightly mixed (in my previous example, the output with 49 BTC is obvious where it came from). There is no such thing as "little unsure". Funds are completely anonymous*, or they are identifiable. And I chose to make it clear in the protocol.

I would like feedback in the protocol itself. For example, how can a transaction be re-identified, or under which circumstances the program may be stuck. If you still believe that reusing the change address would compromise anonymity, please give a concrete example of how.

If it is OK, developing the program is quite straightforward. All the tools exist already (it can be even a bash script with the sx tools).

*Under certain assumptions, like for example excluding the other party (this is why the process is repeated several times)

The client knows from the history which outputs were added as part of the mix, and which were the result of explicit change addresses. This information needs to be tracked anyway because joined coins are not completely anonymous. At best each join adds only a few bits of entropy, and any competent implementation would have to track how much entropy is added with each mix, and therefore would be perfectly capable of setting entropy=0 for change outputs.

EDIT: BTW, in case anyone hasn't seen it, I'm running a crowdfund (https://bitcointalk.org/index.php?topic=291283.0) to finish the chaum blinded signature version of the protocol that I've started working on (https://github.com/maaku/coinjoin).

phase 2. Now make 'normal' transaction be transaction exclusively in minted coin. Other transactions still legal, just not 'normal' anymore (or maybe not 'normal' unless accompanied by bigger tx fee for miner).

phase 3. Clients concerned with privacy may start participate exclusively in tx have exactly same number, denomination, for input & output, and at least 2 inputs largest size coin used. Other clients, not care, may allow tx where take maybe some number coin at same address , but if so let make another standard size coin.

Easy for someone to figure out what's going on when there's an input that's 3.88 BTC, an output that's 3 BTC, and an output that's .88 BTC.

Much less easy when there are 3 inputs of 1 BTC, 3 inputs of .25 BTC, 2 inputs of .05 BTC, and 3 inputs of 0.1 BTC, and output is exactly the same number and size of coins. No way to know which is change going back to buyer. No way to know which inputs & outputs represent buyer, which seller. Maybe seller has inputs too, and is making change Not even a way to know if the thing somebody bought cost 0.5 BTC or 3 BTC or 3.5 BTC, etc. Every address used have one coin, every address paid to have one coin.

Trades in 'bullion' (arbitrary N-digit denominations) still possible, maybe not 'standard', or may require small 'minting fee'. But also possible exchange 'bullion' for 'minted coin' of standard denominations, down to level of negligible dust award for miners. Not even possible when watching to tell difference between someone changing own 'bullion' for goods with merchant take 'minted coin' and getting 'minted coin' change, from someone just changing own bullion for minted coin.

Makes 'coinjoin' privacy by default. Money go through a few ordinary trades under new rules, specially trades with or by privacy enforcing clients, no longer possible tell who own which. Is soft fork only; all tx legal under new rules also legal under old. Takes no 'mixing' as such or 'mixers.' Requires trust no extra party. Implementation simple and easy make secure.

I would prefer mixing arbitrary values of BTC. Ideally, the adversary should not be able to distinguish on-purpose mixing transaction from normal multiple input/multiple output transactions.

That's why I would like to do the mixing kind of automatically, from the queue of transactions to be mined.

If there are signed transactions A1+A2->X1+X2 from one user, B1->Y1+Y2 from other, etc., 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. It may look like double spend, but this could be solved using special "propose transaction" message instead of "broadcast transaction".

Thus, the Bitcoin transfers of users, who do not know each other, will be, kinda automatically (think of "offer for mixing" checkbox in Bitcoin-QT) mixed together by the network prior to be mined. Could save some blockchain space, too.

That's a neat idea (mixing large transactions) but unfortunately I cannot see how it could be implemented. When signing an input we sign a hash of the outputs, and thus adding new outputs will require to re-sign the transaction (as you already stated).

So, the transaction must go back and fort (in order to resign it each time an output is added) and the miner becomes essentially the rendez-vous server.

That's a neat idea (mixing large transactions) but unfortunately I cannot see how it could be implemented. When signing an input we sign a hash of the outputs, and thus adding new outputs will require to re-sign the transaction (as you already stated). So, the transaction must go back and fort (in order to resign it each time an output is added) and the miner becomes essentially the rendez-vous server.

That isn't the case, and if you see the "taint rich (https://bitcointalk.org/index.php?topic=139581.0)" link in the post, you can see I went and performed these transactions with people with no back and forth, there is a single round trip: I offer inputs and outputs, you respond with inputs and outputs and your signature, I then add my signature. If you'd like we can do one together too.

My main motivation in creating that long writeup was correcting that misconception. For SIGHASH_ALL these can be accomplished by simply agreeing on the outputs before any signing begins. (Obviously things are even simpler with SIGHASH_SINGLE, but that doesn't have the desirable privacy properties).

I tried pretty hard a couple years ago to get pools to round up their payments to non-jagged numbers like 0.01, because the highly jagged outputs they produce are bad for privacy and produce more bloaty change... and had absolutely zero luck. I am not anticipating great success on any kind of denominationalizing bitcoin. Maybe if the block explorers that give the misleading "account" view go away and people use more clients that show a more accurate "coin" view people will start to care more about the denomination of the coins they receive.

I tried pretty hard a couple years ago to get pools to round up their payments to non-jagged numbers like 0.01, because the highly jagged outputs they produce are bad for privacy and produce more bloaty change... and had absolutely zero luck.

Interesting. I had not thought about the privacy implications of the jagged numbers, just the bloaty change part.

outputs: a) A different address of him (X BTC) b) You address (with 1 BTC)

- This transaction is signed and sent back to you (cited: "via PM, anonymous gpg encrypted email, or a post in this thread") (second transmission).

- You sign this transaction and announce it (third transmission)

Or, in other words, in order to agree on the outputs, we need to have a rdv server (either an IRC server, a Forum -as in your thread-, a P2P network, etc.). We cannot avoid playing ping-pong with the transactions (I have nothing against it. In fact I proposed a detailed specification some post above).

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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 :)

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

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 (http://webmasters.stackexchange.com/questions/8525/how-to-open-the-javascript-console-in-different-browsers/8555#8555).

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.

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.jsServer status can be viewed while testing at: https://api.sharedcoin.com/

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.

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 (https://bitcointalk.org/index.php?topic=321228) 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.

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.

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.

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund (https://bitcointalk.org/index.php?topic=291283.0) 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).

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.

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund (https://bitcointalk.org/index.php?topic=291283.0) 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.

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 (https://bitcointalk.org/index.php?topic=291283.0) 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.

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.

I replied (https://bitcointalk.org/index.php?topic=291283.msg3146796#msg3146796) 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 (https://bitcointalk.org/index.php?topic=279249.msg3041593#msg3041593) 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.

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.

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.

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.

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.

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.

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

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?

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

Way to go piuk! It's a centralised effort but it's better to have a centralised coinjoin than no coinjoin at all.

I totally agree. However I think it should be made transparent that with this solution, the facilitator can map inputs to outputs easily and you have to trust him with retaining your own personal privacy.

One question piuk: does your servers in any way store records that would allow this mapping to be conducted by some entity gaining access to your databases?

One question piuk: does your servers in any way store records that would allow this mapping to be conducted by some entity gaining access to your databases?

You should never asks this question of any service.

Why? Because the answer you receive doesn't matter because you have no way to independently to verify the truth of a response.

A dishonest operator can lie.

An honest operator might not start out keeping logs, but could be ordered to do so and forbidden from telling you the truth via the threat of going to jail.

An honest operator might not realize they are keeping logs because their system has been compromised.

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

I hate to do this (in fact it might be the first time I actually have) but:

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

piuk, and my, point is that decentralized P2P systems with anonymous counterparties aren't necessarily any better because you can't know if your counterparties to the coinjoin are the NSA/FBI/whatever.

At least with a central service if they are honest you're well protected. With P2P stuff every transaction you make may or may not be deanonymized.

Best to use both if you really need to be able to count on the privacy... and hopefully someone will come up with a off-chain transfer system on some Tor site that implements chaum tokens.

piuk, and my, point is that decentralized P2P systems with anonymous counterparties aren't necessarily any better because you can't know if your counterparties to the coinjoin are the NSA/FBI/whatever.

It turns into a numbers game. If x% of the participants are evil, then you need to mix 1/x times.

Actually it is doing something - providing a type of plausible deniability.

Suppose CoinJoin transactions become a frequent occurrence in the blockchain. I can now spend funds from my wallet using transactions that appear to be CoinJoins, but are actually only my funds. I might only need to use "real" CoinJoin transactions some small percentage of the time.

One question piuk: does your servers in any way store records that would allow this mapping to be conducted by some entity gaining access to your databases?

You should never asks this question of any service.

Why? Because the answer you receive doesn't matter because you have no way to independently to verify the truth of a response.

A dishonest operator can lie.

An honest operator might not start out keeping logs, but could be ordered to do so and forbidden from telling you the truth via the threat of going to jail.

An honest operator might not realize they are keeping logs because their system has been compromised.

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

There's the possiblity he will just say: yes, we keep logs. In that case the question would've made sense.

Actually it is doing something - providing a type of plausible deniability.

Suppose CoinJoin transactions become a frequent occurrence in the blockchain. I can now spend funds from my wallet using transactions that appear to be CoinJoins, but are actually only my funds. I might only need to use "real" CoinJoin transactions some small percentage of the time.

Exactly.

There's this huge upside to widespread use of coinjoin transactions (no matter how they've been assembled) in general (even affecting people that don't ever use coinjoin), because it torpedoes the assumption that all inputs of a transaction are owned by a single entity that can currently pretty reliably be used to cluster addresses, which is the most common (valid) argument used when arguing that bitcoin isn't as private as many think.

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.

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.

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.

how did we solve this with bitcoin? you could solve it here the exact same way. have the facilitators be the 6 most recent miners to contribute new blocks to the blockchain. or atleast the 6 most recent who agree to provide the service.

Anon136, there is no need to reduce the set of facilitators in any way, even by distributed consensus. But miners could certainly publish lists of perceived reliable facilitators in their blocks, helping others to find them. There's a proposal along these lines for peer lists that is currently circulating the development mailing list.

Anon136, there is no need to reduce the set of facilitators in any way, even by distributed consensus. But miners could certainly publish lists of perceived reliable facilitators in their blocks, helping others to find them. There's a proposal along these lines for peer lists that is currently circulating the development mailing list.

what if the majority of the facilitators were actually a single malicious actor using multiple ip exit nodes? have you devised a mechanism for preventing him from being able to deduce information about transactions in this manner? or have you devised an alternative mechanism for insuring that no such actor is ever able to gain that much influence?

*tangent warning* blind signatures are amazing. some people talk about how the future will be saved from tyranny through peaceful parenting. others through the political system. some through revolution. but my money is on the efforts of people like yourself and gmaxwell. idk if you ever stop to think about this, but just the hand full of you guys working on these sorts of technologies might be responsible for saving the entire human species from extinction or worse. i know that sounds dramatic but i really think its hard to overstate the importance of this sort of research.

*tangent warning* blind signatures are amazing. some people talk about how the future will be saved from tyranny through peaceful parenting. others through the political system. some through revolution. but my money is on the efforts of people like yourself and gmaxwell. idk if you ever stop to think about this, but just the hand full of you guys working on these sorts of technologies might be responsible for saving the entire human species from extinction or worse. i know that sounds dramatic but i really think its hard to overstate the importance of this sort of research.

justusranvier, I'm not sure I follow. Mixing is only occurring within a single transaction. Within that transaction, some subset of the outputs must be same-sized. But I do not think there is any reason that all transactions must use the same (set of) output sizes...

justusranvier, I'm not sure I follow. Mixing is only occurring within a single transaction. Within that transaction, some subset of the outputs must be same-sized. But I do not think there is any reason that all transactions must use the same (set of) output sizes...

If there's only one solution to the question of "which combinations of inputs add up to the individual output values" then the mixing isn't effective.

If I put in 5.2543 BTC worth of inputs and you put in 2.6098 BTC worth of inputs and we create a Coinjoin transaction it's possible for there to be only one combination of inputs which add up to each output. In that case the mixing could be trivially reversed, unless I'm missing something fundamental about CoinJoin.

One way I can see to avoid that is a convention where outputs are always a standard size (integer powers of two, for example).

I like this idea, although enforcing it network-wide might have other implications (or maybe not, I'm not sure). A script could be written to easily condense a users outputs prior to a CJ tx, so gmaxwell's original design can be followed:

Quote

To use this to increase privacy, the N users would agree on a uniform output size and provide inputs amounting to at least that size.

I think Peter Todd wrote something that cleans out dust, you could just rework that to accomplish the above methinks.

Even when the inputs can be trivially separated, a party trying to do automated analysis still gets their taint tracking degraded by widespread CJ usage since they won't be able to assume cases where two separable inputs happened was an indication that the two inputs were owned by the same party. Obviously, perfect output indistinguishably is best, but even when the outputs are fully distinguishable (and everywhere in between) there is value too.

In other news, there is a Bitcoin-QT issue for this now: https://github.com/bitcoin/bitcoin/issues/3226

I am thinking if we should conduct some field tests: get some people to use Coinjoin, and publish their transactions, others will employ every method they can come up with to try to determine which address has sent to which.

How do you stop the greenlisting authority from saying to you "that's a suspiciously high porportion of multi-output transactions going to your green address, BANNED"?

How do you stop the greenlisting authority from contacting the blacklisting authority and saying to them "Caught another one. Blacklist all these addresses from these transactions. Still remaining unpsent inputs? Too bad."?

I don't reuse addresses. I was proposing a hypothetical situation. Greenlisting schemes suppose that everyone will be happy to reuse one address that is linked to a real world identity. Get with the program.

Obviously, perfect output indistinguishably is best, but even when the outputs are fully distinguishable (and everywhere in between) there is value too.

Why not right now encourage a standard that will more often result in the superior case?

I'm not particularly thrilled with merely degrading taint calculations when analytic capability is only going to improve over time.

I'm not really sure I follow. From my analysis there is zero benefit to mandating common output sizes across multiple transactions. gmaxwell, am I mistaken?

Consider a hypothetical CoinJoin transaction with several inputs and two outputs, A and B.

Output A is 5.21875 BTC and Output B is 3.4375.

In order for an attacker to break the mixing he must answer the question, "which combination of inputs add up to each output", and that question could likely have only one solution. If there is only one solution, the mixing has no value other than forcing the attacker to spend a bit of CPU power on it.

If the participants in the mix instead choose to only use integer powers of 2, they can break their desired outputs down like this:

Apparently people are plotting behind the scenes to put whitelisting, blacklisting and redlisting (https://bitcointalk.org/index.php?topic=333824.0) and other terrible ideas into Bitcoin.

Perhaps we should seriously speed up initiatives like CoinJoin, CoinSwap and CoinControl so people start massively mixing coins and make such efforts unfeasible.

This assumes that you opt-in to the listing with your real world ID, then obscure the source of your funds with anonymity schemes as you've denoted. But with CoinJoin, this could get you banned from the listings people, and potentially get all the CoinJoiners you collaborated with blacklisted too.

I think the best way is to encourage miners to ban the clean addresses from tx processing. If that doesn't succeed, use or develop another coin.

Apparently people are plotting behind the scenes to put whitelisting, blacklisting and redlisting (https://bitcointalk.org/index.php?topic=333824.0) and other terrible ideas into Bitcoin.

Perhaps we should seriously speed up initiatives like CoinJoin, CoinSwap and CoinControl so people start massively mixing coins and make such efforts unfeasible.

This assumes that you opt-in to the listing with your real world ID, then obscure the source of your funds with anonymity schemes as you've denoted. But with CoinJoin, this could get you banned from the listings people, and potentially get all the CoinJoiners you collaborated with blacklisted too.

I think the best way is to encourage miners to ban the clean addresses from tx processing. If that doesn't succeed, use or develop another coin.

Another option is to make CoinJoin/CoinSwap really popular. Perhaps make the client suggest mixing like by adding "mix coins with other's users coin" checkbox in the send coins GUI.

This way regulators will have no other way than to accept Bitcoin the way it is - mixed and untraceable.

Another option is to make CoinJoin/CoinSwap really popular. Perhaps make the client suggest mixing like by adding "mix coins with other's users coin" checkbox in the send coins GUI.

This way regulators will have no other way than to accept Bitcoin the way it is - mixed and untraceable.

More difficult to popularise anonymising features than it is to find out what colour the biggest miners like their address lists. If they want the lists transparent, instead of red, black blue green or white, then they should prefer to ban any such coloured listed addresses from their transaction inclusions.

Let's push to hit these lists right at their fundamentals, make them undesirable and unusable, not the other way around.

Perhaps we should seriously speed up initiatives like CoinJoin, CoinSwap and CoinControl so people start massively mixing coins and make such efforts unfeasible.

And/or incorporating it into clients so people wouldn't have to bother. E.g. I wouldn't mind to spend a millibit a week in network fees just to have my coins periodically mixed.

Exactly what I am talking about.

We must make coin mixing almost as common as sending them. This way governments will have no choice but face the reality.

I think there are too many compliant goody goodies out there for this to work. You only have to craft a well thought through smear campaign against anonymising and most people will be too anxious to rebel against it, they will believe the nonsense is true.

There are fewer miners than users, and they are naturally determined risk takers. They are easier to convince of the drawbacks than average users, especially as they have probably got more BTC balance whose long term value and viability they wish to protect.

Consider a hypothetical CoinJoin transaction with several inputs and two outputs, A and B.

Output A is 5.21875 BTC and Output B is 3.4375.

...

The mixing application described in the OP uses same valued outputs for two reasons: (1) to avoid this sort of identification, and (2) to prevent the facilitator from learning identities through blind signatures. This requires that within a single transaction, the mixed outputs must have the same value denominations (or be divided into groups of same-valued denominations). The hypothetical given is a weaker protocol than the OP.

That said, there is no reason that the common denomination used by one transaction has to match or be a multiple of the common denomination of another - that gains you nothing as far as I can tell.

It's fine as an academic exercise but how people actually use their bitcoins in the real world is considerably more messy. Unless you can handle situations where the users need to mix differing amounts of coins you'll either degrade the mixing to uselessness or else end up with a double coincidence of wants problem where nobody can find suitable partners top mix with.

It's fine as an academic exercise but how people actually use their bitcoins in the real world is considerably more messy. Unless you can handle situations where the users need to mix differing amounts of coins you'll either degrade the mixing to uselessness or else end up with a double coincidence of wants problem where nobody can find suitable partners top mix with.

Yea, and to that effect there should be a step prior to the CJ where outputs are made uniform.

It's fine as an academic exercise but how people actually use their bitcoins in the real world is considerably more messy. Unless you can handle situations where the users need to mix differing amounts of coins you'll either degrade the mixing to uselessness or else end up with a double coincidence of wants problem where nobody can find suitable partners top mix with.

A decentralised approach would provide enough variety so that the number of people who have to compromise would decrease, but I agree that this harms the effectiveness of the anonymity of inputs. It would also be less easy to convince a nosy listing agency that you were settling several hundred payments in a single transaction... especially when several hundred other CoinJoin participants could be making the same claim to the very same transaction to the same agency. It's not possible that you're all the sole originator of the same transaction.

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

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

I agree so I just send ~$50 to donations https://blockchain.info/tx/37fa76c95c06c4f35ac4069a84d75a022275a80bd35a05e102c8f6ad4d02646d

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

IMHO we should motivate miners to operate liquid CoinJoin pools and pass all their new block rewards through it. Then integrate CoinJoin in as many clients as possible, for automatic or semi-automatic use. When everything is tainted, nothing is, and all list operators will look pretty stupid.

It's in the best interest of miners that bitcoins remain fungible long term, but some short sighted individual miners might object to getting slightly tainted coins. This could be offset by a small fee paid by CoinJoin users, and shared between pools and miners.

IMHO we should motivate miners to operate liquid CoinJoin pools and pass all their new block rewards through it. Then integrate CoinJoin in as many clients as possible, for automatic or semi-automatic use. When everything is tainted, nothing is, and all list operators will look pretty stupid.

It's in the best interest of miners that bitcoins remain fungible long term, but some short sighted individual miners might object to getting slightly tainted coins. This could be offset by a small fee paid by CoinJoin users, and shared between pools and miners.

I tend to think that Coinjoin pools should be like Tor flashproxies, ephemeral, ad-hoc and untrackable.

Consider a hypothetical CoinJoin transaction with several inputs and two outputs, A and B.

Output A is 5.21875 BTC and Output B is 3.4375.

In order for an attacker to break the mixing he must answer the question, "which combination of inputs add up to each output", and that question could likely have only one solution. If there is only one solution, the mixing has no value other than forcing the attacker to spend a bit of CPU power on it.

If the participants in the mix instead choose to only use integer powers of 2, they can break their desired outputs down like this:

The downside is there's somewhat more risk of analysis matching inputs to outputs, but I would think the increased risk is very slight.

Among the benefits is that the math is simpler, allowing other ideas to be easily implemented (such as a cutoff value: everything under 0.000x BTC is lumped into one output. If a small, random transaction fee is also included, this avoids dust outputs but is still resistant to analysis.)

For example, your above outputs, after removing small transactions fees, might break down to

Almost all of the privacy, and the coins are less noticeable (as opposed to values like 0.03125 BTC) even just sitting in the wallet. And this would be a much better result too for those of us managing coins in paper wallets who need to determine how many change addresses to grab to spend X bitcoins.

Among the benefits is that the math is simpler, allowing other ideas to be easily implemented (such as a cutoff value: everything under 0.000x BTC is lumped into one output. If a small, random transaction fee is also included, this avoids dust outputs but is still resistant to analysis.)

If outputs are in the form of Xn, then you can easily implement a cutoff by specifying a minimum value for n. Leftovers just get added to the transaction fee.

I really don't care if there is a recommended standard of X=2, or X=5, or if an explicit negotiation step is added to the protocol to choose a value for X, just as long as there's some way to do it that actually gets implemented.

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.

Way to go!

I'm upping my offer from 0.50 to 0.75 but please tell Pieter to sign his pubkey in the second message of this thread.

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

Ok so most of this goes way over my head of understanding, so can someone just tell me. Using such a system as this, if I make a payment to an address, does the receiver still see my address as the address the payment came from, or do they receive the correct amount of Bitcoins, but from some other unknown address?

CoinJoin is like collecting 20 of 100 USD bills into a hat and then passing the hat to another group of 20 people, each one takes its 100 USD bill. Noone knows who gives you which bill.

Ah ok, so this would basically be useless for any kind of eCommerce, or paying in restaurant with bitcoins etc because they wouldn't know who paid for it. I sincerely hope this would then be an optional way of transferring rather than a replacement right?, otherwise it would pretty much destroy Bitcoin as a means for paying for goods.

CoinJoin is like collecting 20 of 100 USD bills into a hat and then passing the hat to another group of 20 people, each one takes its 100 USD bill. Noone knows who gives you which bill.

Ah ok, so this would basically be useless for any kind of eCommerce, or paying in restaurant with bitcoins etc because they wouldn't know who paid for it. I sincerely hope this would then be an optional way of transferring rather than a replacement right?, otherwise it would pretty much destroy Bitcoin as a means for paying for goods.

The merchant doesn't need to know who paid because every time they issue a bill they use a brand new address. Forget address reuse

If we can get this onto the front page of r/bitcoin I think we could get some decent coin.

Also, I'm getting a report of a problem sending coin to the address. I originally tried to use the reddit bitcoin tip bot to send it, but kept getting rejected. I eventually just used Coinbase. Now someone is commenting saying that bitcoin tip bot, Mt. Gox, and even Armory all rejected their attempts to send coin.

Here is the Armory error: "You have entered 1 invalid addresses. The errors have been highlighted on the entry screen."

Does anyone have any idea why that would be happening?

EDIT: The commenter just posted the Mt Gox error: "This address is not on the right network"

Ah ok, so this would basically be useless for any kind of eCommerce, or paying in restaurant with bitcoins etc because they wouldn't know who paid for it. I sincerely hope this would then be an optional way of transferring rather than a replacement right?, otherwise it would pretty much destroy Bitcoin as a means for paying for goods.

No, you have a misunderstanding of how bitcoin works. There is no "from" address. A merchant knows when they've been paid because they receive payment to a one-time-use address they generated specifically for the transaction. The way this would work in CoinJoin is that you pretend that you are mixing X coins, where X is the amount that you are paying the merchant, and then use the key id provided by the merchant for your blinded output.

And yes, this is a PURELY higher-level protocol that makes no changes to how bitcoin currently operates.

This does sound great. But I'm not sure I understand how this helps the Blacklist/Whitelist issue. If TPTB still make some kind of Whitelist where merchants are only allowed to accept coins from certain "white" addresses, what does something like CoinJoin offer against that?

This does sound great. But I'm not sure I understand how this helps the Blacklist/Whitelist issue. If TPTB still make some kind of Whitelist where merchants are only allowed to accept coins from certain "white" addresses, what does something like CoinJoin offer against that?

Address re-use is being actively discouraged now. Once this becomes the norm then whitelists will be irrelevant.

In what way is it being discouraged? Is it anything beyond informing people that it's bad practice? I'd like to see some anti-address-reuse measure become baseline, maybe even in the protocol itself if possible. Does CoinJoin have anything to do with address reuse then?

In what way is it being discouraged? Is it anything beyond informing people that it's bad practice? I'd like to see some anti-address-reuse measure become baseline, maybe even in the protocol itself if possible. Does CoinJoin have anything to do with address reuse then?

https://bitcointalk.org/index.php?topic=334316.0

This might be a premature decision, and only is effective per block, but hopefully the side-effect is faster adoption of BIP32

Awesome. Thanks for the information. That seems like a great idea putting that on the miners.

I have another question, I've asked this before but I don't quite understand why it wouldn't work. Couldn't the protocol be changed so that once an address is spent, it also becomes invalid? That way someone couldn't use an address to pay for something more than once, but he could still receive any number of incoming transactions to it before he decides to spend it. Transactions going to an invalid address would just not be accepted by miners and thus bounced back. This would mean that any attempts to whitelist addresses would be moot because an address disappears after use. What am I missing? Wouldn't this work?

Awesome. Thanks for the information. That seems like a great idea putting that on the miners.

I have another question, I've asked this before but I don't quite understand why it wouldn't work. Couldn't the protocol be changed so that once an address is spent, it also becomes invalid? ... What am I missing? Wouldn't this work?

The place for this is in wallet software, not the protocol. There should still be freedom of choice where someone who loves their vanity address more than their privacy can still use it (send from it) as long as they like.

I'd like it if someone could address a concern I raised in another thread, but is relevant to mention here:

The outputs of a CoinJoin transaction will have an amount of red taint equal to the amount of red taint on the inputs. So basically half of the participants will get cleaner coins and half will get dirtier coins. There is no net reduction in red taint.

Unless you are assuming that number-of-hops somehow makes your redcoins less red, but I don't believe this to be the case. The redness factor is really about the source transactions that lead into your transaction, and if a high % of those are red then your coins are tainted.

What incentive is there for clean coins to participate in CoinJoin? Wouldn't it tend to be the case that CoinJoin inputs are all quite red?

What incentive is there for clean coins to participate in CoinJoin? Wouldn't it tend to be the case that CoinJoin inputs are all quite red?

Because the whole concept of "red" to begin with is a human imposed concept which is senseless in a world where people are widely and casually using coinjoin. This is why its important that it be made as easy and as cheap as possible, because its not really useful to anyone unless its usable by everyone.

I'd like it if someone could address a concern I raised in another thread, but is relevant to mention here:

The outputs of a CoinJoin transaction will have an amount of red taint equal to the amount of red taint on the inputs. So basically half of the participants will get cleaner coins and half will get dirtier coins. There is no net reduction in red taint.

Unless you are assuming that number-of-hops somehow makes your redcoins less red, but I don't believe this to be the case. The redness factor is really about the source transactions that lead into your transaction, and if a high % of those are red then your coins are tainted.

What incentive is there for clean coins to participate in CoinJoin? Wouldn't it tend to be the case that CoinJoin inputs are all quite red?

If you are a Bitcoin investor, then you really should give a damn about Coinjoin. Destroying its fungibility would allow Wall Street's money masters to separate Bitcoin into assets of different sorts, like "good bitcoins" and "bad bitcoins", and manipulate their values while giving themselves unfair advantages like they have always been doing(e.g., with gold). The bitcoins they control will obviously be A+ grade, and yours may become entirely worthless someday even if you just hoard them and do nothing, to ensure your asset doesn't get depreciated is a pretty big incentive I guess.

I'd like it if someone could address a concern I raised in another thread, but is relevant to mention here:

The outputs of a CoinJoin transaction will have an amount of red taint equal to the amount of red taint on the inputs. So basically half of the participants will get cleaner coins and half will get dirtier coins. There is no net reduction in red taint.

Unless you are assuming that number-of-hops somehow makes your redcoins less red, but I don't believe this to be the case. The redness factor is really about the source transactions that lead into your transaction, and if a high % of those are red then your coins are tainted.

What incentive is there for clean coins to participate in CoinJoin? Wouldn't it tend to be the case that CoinJoin inputs are all quite red?

If you are a Bitcoin investor, then you really should give a damn about Coinjoin. Destroying its fungibility would allow Wall Street's money masters to separate Bitcoin into assets of different sorts, like "good bitcoins" and "bad bitcoins", and manipulate their values while giving themselves unfair advantages like they have always been doing(e.g., with gold). The bitcoins they control will obviously be A+ grade, and yours may become entirely worthless someday even if you just hoard them and do nothing, to ensure your asset doesn't get depreciated is a pretty big incentive I guess.

Exactly. Redlisting will turn into blacklisting and it will turn into whitelisting if not stopped.

I dont understand the advantage of using tor. unless of course you wanted to, in addition to hiding information about your transaction, actually hide the fact that you are participating in the bitcoin system entirely. Wouldn't the coinjoin facilitator just publish a public key that all other participants could use to encrypt their transaction?

I dont understand the advantage of using tor. unless of course you wanted to, in addition to hiding information about your transaction, actually hide the fact that you are participating in the bitcoin system entirely. Wouldn't the coinjoin facilitator just publish a public key that all other participants could use to encrypt their transaction?

If you don't use tor (or another similar network) then the peers you're talking to could record your IP, which you presumably want to keep private too. I mostly pointed it out to head off comments like "OMG YOUR PEERS CAN RECORD YOUR IP!" ... yes, they can, other things fix that. This is intended to address privacy in the blockchain. :)

Figuring out how to construct CoinJoin transactions is just the first step in having a usable system.

The rest of the work is the nuts and bolts of how users actually find suitable mixing partners.

Based on how users are likely going to want to employ CoinJoin, there are going to be two general classes of clients:

Opportunistic clients which are configured to wait for suitable conditions and perform mixing in the background. These will necessarily be clients where the private keys are stored on a online machine. Mixing is not time sensitive at all for them.

Immediate clients who want to use a CoinJoin transaction to send bitcoins. They need to be able to complete the protocol quickly, within a few seconds, because they using an Armory-style offline wallet where they need to save an unsigned transaction to a suitable medium, cross the air gap, sign the transaction, and broadcast it all before the BitPay timer runs out.

In order for the immediate clients to be able to operate, you need a lot of opportunistic clients. Also, some of the opportunistic clients will be FBI honeypots, so there's that too.

Right off the bat, a CoinJoin negotiation protocol should be work over Tor. The TorChat (https://github.com/prof7bit/TorChat) system is a good model for this - they actually bundle a Tor binary directly into their application so that a TorChat user doesn't need to download, install, and configure Tor separately. They also use the hidden service URL as a user name, which means you don't need some additional name mapping system.

It's too bad the Tor project hasn't separated their core functionality library into a library that could be used by third-party applications, despite repeated calls to do so (https://www.google.com/#q=embed+tor+into+other+application).

Perhaps CoinJoin clients could just work through the libpurple plugin for TorChat.

Once the clients all meet up, they need a way to negotiate parameters like output sizes. If an immediate client wants to use CoinJoin for a purchase, it's not likely that any other immediate clients are going to have the exact same output size needs, so they'll have to rely on opportunistic clients who have specified a compatible range of acceptable output sizes.

tl;dr: Clients need a protocol by which they can register their willingness to participate in a CoinJoin, and any relevant constraints which determine who is and is not a suitable partner, over a secure channel (because even though you might theoretically do it in the clear, people who want CoinJoin are also going to want to have IP address-level privacy too).

I dont understand the advantage of using tor. unless of course you wanted to, in addition to hiding information about your transaction, actually hide the fact that you are participating in the bitcoin system entirely. Wouldn't the coinjoin facilitator just publish a public key that all other participants could use to encrypt their transaction?

If you don't use tor (or another similar network) then the peers you're talking to could record your IP, which you presumably want to keep private too. I mostly pointed it out to head off comments like "OMG YOUR PEERS CAN RECORD YOUR IP!" ... yes, they can, other things fix that. This is intended to address privacy in the blockchain. :)

Supposing you did nothing to obfuscate your ip, would the peers you are talking to have any means by which to link your ip address to the outputs of the transactions that belonged to you? or would they simply be recording the fact that your ip address participated in that particular coinJoin session?

The idea can also be used more casually. When you want to make a payment, find someone else who also wants to make a payment and make a joint payment together.

This thread is so big. Could anyone, who managed to read it, tell me what prevents CIA/FBI/MI6 from taking part in most of such transactions? This would let them to "break" privacy, coz they know which inputs and outputs r their own. Bitcoin network is already flooded with a lot of "spying" nodes, the same approach can be used against CoinJoin.

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

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

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

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

Pretty embarrassing that the Bitcoin ecosystem can't keep up with a couple year old feature. It's not the only thing, some websites will, electrum will, the SX tools will. But armory, nothing bitcoinj based, or blockchain.info will.

It's a real bummer because I think that using a multi-signature escrow is the right and proper thing to do here. I don't think I should personally be holding money set aside for this— my computer security is good, but I think no single person should be entrusted with holding non-trivial amounts of other folks money. How many bitcoins have been stolen that could have been avoided if the norm was to use in blockchain escrows for things, but people didn't because of silly wallet compatibility? :( (And perhaps people will understand that I'm really not being a rabid bitcoin-qt advocate when I say that I'm not super eager to see lots of alternative implementations, they really do complicate the ecosystem and make new features harder for people to use) [/OT]

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.

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.

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.

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.

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.

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

Pretty embarrassing that the Bitcoin ecosystem can't keep up with a couple year old feature. It's not the only thing, some websites will, electrum will, the SX tools will. But armory, nothing bitcoinj based, or blockchain.info will.

It's a real bummer because I think that using a multi-signature escrow is the right and proper thing to do here. I don't think I should personally be holding money set aside for this— my computer security is good, but I think no single person should be entrusted with holding non-trivial amounts of other folks money. How many bitcoins have been stolen that could have been avoided if the norm was to use in blockchain escrows for things, but people didn't because of silly wallet compatibility? :( (And perhaps people will understand that I'm really not being a rabid bitcoin-qt advocate when I say that I'm not super eager to see lots of alternative implementations, they really do complicate the ecosystem and make new features harder for people to use) [/OT]

Besides, I haven't seen a Coinjoin implementation supporting it! So instead of sending donations to the fund address I send to your personal donation address.

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.

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

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:

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:

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

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.

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.

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 (https://bitcointalk.org/index.php?topic=321228)" 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.

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.

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 (https://bitcointalk.org/index.php?topic=321228)" 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.

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.

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 (https://bitcointalk.org/index.php?topic=321228)" 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...

[...]

Now I had a look at CoinSwap. Nice! I was not aware of a concept like these "hash-locked" transactions.

I am wondering whether it is possible to combine the CoinSwap and CoinJoin concepts. Idea (Ex. N=3 again):

Contrary to normal CoinJoin, taint is really removed instead of just "hidden".

A CoinSwap-like protocol would have to be defined to make sure that no funds can be embezzled (via hash-locked techniques?), and that no connections between the two CJ transactions can be made from the outside observer. And hopefully, it can be done in a way that there's not a "single-point-of privacy-leak" like in CoinSwap where "Carol can tell about Alice".

I am stopping here, because I did not understand CoinSwap to the last detail yet, but I have the feeling that such combined mechanism could be possible and trying to inspire...

Furthermore, remember that in CoinJoin all outputs have the same size. So in this case one output is 1.5 BTC to 1Friend, so the other two outputs (going to new addresses of Person A himself) each have 1.5 BTC too. So the sum of all inputs must be at least 4.5 BTC. So Person A must have at lest 4.5 BTC in his wallet although he just wants to transfer 1.5 BTC to 1Friend.

Good point. However outputs don't have to be the same value but could be among a set of values. And with the advent of HD wallets, I could ask my friend for an extended pubkey so I could generate as many addresses of them as I wanted, and I would set up the outputs of the CJ accordingly. For example if the outputs must be powers of two between 2^16 and 2^32 satoshis, I could roughly fit 1.5 BTC into that. (2^27 + 2^23 + 2^22 + 2^21 + 2^20) / 1e8 = 1.49946368.

I appreciate the thought here with coinjoin, but the fact remains that people need to actually use it, and then people need to actually pay (transaction fees) for it.

Honestly, I don't think they will. If the manager of a sandwich shop spends 1/10 of 1% of his receipts on coinjoin transactions, he's going to get fired. If you ask naive user Joe whether he's willing to spend an extra fifty cents for some abstract thing like privacy on a legitimate $500 transaction, he's going to say no because he doesn't care enough in the immediate case.

If you want privacy, then you need to fix the protocol so that *EVERY* transaction is a mix, and people *DON'T* have to pay extra for mixing.

My thought on this is that the clients need to prefer producing outputs in "standard" coin sizes (to separate output addresses) such as [1 | 2.5 | 5] * 10^N - for ALL outputs including change - and that whenever possible *both* sides of a transaction need to be providing inputs that add up to at least twice the amount of money that's actually required to change hands.

'Coz honestly, it doesn't matter how good your coinjoin design is if people still have to pay tx fees to use it, because they won't.

It seems to me that you can cut down the chances of a CoinJoin being participated in by snoopy spying agencies by choosing low numbers of participants and doing numerous/frequent CoinJoins (and accepting the increased fees you pay as a cost of keeping your holdings private).

And when I say low numbers of participants, it also seems there is an option to choose to CoinJoin entirely with inputs and outputs of addresses that only belong to you. How could someone analysing the blockchain prove they were not trying to disentangle the identities of what would in effect be a spoofed CoinJoin? I'm not sure that they could.

And when I say low numbers of participants, it also seems there is an option to choose to CoinJoin entirely with inputs and outputs of addresses that only belong to you. How could someone analysing the blockchain prove they were not trying to disentangle the identities of what would in effect be a spoofed CoinJoin? I'm not sure that they could.

Normal transactions do this all the time (ignoring creating faux-anonymous output values), but today people assume common use means common ownership. Part of the advantage of CoinJoin is that if widely used it breaks the ability to assume that, recovering some privacy for everyone.

I just realized CoinJoin is actually an effective scaling tool; no longer would we have to increase the block size to handle more tx/s. Just bundle them in CoinJoin txs.

it only helps a little bit because it only saves the need to store some of the transaction headers. As far as the information inside of the body is concerned, you still have just as many inputs and outputs, its just as much data to be stored on the blockchain.

I just realized CoinJoin is actually an effective scaling tool; no longer would we have to increase the block size to handle more tx/s. Just bundle them in CoinJoin txs.

it only helps a little bit because it only saves the need to store some of the transaction headers. As far as the information inside of the body is concerned, you still have just as many inputs and outputs, its just as much data to be stored on the blockchain.

Ah true.

Someone debunk this idea: SwapJoin

I know you can only add up to [I think] 10 sigs in a multi sig transaction, but could you build the escrow transactions in the CoinSwap protocol with CoinJoin properties? Or is that a gross misunderstanding of how it works.

it only helps a little bit because it only saves the need to store some of the transaction headers. As far as the information inside of the body is concerned, you still have just as many inputs and outputs, its just as much data to be stored on the blockchain.

It could help if it covered time too.

If A pays B and then B pays C, then the 2 transactions could be combined to give A pays C.

A pays C could have higher fee per kB than A pays B and B pays C, so it is worth it for a mining pool to combine them.

This could happen if the transaction pool started becoming a queue. At the moment, transactions mostly get into the chain.

If transactions stayed unconfirmed for a while, then you could end up with more opportunities to collapse the transactions. So, a longer queue makes the blockchain more efficient.

I just realized CoinJoin is actually an effective scaling tool; no longer would we have to increase the block size to handle more tx/s. Just bundle them in CoinJoin txs.

It could be used as a load balancing device for a system with a fixed block size limit. CoinJoins happen automatically to help compress more transactions into the available block space. This could provide a good argument against a scheme with a continuously variable block size, or to a scheme with no limit at all (although I don't think anyone has yet made any serious proposal for the latter)

It also illustrates that CoinJoin really is just that, joining inputs and outputs into single transactions, regardless of the utility you're seeking from doing so.

it only helps a little bit because it only saves the need to store some of the transaction headers. As far as the information inside of the body is concerned, you still have just as many inputs and outputs, its just as much data to be stored on the blockchain.

It could help if it covered time too.

If A pays B and then B pays C, then the 2 transactions could be combined to give A pays C.

A pays C could have higher fee per kB than A pays B and B pays C, so it is worth it for a mining pool to combine them.

This could happen if the transaction pool started becoming a queue. At the moment, transactions mostly get into the chain.

If transactions stayed unconfirmed for a while, then you could end up with more opportunities to collapse the transactions. So, a longer queue makes the blockchain more efficient.

A thought occurred to me this morning. Why are the blocks structured in such a way that you can tell in the first place which txins and txouts go with which transactions? By the time the block is found most peers have already seen the transactions that the block is composed of. We need a list of transactions, a list of txins, and a list of txouts. There's no need to give information in the block about which txins and txouts go with which transactions.

Those who have seen the transactions already know. So they can still check everything they've seen in the block. And the block structure doesn't need to make it easy to reconstruct the individual transactions. After the fact people can still check validity by treating a block the same way they treat a transaction now.

That makes coinjoin completely superfluous. And free. And the default for all transactions.

A thought occurred to me this morning. Why are the blocks structured in such a way that you can tell in the first place which txins and txouts go with which transactions? By the time the block is found most peers have already seen the transactions that the block is composed of. We need a list of transactions, a list of txins, and a list of txouts. There's no need to give information in the block about which txins and txouts go with which transactions.

Those who have seen the transactions already know. So they can still check everything they've seen in the block. And the block structure doesn't need to make it easy to reconstruct the individual transactions. After the fact people can still check validity by treating a block the same way they treat a transaction now.

That makes coinjoin completely superfluous. And free. And the default for all transactions.

Of course it's a hard fork. But it's worth it.

I've often wondered about variations along this line myself ... and also if some kind of homomorphic encryption might used to conceal tx details completely and yet still have verifiable blocks ?

I've often wondered about variations along this line myself ... and also if some kind of homomorphic encryption might used to conceal tx details completely and yet still have verifiable blocks ?

Adam had a whole thread on encrypted transactions (https://bitcointalk.org/index.php?topic=206303.0). Though without compact zero knoweldge proofs (like the stuff I discussed in the coinwitness thread) it's hard to make them not super brittle and inefficient, because anyone you pay has to receive and validate the whole decrypted history of a coin, since it can't be validated without the history.

If you had a zero knowledge proof that the transaction was valid (e.g. that all the outputs and inputs added up) which the network checked then you could accept the coin without re-verifying the history and, importantly, without revealing the history to the recipients. The trick is finding a system for zero knoweldge proofs which is powerful enough to prove the right things but fast and low bandwidth enough to actually use which doesn't have annoying limitations like requiring a trusted initialization.

I've often wondered about variations along this line myself ... and also if some kind of homomorphic encryption might used to conceal tx details completely and yet still have verifiable blocks ?

Adam had a whole thread on encrypted transactions (https://bitcointalk.org/index.php?topic=206303.0). Though without compact zero knowledge proofs (like the stuff I discussed in the coinwitness thread) it's hard to make them not super brittle and inefficient, because anyone you pay has to receive and validate the whole decrypted history of a coin, since it can't be validated without the history.

If you had a zero knowledge proof that the transaction was valid (e.g. that all the outputs and inputs added up) which the network checked then you could accept the coin without re-verifying the history and, importantly, without revealing the history to the recipients. The trick is finding a system for zero knowledge proofs which is powerful enough to prove the right things but fast and low bandwidth enough to actually use which doesn't have annoying limitations like requiring a trusted initialization.

Using the Benaloh homomorphic encryption system you can check that txins and txouts are equal without knowing anything about their real values. If you encrypt two bunches of numbers that add up to equal sums using Benaloh, the ciphertexts of those two bunches when interpreted as numbers have equal modular products.

Actually making the transactions using that system would require more compute power, on the order of an RSA encryption per txout. But checking it would require very little extra because modular multiplications are nearly as cheap on modern architectures as additions.

This would mean that tx fees have to be an explicit txout of the transaction, but we're talking about a hard fork anyway if we get that far.

Using the Benaloh homomorphic encryption system you can check that txins and txouts are equal without knowing anything about their real values. If you encrypt two bunches of numbers that add up to equal sums using Benaloh, the ciphertexts of those two bunches when interpreted as numbers have equal modular products.

Brainstorm: is there anyway to make fee payments anonymous as well? I figure that since on one hand some are concerned whether there will be enough unsuspected users to help them hiding the trail, otoh some are concerned about fees, it would be one stone for two birds if we can give some users the opportunity to have their fees paid by those willing, if they choose to do a Coinjoin transaction.

I have written a tool in Rust to make CoinJoining easier to do -- though it still requires creating and passing raw transactions. (I apologize for the weird language choice, but Rust is awesome. The first time the code compiled it worked correctly, that's just how good the static analysis is with this language.) Having said that, I have only done so much testing, so I encourage you guys to download and play with it:

https://github.com/apoelstra/coinjoin

Be aware that testing is perfectly safe -- no matter how badly my code mangles the transaction, any changes to the outputs will invalidate the signatures, so there is no additional risk of money loss from running the program. (On the other hand, make sure you verify every transaction you sign!)

From the README, there are two steps to using the program:

1. All parties who want to coinjoin create a raw transaction using createrawtransaction. They submit these to one individual, who enters them into CoinJoiner by running

./coinjoin-merge-unsigned

Then just copy/paste the transactions in, one on each line, followed by a blank line. The output will be an unsigned merged transaction.

2. This merged transaction is distributed to the original parties, who each sign it. Then they send these back to the individual running CoinJoiner, who merges them by running

./coinjoin-merge-signed

Then just copy/paste the signed transactions in, one on each line, followed by a blank line. The output will be a merged, signed transaction that is ready to be submitted to the bitcoin network.

1. All parties who want to coinjoin create a raw transaction using createrawtransaction. They submit these to one individual, who enters them into CoinJoiner by running

./coinjoin-merge-unsigned

Then just copy/paste the transactions in, one on each line, followed by a blank line. The output will be an unsigned merged transaction.

Interesting approach. This has some very nice advantages. For example, we could add a flag to sendtoaddress that makes it return the unsigned tx hex. Thus we take advantage of the coin selector built into the node, etc.

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.

Way to go!

I'm upping my offer from 0.50 to 0.75 but please tell Pieter to sign his pubkey in the second message of this thread.

Interesting approach. This has some very nice advantages. For example, we could add a flag to sendtoaddress that makes it return the unsigned tx hex. Thus we take advantage of the coin selector built into the node, etc.

It'd also need to mark the inputs as spent so that further transactions don't double-spend.This could be done using `lockunspent` but these are not saved when bitcoind is restarted.

Interesting approach. This has some very nice advantages. For example, we could add a flag to sendtoaddress that makes it return the unsigned tx hex. Thus we take advantage of the coin selector built into the node, etc.

It'd also need to mark the inputs as spent so that further transactions don't double-spend.This could be done using `lockunspent` but these are not saved when bitcoind is restarted.

If anyone knows how to make JSON-RPC calls through Rust (or C), I'd be able to (a) do my own 'sendtoaddress' equivalent, and (b) check for double-spends, excessive fees, negative fees, etc, and flag these as errors.

Right now I only check things intrinsic to the transactions -- for merge-unsigned, I ensure there are no duplicate inputs; for merge-signed, I ensure that all transactions are identical modulo scriptSigs.

It's not terribly important to do lockunspent -- if somebody double-spends, the coinjoin will be invalid. Presumably they wanted to do the coinjoin, so they've just screwed themselves. So any double-spend blocking is purely a usability feature.

Hey, um, stupid question, and I'm just too drowsy to wrap my head around it, but if I use CounJoin on blockchain.info, where I have one input and one output, and sent 5 BTC through, with 5 BTC coming out on the other end, isn't it still fairly easy to track my 5 BTC,simply because that's the amount that went in and came out?

if I use CounJoin on blockchain.info, where I have one input and one output

If you only have one input, you're not joining any coins. The point is mixing unspent outputs from several people/addresses so external observers can't figure out where each output has gone.

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

if I use CounJoin on blockchain.info, where I have one input and one output

If you only have one input, you're not joining any coins. The point is mixing unspent outputs from several people/addresses so external observers can't figure out where each output has gone.

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

The possibility that you could get 5 BTC sent to more than one address. Also, you could use the system to pay people too. So, you get your 5 BTC sent to 4 adddresess that belong to you, and the small fraction you are paying to someone else goes to their address. To the outside observer, do all 5 addresses belong to the original holder? Do they all belong to someone receiving a total of 5 BTC from the original holder? Or somewhere inbetween? Impossible to tell, and so analysing the transaction leaves you with lots of questions and no answers.

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

You don't re-assemble them into the original amounts. Why would you want to do that?

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

You don't re-assemble them into the original amounts. Why would you want to do that?

That's what Blockchain.info does. You send from a single address, you give it an amount and a destination address, and it goes through 2+ CoinJoin steps, split up into random amounts from your source address, then after all the steps gets recombined into the amount you sent (minus transaction fee) into your destination address. Basically, it's as if your amount is exploded into random chunks, and then recombined into the same amount. Unless multiple steps involve multiple different coinjoiners, and much of what you get isn't tied to your own bitcoin at all, I'm not sure it's secure.

That's what Blockchain.info does. You send from a single address, you give it an amount and a destination address, and it goes through 2+ CoinJoin steps, split up into random amounts from your source address, then after all the steps gets recombined into the amount you sent (minus transaction fee) into your destination address. Basically, it's as if your amount is exploded into random chunks, and then recombined into the same amount. Unless multiple steps involve multiple different coinjoiners, and much of what you get isn't tied to your own bitcoin at all, I'm not sure it's secure.

Assuming you use a single input of the exact size then it will be recombined into the same output value. But the client will deliberately select more inputs than necessary in order to make determining the input value more difficult. The server will also add multiple outputs of the same size as your inputs.

Even if you are restricting outputs to power of two sizes, as in the original coinjoin proposal, the same issue is still a problem. Address A sends 2 * 0.1 BTC + 1 * 1 BTC outputs then Address BTC receives 2 * 0.1 BTC + 1 * 1 BTC soon after it is easy to connect the dots.

Mixing in the background rather than on demand is probably the best way to solve this.

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

I got into a argument with somebody on IRC in #bitcoin over the suitability of coinjoin transactions for annoymised verifiable e-voting. justanotheruser's argument was that he could always verify that his choice got a "vote". My argument was that since the voters don't share their votes with each other, it is possible to mis-allocate votes without detection (as long as you are not too greedy).

This has implications for "normal" coinjoin transactions as well:If:

There are more than two participants

Two or more participants try to send coins to the same address without directly communicating with each other. (This includes trying to send mining fees)

Then:

It is possible for a bad actor to misdirect some of those funds for their own purposes.

For the attack to work, the original output must have at least as much funds as any one participant sent.

This works because non-communicating participants can only ever check that their own outputs look correct. One way to mitigate this is to phase out address reuse: which has not yet happened in practice.

As you note one workaround is don't reuse addresses— always good advice and here it doesn't have to be "phased out" in general but just by participants— but it's always better to be secure even if software is used dumbly.

I can suggest a trivial protocol addition that solves this without making the CJ transactions distinguishable or degrading privacy, but my solutions have some overhead. I'm curious if anyone can come up with a better way of doing it that doesn't have the overhead.

The general idea is that the merging party can just make a list (blindly) mapping their inputs to outputs, give the list to all players, and commit to the list so that all players know they got the same list.

Here is how it works:

The merging party makes a list with an entry for each output in the transaction. The entries have a nonce provided by each user either when they provide their input (or submitted their blindsigned tokens if blind signed tokens are in use). When they ask the users to sign they give the users the list and the users check and see that they are the credited party for every output they think they should be. Because they are just nonces they don't deanonymize users.

But to prevent the merging party from giving a different list to each user they must commit to it. I have two way to accomplish that:

The first is that we could require that a particular index in the outputs pay to an address which commits to the list: The merging party computes a new public key as an existing pubkey plus the H(list)*G, like a pay to contract (http://arxiv.org/abs/1212.3257), and a previously designated output pays to the resulting address. Given the list and original public key, everyone can check that that output commits to the same list. (And if two different users are given different lists, their signatures will not be merge-able since they would have signed different outputs).

(This designed output could belong to the merger or players could volunteer to have their output address placed in the designated position and to instead receive their payment at a pay-to-commit address. This is a little lame though, because it requires that there be at least one player that will tolerate receiving coins at a non-deterministic key.)

The second way to commit that I've come up with is to add an additional round to the protocol where you make a dummy transaction modified so that it won't ever be valid, e.g. using the list hash as an addition vin. Everyone signs this transaction and then only once they've seen this commitment signed by all the inputs will they sign the real transaction.

Needing an extra communications round or a non-deterministic output is kinda weak. Can better be done?

I really don't understand all the applause and excitement on how "CoinJoin" is supposed to increase the users' privacy.

Are you kidding me?This is not any new technology - personally I would not even call it an invention...IMHO, it is rather a legal advise to use a plausible deniability in a possible cases against you.

At first it had been assumed (by some incompetent people) that all the inputs of a single transaction must always come from the same wallet (thus the same person).What the author of the OP has invented is literally nothing - he only stated that technically inputs of a single transaction might just as well come from a completely different wallets - and this gives anyone a plausible deniability in any legal case (against him) that would be based on the assumption that all the inputs of a certain transaction came from his wallet.

In reality, assuming that you never disclose the content of your wallet (and if you did, CoinJoin won't help you anyway), you do not even need to find other parties to conduct CoinJoin!You can just as well "CoinJoin" your own coins, as long as you are going to claim that they weren't all yours - and there will be no distinguishable difference whatsoever, from a CoinJoin tx made by a multiple parties.

CoinJoin does not create any additional privacy - it is actually less private than regular translations, since the process involves letting other people to know which coins are yours.At best, it only gives you a reason to claim in court that not all the inputs were yours. The core of the "solution" here is a legal advise based on a technical properties of the bitcoin protocol.

So, not that I want to scare him, but as much as gmaxwell did not want to offend his big brother by helping to develop a software that would enable CoinJoin, he actually already did the most important part of the job by giving all the people the excuse that is the core of the invention here.

Therefore, since I am not so afraid of his brother, let me promptly point it out once again and remember: whenever anyone tells you that they traced your coins by "joined inputs" - just deny it and say that it was a CoinJoin transaction and not all the inputs were yours. Especially if it wasn't a CoinJoin transaction. :)

Good point piotr_n. It makes you think about the game-theoretic infinite regresses going on here. I would really appreciate it if some people write plausible code into wallets for CoinJoin, because next time I am in despotic country X and the local thugs are rubberhosing my private keys out of me, I'd like them to be slightly less convinced that both those inputs were mine :)

Good point piotr_n. It makes you think about the game-theoretic infinite regresses going on here. I would really appreciate it if some people write plausible code into wallets for CoinJoin, because next time I am in despotic country X and the local thugs are rubberhosing my private keys out of me, I'd like them to be slightly less convinced that both those inputs were mine :)

If it makes you feel better my Gocoin already supports it, though I won't be going into details because as I said: it's pretty useless and all we need to make it even more plausible is a software that can do it, not the people to do it with, nor actually doing it.

Actually even the satoshi client supports it, ever since they added the create/sign raw transaction APIs.

So if you will ever need a court witness to demonstrate how easy it is to make a CoinJoin transaction, you know how to find me. :)

Are you kidding me?This is not any new technology - personally I would not even call it an invention...IMHO, it is rather a legal advise to use a plausible deniability in a possible cases against you.

...

CoinJoin does not create any additional privacy - it is actually less private than regular translations, since the process involves letting other people to know which coins are yours.At best, it only gives you a reason to claim in court that not all the inputs were yours. The core of the "solution" here is a legal advise based on a technical properties of the bitcoin protocol.

Privacy is not only for plausible deniability in a legal case against you: as waxwing alluded to, it is also designed to give plausible deniability if local thugs figure out you frequent a Bitcoin accepting shop and likely have a fat wallet.

I am not convinced doing coinjoin transactions with yourself gives the same deniability. You would first have to split your funds (a good idea anyway with the relentless climb in value), then mix them. However, without other parties, the spitting and mixing with no external links will look obvious on a graph of transactions.

IMHO, it is rather a legal advise to use a plausible deniability in a possible legal cases against you.

...

CoinJoin does not give you any additional anonymity. At best, it only gives you a reason to claim in court that not all the inputs were yours. The core of the "solution" here is a legal advise based on a technical properties of the bitcoin protocol.

Coinjoin will be worthless in court. Your case is not going to prosecution when the sole evidence is a bitcoin transaction. Instead, that transaction is going to be used as the basis for collecting gobs and gobs of further evidence. At that point, the coinjoin isn't going to help you in court, it is going to hurt you, since it will be evidence that you knew what you were doing was wrong and tried to bury the evidence.

We need massive large scale joining for two reasons. One, if joining is routine, then you doing it isn't going to be evidence of wrongdoing anymore.

Two is to muddy the waters for mass surveillance. Right now, it is nearly trivial to trace transactions back and forth until it lands on a discoverable point. Assume for the moment that the NSA has total visibility into some exchange's HTTPS traffic and can see every deposit address they provide to users. When your chain of transactions lands on one of those addresses, the FBI knows they just need to request the customer info for whichever account uses that address, and they've got you.

Now imagine the world with coinjoin. Your coins break up and land in a dozen joint transactions. From there, each one hits a dozen more, and a dozen more, and so on. Now there are thousands or millions of things to track, and almost all of them will not be yours.

Sharedcoin transactions on blockchain.info lowered to 0.0001 BTC per repetition. On average 1.8 unique participants are joining in together each transaction, so over several repetitions there is a very good chance your transaction will be directly mixed with other users not just the sharedcoin server.

Sharedcoin transactions on blockchain.info lowered to 0.0001 BTC per repetition. On average 1.8 unique participants are joining in together each transaction, so over several repetitions there is a very good chance your transaction will be directly mixed with other users not just the sharedcoin server.

For those willing to futz around with raw transactions, I have a simple centralized coinjoiner available here:

https://www.wpsoftware.net/coinjoin/

Basically, once you submit a transaction this opens a 15-minute window for others to submit a transaction. After the 15 minutes are up, the transactions are merged and everybody signs the merged transaction. Once all the signatures are received, the joiner submits the transaction.

Thanks very much to my testers, in particular gmaxwell and midnightmagic, for their excellent suggestions and bug-finding.

Take N>3 coin joiners wishing to mix their coins and give them an order: A to B to C to D to E and back to A, forming a circle.

A is responsible for creating the first transaction. We proceed in rounds, each person receives the transaction from the person before them and forwards it to the next guy, where E returns it to A to form a circle.

Each person, upon receiving the transaction does the following:

If the received transaction is completely signed, then either forward the transaction onto the next guy or broadcast it to the bitcoin network. Forward randomly so the next in line can't figure out who signed last.

Otherwise, randomly add unspent inputs (from the blockchain utxo set) to the transaction and then add some random outputs. The inputs and outputs don't need to be owned by the person adding them, but eventually you need to include your final inputs and outputs. Next, select a few inputs added in a previous round and remove them (in the first round there will be nothing to remove). Do the same for outputs. Don't remove inputs or outputs that others added because they will assume you're trying to cheat and leave. In a later round, say 2 or 3, optionally sign one of your real inputs. If a successive person changes the tx again, you'll have to resign in another, later round.

Continue rounds until all fake inputs and outputs have been removed and the remaining inputs have been signed.

The obvious downsides include having to resign multiple times, the potential for lots of rounds, and not scaling well to large values of N. Any other thoughts?

If the parties immediately before and after you in the loop are conspiring (or sibyls) then they can always tell which inputs/outputs you added, so this is less private than some of the schemes proposed, in which N-2 malicious parties in an N way join cannot tell the 2 honest parties apart, for all N>2 (assuming you have underlying anonymous communication).

Your protocol sounds somewhat similar to a reencryption mix, except a reencryption mix doesn't need the chaff because the values are encrypted. A problem with using them for CJ is that protocols to prove faithful operation (e.g. to catch a party trying to break it) are computation and bandwidth intensive. One of their upsides (also— somewhat the case for yours) is that they are not so dependent on an underlying anonymity network (also the case for a MPC sort).

I think another potential issue in your protocol is that someone can just keep changing inputs/outputs forever to jam it, and you can't tell who is doing it (well, not anymore than you can tell who is who absent a jammer).

For those willing to futz around with raw transactions, I have a simple centralized coinjoiner available here:

https://www.wpsoftware.net/coinjoin/

Basically, once you submit a transaction this opens a 15-minute window for others to submit a transaction. After the 15 minutes are up, the transactions are merged and everybody signs the merged transaction. Once all the signatures are received, the joiner submits the transaction.

Thanks very much to my testers, in particular gmaxwell and midnightmagic, for their excellent suggestions and bug-finding.

If the parties immediately before and after you in the loop are conspiring (or sibyls) then they can always tell which inputs/outputs you added, so this is less private than some of the schemes proposed, in which N-2 malicious parties in an N way join cannot tell the 2 honest parties apart, for all N>2 (assuming you have underlying anonymous communication).

I considered this, but there's the extra advantage that nobody knows for sure if a single entity in the loop is indeed a single entity. Consider a figure 8, where node C is at the apex, and when he receives the transaction, it's passed around a similar set of other nodes and returning back to C, he forwards it on in the other loop. You'd have to control a large number of nodes in such a network to be able to produce any real association.

Quote

Your protocol sounds somewhat similar to a reencryption mix, except a reencryption mix doesn't need the chaff because the values are encrypted. A problem with using them for CJ is that protocols to prove faithful operation (e.g. to catch a party trying to break it) are computation and bandwidth intensive. One of their upsides (also— somewhat the case for yours) is that they are not so dependent on an underlying anonymity network (also the case for a MPC sort).

Do you have any more information on how a reencryption mix works w.r.t. CoinJoin?

Quote

I think another potential issue in your protocol is that someone can just keep changing inputs/outputs forever to jam it, and you can't tell who is doing it (well, not anymore than you can tell who is who absent a jammer).

True - it's especially problematic as N goes larger. Worst case, you have to assume everyone in the group is against you. Limit yourself to a low number of rounds and try other peers if the # of rounds is exceeded. You could theoretically build a list of trusted peers where previous successful CJs have been executed, too. All this is just workaround for a fundamental problem, though.

Have any Bitcoin core developers said anything about adding CoinJoin into the protocol?

Bump for this thread because it is important for Bitcoin

You don't need to add it to the protocol, CoinJoin operates just fine at a strictly higher level. But I suppose you mean adding support to the reference wallet for CoinJoin transactions? I would not be surprised to see that happen, but someone needs to write the code first.

Have any Bitcoin core developers said anything about adding CoinJoin into the protocol? Bump for this thread because it is important for Bitcoin

It doesn't need to be added to the protocol, thats part of the point.

If instead you mean the integrated Bitcoin-qt wallet, Wumpus and I have both commented that we'd like to see it there. I'd like to see more external implementation done first. Inside the wallet is good for getting users, but it's not good for protocol R&D.

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

You can use it without a blockchain.info wallet, and read all about it here:

https://blockchain.info/wallet/send-shared

From the FAQ on that page:

Quote

How does it work?Coins send with shared send will be matched up with another user. When a match is found your coins will be swapped breaking the transaction chain from your own wallet. Coins will be swapped with multiple users making the chain even harder to follow.

I found this very interesting (also from the same FAQ):

Quote

How can you guarantee that the transaction chain will be broken?There is no guess work involved, each shared transaction analyzes up to 50,000 outputs or 250 levels deep in the blockchain to ensure the coins sent to the destination address are 100% untainted with the original coins.

The source code for taint analysis calculations can be found on the Blockchain Github Project

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

When there are two outputs to the same address with the same value (for example, two people want to donate 1 btc each to wikileaks), what prevents the service owner from swapping one of them with their own address?

But how would you know? If only one Wikileaks donation makes it into the final txn, wouldn't each participant just assume it was their donation? How could they tell otherwise?

It's the way the protocol works. You don't just have your balance lowed and some other balance somewhere raised; inbetween there is something called a 'transaction' specifying very specific things which must be digitally signed.

If you and someone else both send money to Wikileaks, you both sign your transactions. The transactions, even for identical amounts, are not identical. For one thing they will name different unspent txouts to spend; for another they'll have different timestamps. For a third thing they will specify different addresses for "change" to come back to. All of these things will be combined in a hash function to give your transaction a transaction ID which is unique.

If someone violates the protocol and sends some other guy's transaction to you to sign, your bitcoin client will look at it and say, "hey, I don't even own this particular txout that this transaction is trying to spend, and this isn't my transaction ID, and the timestamp is wrong, and the change address isn't any I've ever given out. Heck, the change address is not even one I have a key to spend. WTF?"

Meanwhile, if someone tries to use a transaction that you have signed, but with a changed payee, it won't match the signature you put on it because the changed payee would make it have a different transaction ID. It would be a transaction that doesn't match its signature, and he couldn't put it on the blockchain because every other client would reject it.

But how would you know? If only one Wikileaks donation makes it into the final txn, wouldn't each participant just assume it was their donation? How could they tell otherwise?

A possible solution:

Each participant must have all the information from all participants to create the transaction for themselves (i.e. know all inputs and outputs). If both Participant A and Participant B create unique identifiers for their outputs (both for 1BTC, both to address 1HB5XMLmzFVj8ALj6mfBsbifRoD4miY36v, but each with a unique identifier, X and Y, respectively), then when the Controller C specifies the full inputs and outputs to create the Transaction, it will also need to indicate the unique output identifiers.

When Participant A and Participant B create the Transaction from the information from Controller C, they will only create and sign a transaction where Controller C indicates the correct output amount, address, and identifier. Participant A will only sign a transaction that has an output with identifier X and Participant B will only sign a transaction with identifier Y.

Participant A and B then send the correct signatures to the Controller who recreates the same transaction from the inputs and outputs, but now with the signatures of Participant A and B.

If you and someone else both send money to Wikileaks, you both sign your transactions. The transactions, even for identical amounts, are not identical. For one thing they will name different unspent txouts to spend; for another they'll have different timestamps. For a third thing they will specify different addresses for "change" to come back to. All of these things will be combined in a hash function to give your transaction a transaction ID which is unique.

There is no way in a transaction to determine what is "my output" and "your output". That is what makes coin join work, but also brings up the problem originally posed.

If you and someone else both send money to Wikileaks, you both sign your transactions. The transactions, even for identical amounts, are not identical. For one thing they will name different unspent txouts to spend; for another they'll have different timestamps. For a third thing they will specify different addresses for "change" to come back to. All of these things will be combined in a hash function to give your transaction a transaction ID which is unique.

There is no way in a transaction to determine what is "my output" and "your output". That is what makes coin join work, but also brings up the problem originally posed.

Your output is the one that you have the key to spend. What's hard about that? There may be no way for anyone *else* to tell whose output is whose, but you are the guy who created that key pair, you still have the private key, and you know damn well whether a given output has the corresponding public key. In a coinjoin everyone can identify their own outputs. But they can't distinguish anyone else's, and no third-party observer can distinguish them at all.

If you and someone else both send money to Wikileaks, you both sign your transactions. The transactions, even for identical amounts, are not identical. For one thing they will name different unspent txouts to spend; for another they'll have different timestamps. For a third thing they will specify different addresses for "change" to come back to. All of these things will be combined in a hash function to give your transaction a transaction ID which is unique.

There is no way in a transaction to determine what is "my output" and "your output". That is what makes coin join work, but also brings up the problem originally posed.

Your output is the one that you have the key to spend. What's hard about that? There may be no way for anyone *else* to tell whose output is whose, but you are the guy who created that key pair, you still have the private key, and you know damn well whether a given output has the corresponding public key. In a coinjoin everyone can identify their own outputs. But they can't distinguish anyone else's, and no third-party observer can distinguish them at all.

We might be talking about different outputs. The original question was not about the TxOut that is an input to the CoinJoin transaction, but instead the outputs of the CoinJoin Transaction itself. AFAIK, there is no way for me to get Wikileak's private key. :)

If you and someone else both send money to Wikileaks, you both sign your transactions. The transactions, even for identical amounts, are not identical. For one thing they will name different unspent txouts to spend; for another they'll have different timestamps. For a third thing they will specify different addresses for "change" to come back to. All of these things will be combined in a hash function to give your transaction a transaction ID which is unique.

I suggest you carefully read the first post of this thread. We aren't discussing the usual bitcoin transactions here but coinjoin specifics.

When Participant A and Participant B create the Transaction from the information from Controller C, they will only create and sign a transaction where Controller C indicates the correct output amount, address, and identifier. Participant A will only sign a transaction that has an output with identifier X and Participant B will only sign a transaction with identifier Y.

I guess one could include an indentifier in the tx_out using OP_DROP, that might work.

It's a bit more convoluted but if everybody signs a dummy transaction with identifiers for the outputs then you could just remove the identifiers and everybody signs again if the transaction is exactly the same in terms of tx_out and tx_in.

It's a bit more convoluted but if everybody signs a dummy transaction with identifiers for the outputs then you could just remove the identifiers and everybody signs again if the transaction is exactly the same in terms of tx_out and tx_in.

I just meant that if you didn't want to include the identifiers in the actual multi signature coin join transaction then everybody would sign a dummy transaction. This dummy transaction would contain everybody's outputs with identifier so that they know that the controller hasn't redirected any duplicate payments to himself. The dummy transaction would not be broadcastable or valid but everybody would use it to agree to the tx_outs and tx_ins by everybody signing it. Once they had agreed by all signing the controller could create a valid transaction with the same inputs and outputs but without identifiers and then they would all sign this.

I just meant that if you didn't want to include the identifiers in the actual multi signature coin join transaction then everybody would sign a dummy transaction. This dummy transaction would contain everybody's outputs with identifier so that they know that the controller hasn't redirected any duplicate payments to himself. The dummy transaction would not be broadcastable or valid but everybody would use it to agree to the tx_outs and tx_ins by everybody signing it. Once they had agreed by all signing the controller could create a valid transaction with the same inputs and outputs but without identifiers and then they would all sign this.

..or maybe I've misunderstood something?

I see. The problem is if the service chooses the identifiers they would just send the two users different dummy transactions to sign, with such identifiers both would be convinced the donation is actually their own, so I think it has to be users who choose identifiers beforehand. I think just adding (random) id's to the outputs that are dropped off the stack using OP_DROP wold work though - so for each output I choose random number, add it (as <rnd number> OP_DROP), send inputs and outputs to the service, when I get the transaction back I check if the outputs match with what I sent, if they do I sign the transaction.

I meant the users do choose their own identifiers, the dummy transaction is created with these.I just thought the identifiers might be able mark out the transaction as a coin join transaction if they were part of the transaction which might not be desirable.I'm not really familiar with OP_DROP, maybe it achieves the same thing.

But how would you know? If only one Wikileaks donation makes it into the final txn, wouldn't each participant just assume it was their donation? How could they tell otherwise?

Reference the original offers in the join request, so that anyone considering signing the transaction can make sure that not just the correct outputs, but also the correct number of outputs are present. My Python implementation does this.

But how would you know? If only one Wikileaks donation makes it into the final txn, wouldn't each participant just assume it was their donation? How could they tell otherwise?

Reference the original offers in the join request, so that anyone considering signing the transaction can make sure that not just the correct outputs, but also the correct number of outputs are present. My Python implementation does this.

Can you link to your implementation, please? I'd like to have a look because I don't fully understand.

The way I understand it, the problem can be phrased in the following way.

Suppose that both Alice (address A) and Mallory (address M) want to buy an item from seller Steve. Alice and Mallory create a CoinJoin transaction (A,M) -> (S,M') where M' is another address controlled by Mallory. Alice signs the transaction as she sees that the correct amount is sent to Steve and expects to receive her service. However, Mallory may also later claim that he sent the money to Steve and that he should receive the service. From Steve's point of view, both claims are equally valid.

I believe that maaku's solution would work as long as the join requests are signed and kept by each party. One downside of this is that it might reduce the anonymity of the system since each user can later prove the other user's intentions to a third party.

Reference the original offers in the join request, so that anyone considering signing the transaction can make sure that not just the correct outputs, but also the correct number of outputs are present. My Python implementation does this.

Another, simpler solution would be to make sure to never send funds to a public address in a CoinJoin transaction and for sellers to always use fresh receiving addresses.

Suppose that both Alice (address A) and Mallory (address M) want to buy an item from seller Steve. Alice and Mallory create a CoinJoin transaction (A,M) -> (S,M') where M' is another address controlled by Mallory. Alice signs the transaction as she sees that the correct amount is sent to Steve and expects to receive her service. However, Mallory may also later claim that he sent the money to Steve and that he should receive the service. From Steve's point of view, both claims are equally valid.

This is not exactly what I meant.

Alice uses input A and sends 1 btc to address S. Bob uses input B and sends 1 btc to address S. Legit coinjoin transaction would look like [A, B] -> [(S,1), (S,1)], but here the service could change it to [A, B] -> [(S,1), (X,1)], where X is service's address. Since Alice isn't aware of Bob's transaction and vice versa none would suspect that the (S,1) output is not theirs, thus signing the transaction. As I said I don't really understand how maaku solves this problem. As I see it the only way to solve it is for users to provide some kind of a nonce with the outputs that can later be checked.

Suppose that both Alice (address A) and Mallory (address M) want to buy an item from seller Steve. Alice and Mallory create a CoinJoin transaction (A,M) -> (S,M') where M' is another address controlled by Mallory. Alice signs the transaction as she sees that the correct amount is sent to Steve and expects to receive her service. However, Mallory may also later claim that he sent the money to Steve and that he should receive the service. From Steve's point of view, both claims are equally valid.

This is not exactly what I meant.

Alice uses input A and sends 1 btc to address S. Bob uses input B and sends 1 btc to address S. Correct coinjoin transaction would look like [A, B] -> [(S,1), (S,1)], but here service could change it to [A, B] -> [(S,1), (X,1)], where X is services' address. Since Alice isn't aware of Bob's transaction and vice versa none would suspect the (S,1) output is not theirs, thus signing the transaction. As I said I don't really understand how maaku solves this problem. As I see it the only way to solve it is for users to provide some kind of a nonce with the outputs that can later be checked.

I was imagining more of a decentralized CoinJoin where people got together to create the transaction instead of asking a service to do it, but both situations are similar. In the centralized case, maaku's solution does not seem to work as it requires communication between the participants. However, sellers not reusing addresses that receive payments does solve the problem even in the centralized case as Alice and Bob cannot simultaneously think that they are paying Steve.

Of course you cannot trust any service more than to provide you the entire transaction you get to sign - not only its hash.Then you make sure that at least one of its outputs satisfies your input.And then you get to know more about a possible connections between the txs inputs and output. Which inforamtion, who knows, maybe you'll be able to sell one day in a future so you may want to keep it :)

Its really not as cool as you think, unless you build a huge and anonymous infrastrtuctere for it.Who's going to do it? Jesus is dead for all I know. We're talking about tor at least, otherwise it dont make no sense. And what: SR style, or p2p? Is there even a p2p in tor? Who's going to pay for it to profit from it? Or it won't happen...

Anyway, understand that the weakest link here is the ip that sends your money to the network. Sharing the tx with your pals or strangers picked by some system to increase privacy - give me a break

maaku's solution does not seem to work as it requires communication between the participants

No, the server can include this signed information in the message it sends to participants.

The solution is simple: each participants sign what outputs they want to see on the chain. No participant signs the transaction unless they receive invoices separately signed by every single input which cumulatively add up to the transaction. Cryptographic blinding is used to make sure that users can specify hidden outputs not subject to this check.

Quote

the example was a donation address, it would be difficult to imagine this changing for each donation

Rather than adding more steps and layers to the system, I propose ignoring the chance of the joiner operator skimming merges.

If it bothers anyone, they can send their donation to a new address in their own wallet, then send that to the donation address in the normal way. This operation could even be scripted. (Your wallet searches google for your payment address. If there are no results, it is more or less impossible for another coin join user to be sending to that address. If there are results for it outside of the explorer sites, it automatically switches into 2-stage mode.)

maaku's solution does not seem to work as it requires communication between the participants

No, the server can include this signed information in the message it sends to participants.

The solution is simple: each participants sign what outputs they want to see on the chain.

Are they signing a set of all outputs randomly mixed up? This wouldn't solve the problem.Or are they signing their individual outputs? There is no anonymity now.

Quote

No participant signs the transaction unless they receive invoices separately signed by every single input which cumulatively add up to the transaction.

I can't see how this helps to solve the problem.

Quote

Cryptographic blinding is used to make sure that users can specify hidden outputs not subject to this check.

I'm not really sure what you're saying here. If you're talking about a blind signature protocol can you be more specific about how it can work in this case.

Quote

the example was a donation address, it would be difficult to imagine this changing for each donation

Quote

Google "bitcoin stealth address"

I didn't say that it wasn't possible to change the address for each donation. This could be done without stealth addresses. I just think that most people asking for donations will just put up an address and ask people to send coins to it. :)

They sign a list of their outputs, some of which are explicit, some of which are blinded. The blind signed outputs are separately checked (the server blind signed them without knowing what they were, so couldn't later skim them without detection). So each participant has a list of non-mixed outputs signed by their owners, and a list of blinded outputs signed by the server before it had a chance to do any funny business. Together these should add up to the entire transaction (modulo facilitator and miner fees).

I've spent the last two/three months working on a CoinJoin implementation that I call Coinmux. It is open source and mostly P2P / decentralized.

The source is in Ruby (JRuby) and on Github: https://github.com/michaelgpearce/coinmux. The project home page has quite a bit of information so its worth reading through.

Here is an example transaction created with Coinmux for 3 participants: http://test.webbtc.com/tx/963d6a87c2f0c3e715d0550539ffa3fed0731abd4b3b081d52f29891592f400d. (You'll notice some change address re-use due to this making my testing easier.) The commands used were:

Its setup to use Testnet (i have not tried it on mainnet as its alpha software!). It can be easily configured to use either a local filesystem to communicate or P2P over the Internet. The filesystem communication is fairly robust while the P2P Internet mode works reasonably well, but will require a lot more testing and work to prevent bad actors.

There is a protocol specification: https://github.com/michaelgpearce/coinmux/blob/master/docs/spec.mdThe peers communicate using JSON messages. None of the connected peers can associate input with output ownership from the messages themselves, only by IP addresses. This is a pretty big privacy leak, but can be solved by integrating Tor or Freenet to communicate the messages.

I've only implemented a command line interface for now, but the CLI is event driven and built with a GUI in mind. I don't want non-developers trying it yet so a CLI seems like a good place to start.

The easiest way to try it out locally is to use "--data-store filesystem" and invoke the command from a couple of different terminal sessions on your computer. Again, its setup to use Testnet, so you need a Testnet wallet / private keys.

Hey all, i just released v0.1.0 of Coinmux (followed quickly by 0.1.1 to fix a couple of minor UI issues) which is my milestone for having things functional on Testnet. I'm ready to move on to building a GUI to sit on top of the code already there and make it easier to use.

But before I do that, I want to try it out on the Bitcoin MAINNET and with some STRANGERS on the Internet! I've never done either!

I'm hoping a couple of you are brave enough to try it with me. I want to do a small CoinJoin transaction, 0.001 BTC (a little less than 1USD) . To get a suitable wallet, I simply went to bitaddress.org, created a new wallet for the CoinJoin input, and then sent 0.0015 BTC to it from my main wallet (a little extra for miner fees). Any address with a balance > 0.0015 will work, but I would not recommend using your primary wallet. There shouldn't be any issues, but better to be safe than sorry.

If you are interested, there is a link to download the latest Java client here: https://github.com/michaelgpearce/coinmux (https://github.com/michaelgpearce/coinmux). To use the Mainnet Bitcoin network instead of Testnet, you'll simply need to set an environment variable COINMUX_ENV=production. On a Unixy OS, you should be able to just type this command in the terminal/console where you run the Java command. On Windows, i believe you use the SET command, but its been years since i've used Windows.

I'm on Freenode IRC at #coinmux via webchat: https://webchat.freenode.net (https://webchat.freenode.net). Hopefully one or two people will come find me.

How does Coinmux find other users? And if it doesn't, can it implement a Bitmessage chan?

It uses a java p2p library http://tomp2p.net/ to create DHT of users.

Yep. It uses TomP2P. My initial implementation was going to use Freenet, but I didn't want to require needing any external applications running.

In Coinmux, I call the communication layer a Data store in the code. There is an implementation using TomP2P, the file system and one that uses only memory for testing purposes. It's straight forward to implement these and I did also consider Bitmessage. Unfortunately, the Bitmessage JSON API looked to be very heavily tied to a specific user in the UI with no way to create a new user via API or send messages as a specific user. This lead me to stop investigating it further.

Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that. I'm planning on giving a presentation at the SF Bitcoin Meetup to increase CoinJoin and Coinmux awareness.

Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that. I'm planning on giving a presentation at the SF Bitcoin Meetup to increase CoinJoin and Coinmux awareness.

I think this is a great start, your protocol needs a little work and I am writing something off of it.

Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that. I'm planning on giving a presentation at the SF Bitcoin Meetup to increase CoinJoin and Coinmux awareness.

I think this is a great start, your protocol needs a little work and I am writing something off of it.

Feel free to share your thoughts. I haven't gotten any feedback on the protocol yet.

Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that.

Testnet is the proper solution to that. Let people test it using testnet coins and the problem about the bitcoin private key risk goes away.

Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that.

Testnet is the proper solution to that. Let people test it using testnet coins and the problem about the bitcoin private key risk goes away.

I totally agree. It is set up right now to work off testnet by default (the user needs to set an environment variable to connect to Mainnet). Unfortunately, the testnet knowledgeable audience is a lot smaller, and CoinJoining needs multiple people running it at the same time. Hopefully in time, this will resolve itself.

And i'm not sure i really made this clear in my original posting, but the only thing needed to run Coinmux is Java and the Jar file available from http://github.com/michaelgpearce/coinmux (http://github.com/michaelgpearce/coinmux). You don't need to have BitcoinQT installed and it does not require downloading the blockchain to your computer. I'm trying to make something that an average Bitcoin user will be able to understand and use.

After reviewing your coinmux code, I can identify a problem. And a solution.

The good: no evidence appears in the blockchain about whose inputs are associated with which output. That's part 1 of the solution.

The bad: Someone eavesdropping on the protocol messages, including a nonparticipant, can associate both inputs and outputs with IP addresses. Fixing this is completely necessary before coinmux is viable, especially since the primary attack on network privacy is via traffic analysis.

The solution: Implement a Dining Cryptographers Network among the participants, and you are immune to traffic analysis. Here's a wikipedia article about the Dining Cryptographers' problem which it's based on.

http://en.wikipedia.org/wiki/Dining_cryptographers_problem

In a DCN, topologically the participants are arranged in a circle, where Alice is next to Zebulon and Bob, Bob is next to Alice and Carol, Carol is next to Bob and Estelle, etc.

Each adjacent *pair* of participants generates a shared key stream - which can be as simple as repeatedly incrementing a nonce and encrypting it to get each new block of the key stream. You can use Diffie-Hellman key agreement to create a shared secret to key the stream.

Then each participant publishes XOR of the keystreams he shares with his two adjacent participants and the message he wishes to broadcast. When all of these published messages are XOR'd together, the broadcast message magically appears because each keystream has been XOR'd with it twice thereby cancelling out the keystreams. Different participants can write on different parts of the block, creating different messages. And the participants can iteratively publish the block with updates, if they use a different hunk of their shared keystreams each time. I'm thinking that the obvious implementation here has the 'block' that's getting updated include the image of a transaction. The participants would each add their inputs and their outputs, then signatures (not valid if anybody changes outputs) in a later round.

The benefit is that nobody monitoring the protocol messages can tell where the messages (or the parts of messages, IE inputs and outputs) originated, even if they saw every last message and every published XOR. Not even the participants can tell anything about the origins of any part of the message written by someone else.

It has some limitations; For example if two people both try to write on the same blob of bits at the same time, then the 'message' that appears in that blob is binary garbage. So there are conventions about 'reserving' blocks in previous rounds, where you agree that whoever reserved the block can write things in it and others shouldn't, and ways to detect which participant has broken the convention so that they can be cut out of subsequent rounds, etc. Also, it requires O(n^2) overhead where n is the number of participants, so it doesn't scale well past a few dozen people per mux. It's kinda clunky.

But it does work, and it's completely trustless in that NOBODY can de-anonymize, or even distinguish, the participants.

The cryptographer in me says I should do this, while the engineer in me thinks this may be (too) difficult to implement. (And I'm a much stronger engineer than cryptographer!) I still haven't totally wrapped my head around it from an engineering perspective, I'll do that once I get the GUI for Coinmux working. But I am a believer in keeping Coinmux simple. Bitcoin has some warts, but its really pretty simple as far as crypto goes. I'd like to keep that same philosophy for Coinmux.

One of the easiest things I can do to limit who sees the the IP address of published messages is to encrypt them. Both the Director and Participants have a public key as part of their first message broadcast. Other than the Director's first announcement message and the Director's subsequent status updates, all other messages can be encrypted so only the involved parties can decrypt the messages. The IP address would still be leaked, but only those in the mix can make sense of what's going on. While not a cryptographically perfect solution, this would make traffic analysis more difficult and less useful. This may make put Coinmux in the "good enough to be useful" category. This wouldn't be great, but as an engineer, I realize everything has tradeoffs.

The Coinmux protocol itself was not designed to hide IP addresses/participants, only to facilitate communication. As i first imagined what the protocol would look like, I had always considered using Freenet for message communication and to provide anonymity at the "network layer." Coinmux was designed with a Freenet like system in mind with the following properties: untraceable message insertion, immutable messages, ability to post multiple messages to a known location/key, and all messages publicly retrievable from a known key. TomP2P allows for all of these except the untraceable message insertion. TomP2P was really only selected due to it being available as a Java library and ready to be embedded in an application. Well, that and it's faster than Freenet.

I'd rather try to solve this at the network layer than the protocol layer. This allows for the network layer to be easily changed (I have 3 implementations now - TomP2P, the filesystem, and a memory implementation used for testing). I am still actively considering switching to using Freenet as originally planned. Bitmessage is another option, though i believe their API is inadequate. Maybe there is a way to use Tor. Or maybe some new Altcoin becomes a viable option in the future. Or maybe i can push harder on TomP2P: is it possible to shuffle messages around the TomP2P peer network before inserting them to provide anonymity? The protocol doesn't care who inserted the message, only that it gets inserted. As it is right now, none of the options outside of TomP2P meet the requirement of "easy to use" as they require an additional application running.

Anyway, there are lots of different options and all of them have tradeoffs, but I am pretty open to anything that will work. I'll need to let what you wrote settle on my brain a little more.

Maybe you can use i2p (https://geti2p.net) for the network layer (comes with nice java bindings :)).

I had looked at I2P for this project previously but ruled it out due to it not behaving as a data store (which Freenet and TomP2P both are). Looking at the I2P documentation again, they did mention someone adding Tahoe-LAFS support (https://geti2p.net/en/comparison/freenet (https://geti2p.net/en/comparison/freenet)), but I don't have any information about that.

I also looked at I2P before I knew about TomP2P. Since I2P supports both TCP and UDP (https://geti2p.net/en/comparison/tor (https://geti2p.net/en/comparison/tor)), it may be possible to combine it with TomP2P. AFAIK, Tor does not support UDP so TomP2P + Tor is not possible.

Maybe you can use i2p (https://geti2p.net) for the network layer (comes with nice java bindings :)).

I had looked at I2P for this project previously but ruled it out due to it not behaving as a data store (which Freenet and TomP2P both are). Looking at the I2P documentation again, they did mention someone adding Tahoe-LAFS support (https://geti2p.net/en/comparison/freenet (https://geti2p.net/en/comparison/freenet)), but I don't have any information about that.

I also looked at I2P before I knew about TomP2P. Since I2P supports both TCP and UDP (https://geti2p.net/en/comparison/tor (https://geti2p.net/en/comparison/tor)), it may be possible to combine it with TomP2P. AFAIK, Tor does not support UDP so TomP2P + Tor is not possible.

I just saw this: https://geti2p.net/en/docs/applications/supported#decentralized-file-storage (though i can't view eepsites right now since i don't have I2P installed). I2P definitely goes back on my investigation list. :)

After reviewing your coinmux code, I can identify a problem. And a solution.

The good: no evidence appears in the blockchain about whose inputs are associated with which output. That's part 1 of the solution.

The bad: Someone eavesdropping on the protocol messages, including a nonparticipant, can associate both inputs and outputs with IP addresses. Fixing this is completely necessary before coinmux is viable, especially since the primary attack on network privacy is via traffic analysis.

The solution: Implement a Dining Cryptographers Network among the participants, and you are immune to traffic analysis. Here's a wikipedia article about the Dining Cryptographers' problem which it's based on.

http://en.wikipedia.org/wiki/Dining_cryptographers_problem

In a DCN, topologically the participants are arranged in a circle, where Alice is next to Zebulon and Bob, Bob is next to Alice and Carol, Carol is next to Bob and Estelle, etc.

Each adjacent *pair* of participants generates a shared key stream - which can be as simple as repeatedly incrementing a nonce and encrypting it to get each new block of the key stream. You can use Diffie-Hellman key agreement to create a shared secret to key the stream.

Then each participant publishes XOR of the keystreams he shares with his two adjacent participants and the message he wishes to broadcast. When all of these published messages are XOR'd together, the broadcast message magically appears because each keystream has been XOR'd with it twice thereby cancelling out the keystreams. Different participants can write on different parts of the block, creating different messages. And the participants can iteratively publish the block with updates, if they use a different hunk of their shared keystreams each time. I'm thinking that the obvious implementation here has the 'block' that's getting updated include the image of a transaction. The participants would each add their inputs and their outputs, then signatures (not valid if anybody changes outputs) in a later round.

The benefit is that nobody monitoring the protocol messages can tell where the messages (or the parts of messages, IE inputs and outputs) originated, even if they saw every last message and every published XOR. Not even the participants can tell anything about the origins of any part of the message written by someone else.

It has some limitations; For example if two people both try to write on the same blob of bits at the same time, then the 'message' that appears in that blob is binary garbage. So there are conventions about 'reserving' blocks in previous rounds, where you agree that whoever reserved the block can write things in it and others shouldn't, and ways to detect which participant has broken the convention so that they can be cut out of subsequent rounds, etc. Also, it requires O(n^2) overhead where n is the number of participants, so it doesn't scale well past a few dozen people per mux. It's kinda clunky.

But it does work, and it's completely trustless in that NOBODY can de-anonymize, or even distinguish, the participants.

I've thought through this some more. I could implement this, and it wouldn't be terribly difficult. In fact, I think I can even implement it without changing my current communication API (see my data store requirements in a previous post). My main problem with it is that it only solves one thing that i can't solve by simply encrypting every message published to the Director and a DCN doesn't solve a larger issue.

With using TomP2P and adding message encryption, the Director can still connect IP addresses to Inputs/Outputs but the Participants cannot. A DCN will solve this. But an outside observer would most likely still be able to connect IP addresses with the resulting published transaction just by watching the Coinmux network and watching the Bitcoin network. While the observer cannot directly correlate an IP to a specific Bitcoin output address, just knowing the transaction and the IP addresses involved is still a pretty big leaked piece of information.

If I use an anonymity network (i.e. Freenet), it would solve both issues. Neither the participants nor the director would be able to associate an IP address to a specific input/output, and an observer would not be able to associate a transaction to any IP addresses.

I like the DCN because it's elegant and comes with an honest-to-goodness proof of security against all traffic analysis. Even with just two honest participants, nobody else can tell which of them sent a message even if they can see (and even modify!) every message in the whole network.

I guess I trust anonymity networks less, because I consider them to be potentially fakeable; I can imagine code running on a network of servers that presents all honest participants an interface indistinguishable to them from an anonymity network while compromising their communication. In an anonymity network, you only need to compromise the two or three or four nodes that your messages are getting routed through. Or the routing tables that tell you where they are. Or the messages from the DNS servers that relay that information to you. Or ....

I've been reading about the lengths that eavesdroppers are going to, and that just seems like something they'd do. Or something which, if they haven't done it yet, they eventually will. Maybe I'm excessively cynical; I just think that if you leave a target surface, then sooner or later someone is going to exploit it. Massive sybil attacks, fake nodes, backbone router trojans, etc... They've drawn the line at nothing so far. The NSA even went so far as to put a zero-day exploit against the browser that TOR is used with at a fake site, intercepted traffic on backbone nodes, and redirected requests at it in realtime from computers where TOR traffic had been detected. And that's the government - the people who are supposed to be on our side. What the heck are straight-up crooks ready to do?

the people who are supposed to be on our side. What the heck are straight-up crooks ready to do?

You're assuming that the "straight out crooks" aren't the NSA? (All evidence to the contrary.)

I'm just saying that they can't possibly be the worst crooks out there. I mean, hell, I figure we know who the NSA are. If they were really the worst crooks out there we *WOULDN'T* know who they are.

They had public PR problems, boo-hoo, because they accidentally hired someone honest. My heart bleeds for them. But the absolute worst crooks wouldn't have that problem.

People keep forgetting that the NSA isn't the only thing like itself that exists in the world; probably not even the best. And people keep forgetting that among those things, the NSA is probably only about average in terms of its honesty and morality. And that just addresses government agencies, not even starting on whatever parasitic criminal organizations have infiltrated them. Hell, if the NSA is doing all the stuff in the Snowden files, and failed to even keep that a secret, I hate to imagine what NAPSS, BBN, GRU, SAVAK, Mossad etc, are up to.

Hey all. I released a new version of Coinmux that now has a graphical user interface. It still defaults to using the Testnet network, but you can now easily change that in the preferences menu if you are adventurous with your Bitcoin.

You can view an animated GIF with two participants mixing their coins on the Coinmux homepage http://www.coinmux.com (http://www.coinmux.com).

Here is a full-sized direct link to the animated GIF http://coinmux.com/images/animated-coinmux.gif (http://coinmux.com/images/animated-coinmux.gif).

And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux (http://github.com/michaelgpearce/coinmux).

Hey all. I released a new version of Coinmux that now has a graphical user interface. It still defaults to using the Testnet network, but you can now easily change that in the preferences menu if you are adventurous with your Bitcoin.

And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux (http://github.com/michaelgpearce/coinmux).

Hey all. I released a new version of Coinmux that now has a graphical user interface. It still defaults to using the Testnet network, but you can now easily change that in the preferences menu if you are adventurous with your Bitcoin.

And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux (http://github.com/michaelgpearce/coinmux).

It looks awesome! Keep up the good work!

Thanks! I forgot what a pain in the ass making a desktop app is. This was a good reminder. :)

What about adding this into server based clients with matching via the server? (Electrum, Blockchain.info, Mycelium...)

And make them to not store the logs?That would probably be the quickest way to get whoever run these servers arrested by US nazi law enforcement (aka national security services) - at some airport somewhere in the world... :)

What about adding this into server based clients with matching via the server? (Electrum, Blockchain.info, Mycelium...)

And make them to not store the logs?That would probably be the quickest way to get whoever run these servers arrested by US nazi law enforcement (aka national security services) - at some airport somewhere in the world... :)

I think Mycelium has CoinJoin as one of the things on their future To Do list. If not, I'll add it ;D

Yeah, but I'm just saying that it's pretty worthless if they store the logs.And if they don't store the logs... well, that's probably illegal, at least in US and Russia :)

The only safe CoinJoin solution I see is p2p based, with some tricky encryption.

But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".Though it has two big disadvantages, over p2p coin mixing:1) You need to trust the service to really destroy the logs2) It doesn't come for free.

So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it around a server would just defeat the purpose.Not to mention that it would be dangerous for whoever runs this server.

Yeah, but I'm just saying that it's pretty worthless if they store the logs.And if they don't store the logs... well, that's probably illegal, at least in US and Russia :)

The only safe CoinJoin solution I see is p2p based, with some tricky encryption.

But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".Though it has two big disadvantages, over p2p coin mixing:1) You need to trust the service to really destroy the logs2) It doesn't come for free.

So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it would just defeat the purpose.

Is that exactly what Darkcoin is doing? Decentralized and encrypted coinjoin.

Yeah, but I'm just saying that it's pretty worthless if they store the logs.And if they don't store the logs... well, that's probably illegal, at least in US and Russia :)

The only safe CoinJoin solution I see is p2p based, with some tricky encryption.

But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".Though it has two big disadvantages, over p2p coin mixing:1) You need to trust the service to really destroy the logs2) It doesn't come for free.

So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it around a server would just defeat the purpose.Not to mention that it would be dangerous for whoever runs this server.

Piotr_n, you seem to be an intelligent and experienced low level (C++ or lower) programmer.

Wouldn't it suit you better simply to write your own CoinJoin implementation instead of just talking about it ?

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

Yeah, but I'm just saying that it's pretty worthless if they store the logs.And if they don't store the logs... well, that's probably illegal, at least in US and Russia :)

The only safe CoinJoin solution I see is p2p based, with some tricky encryption.

But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".Though it has two big disadvantages, over p2p coin mixing:1) You need to trust the service to really destroy the logs2) It doesn't come for free.

So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it around a server would just defeat the purpose.Not to mention that it would be dangerous for whoever runs this server.

The CoinJoin client I wrote, Coinmux https://github.com/michaelgpearce/coinmux (https://github.com/michaelgpearce/coinmux) is P2P and open source. Its still in its early development phase though. Having spent the last 10 years building web applications, building a true P2P application is definitely more difficult than building a server-side solution (which you have to trust).

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

Honestly, I just don't need it, so I don't really feel the urge to create such a thing.

If the solution was easy I would have probably done it even when not needing it, but in such case someone else would have already done it before me. The problem is that it doesn't seem so much straight forward. At the other hand providing feedback on the forum is easy - this I can do by the way of having another beer before sleep, nothing hard about it :)

Still I believe it can be done and since it can be done, someone will do it one day - it is just a matter of time.But to design it well, you first need to define what kind of privacy this technology is supposed to target.I mean you can identify a different kind of threads.The first one is of course that all the internet traffic is recorded.The second: that the peers with who you are sharing your transaction may (and surely will, after you launch the project) be malicious - e.g I can imagine a network of bots flooding the p2p system with many txs to themselves, just to learn about your transactions. A third... probably also something.

But if you just want to do a "p2p CoinJoin", without caring about any of these things, then you might just as well look for people to share your tx with at IRC; you all make a joined tx and each party signs manually its part. There already is a software that can do it - not only mine, for what I know.

It's possible to implement coinjoin that can be trusted, even if nobody deletes the logs. You can secure it against the ability to associate inputs or outputs with each other, or with IP addresses, to an opponent using blockchain evidence, server logs, or realtime packet sniffing.

The "tricky cryptography" is a stream cipher with multiple keys, each key being known to exactly two participants (aka, a dc-net). There is a requirement that there must be more than one honest participant in the "join" whose stream key is unknown to the opponent. An opponent listening to packet traffic can associate inputs/outputs with any participant whose key that opponent has compromised, so if there is only one honest participant whose key is uncompromised, the opponent can associate inputs/outputs with that participant by process of elimination.

I'll implement it if nobody else has by the time I get around to it, but it isn't my highest priority right now; I have a higher-paying bounty to pursue in programming, which is (arguably) even more important to Bitcoin in terms of adoption and remaining decentralized, and that is to limit the size of the blockchain download needed to run a full node.

The extant solution for anonymous networks (Tor) requires extra steps that many users won't do, many of those who do will get wrong, and many of those who get wrong won't be aware that they've got wrong. It is subject to attacks where the compromises of a few selected machines outside your control (your route and exit nodes) can cause your privacy to be sacrificed even if every other node in the mix is honest. And it is subject to traffic rerouting in transit on the backbone, which is known to be done by at least one sophisticated attacker specifically in response to the fact that it is Tor traffic in the first place. That attacker, and presumably others, specifically reroutes Tor traffic through attack sites which use browser flaws to compromise the machines that originate the traffic.

Tor was a good design once; but the attacks on it are in place, sophisticated, only getting worse, and not easily detectable from the originating node. So I think that its usefulness is closer to its end than to its beginning. While Tor may still be good more than 90% of the time, I'm not willing to trust it in the long run. Nor am I willing to trust that people using it can keep their machines from getting compromised by reroutes to attack sites which are using zero-day exploits against their browsers. Most of them don't even fully disable scripts and cookies in their Tor browser sessions.

The dc-net solution requires you to trust only that there exists at least one other node (ANY participating node) that is not compromised; that's a strictly stronger guarantee than Tor. If it's built into the protocol then it involves no steps that many users will not do, nor steps that users will attempt but do wrongly. It is not dependent on the security of machines other than those directly participating, and does not expose machines to attack via a browser as Tor in normal use generally does.

Further, its guarantees are orthogonal to those provided by a (properly functioning) Tor network; With Tor alone, (if the critical path machines and your own remain uncompromised) you can't associate nodes with IP addresses, but if you're sniffing packet traffic you can associate inputs and outputs with particular nodes. With the DC-net alone, you can't associate inputs or outputs with particular nodes, but if you're sniffing packet traffic you can produce a list of the IP addresses of the nodes. So I claim the proper solution is to implement the DC-net as the "fundamental" basis of the protocol, and then let people use it over Tor if they want the extra layer of obfuscation and can correctly use Tor. That way, even if they fail at configuring Tor, or get unlucky with their Tor network routing, or fail in keeping their own machines secure while using Tor, they still have some fundamental amount of protection. And if they use Tor correctly, they get additional protection that the DC-net alone could not provide.

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

Honestly, I just don't need it, so I don't really feel the urge to create such a thing.(...)Still I believe it can be done and since it can be done, someone will do it one day

Ok then, so you prefer to sit and wait for someone to do it for you.

WowSo lazinessMuch not giving fuckSuch a shameWow

Wtf maybe you should contribute something on your own (code, money) instead of telling other people which type of unpaid work they should do for you in their free time.

My thoughts exactly. If you are serious about anonymity and privacy, PAY FOR IT. Cause you have this big problem of how do you test it to make sure it's working. I'm sure the EFF or some other non-profit could be found to hold some money to pay for development and testing.

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

Honestly, I just don't need it, so I don't really feel the urge to create such a thing.(...)Still I believe it can be done and since it can be done, someone will do it one day

Ok then, so you prefer to sit and wait for someone to do it for you.

WowSo lazinessMuch not giving fuckSuch a shameWow

Wtf maybe you should contribute something on your own (code, money) instead of telling other people which type of unpaid work they should do for you in their free time.

WTF, I already did. Look at my sig, genius.

And that is NOT what I am talking about. I am actually criticising piotr_n for coming to this thread and complaining, instead of coding it himself. And (as he confirmed himself) he could actually do it, he just does not care.

Tor is actually quite easy to bundle, and some other programs (like torchat) already do. I'd assume that someday there would be bitcoin clients offered with bundled tor.

I was looking at Orchid (a Tor library) today and saw Mike Hearn's name on a github pull request: https://github.com/subgraph/Orchid/pull/9 with the comment: "I need this fix for bitcoinj."

how about security? I think most exit nodes are under nsa controll, how could that improved?

I am pretty sure since bitcoind nodes support only tor interactions and many people run them in that state, their would be no reason to hit an exit node if you don't want to, since you would be routed to the bitcoind nodes on tor.

Even if you do hit an NSA controlled exit node, the worst they can do is act like a cancer node to you, and give you false data, and you send rejected transactions on the network.

Yes, I think CoinJoin should be a very good start. But do any really decentralised and fully working implementations of CoinJoin exist already? I don't think so and would be interested to know if they are.

I'm not aware of any either but don't let that deter you from using one of the already existing solutions even if they aren't perfect.

A decentralized CoinJoin will have difficulty forming transactions (including unequal or equal transaction amounts) that look like this if anyone can join:

A sharedcoin transaction will look something like this: https://blockchain.info/tx/e4abb15310348edc606e597effc81697bfce4b6de7598347f17c2befd4febf3b (picked at random). As you can see multiple inputs and outputs make the determining the actual sender and receiver more difficult.

The server does not need to keep any logs and transactions are only kept in memory for a short time. However If the server was compromised or under subpoena it could be force...

Because the way it must work is the users sign the transaction first with their requested outputs, then in the second round they sign their payments as inputs to the transaction. If the payment inputs are less than the total, then the transaction is invalid. There is no way to determine who cheated and rate limit them. Thus the saboteur can stomp on every attempt to create a CoinJoin transaction and destroy the decentralized system.

DarkCoin says they can solve this by charging a fee, but you will see I originally proposed that idea in the CoinJoin thread and the requirement is all the participants must be permanently identified and then must use divide-and-conquer to whittle down to who was the saboteur. But identification defeats the mixing!

Thus I have not yet seen a workable decentralized CoinJoin that can scale. And I don't expect one.

The very first post in the thread points out that decentralized versions take more work because of the anti-DOS proofing. A couple posts down (https://bitcointalk.org/index.php?topic=279249.msg2984051#msg2984051) I give some examples of how it can be done.

You're presuming a broken model that I don't believe anyone here has ever suggested. You'd always being the protocol by specifying the inputs in which you intend to sign. Signature authority over inputs is the principle scarcity that allows you to may the system dos-attack resistant. After the inputs are signed, outputs can be specified in a cheat proof way, and then the only avenue for disruption is refusing to sign which can be addressed by blacklisting your inputs (and other rate limiting tokens) and restarting.

[A couple posts down](https://bitcointalk.org/index.php?topic=279249.msg2984051#msg2984051) I give some examples of how it can be done.

And again in that post you admit there is a DOS problem. You didn't solve it. And you can't solve it in a decentralized setting unless you have non-ephemeral identification of the participants. Which is precisely the point of my prior post to which you are replying

Incorrect. What I wrote is functionally equivalent to what you described. The point is the transaction can be jammed in the final round.

Since you didn't see the equivalence let me explain it. I thought you were smart enough to deduce such things. I chose to let the signatures of inputs go in the second and final round and point to a transaction because I envisioned using ring signatures. And the transaction won't be valid (blockchain will reject it) if the inputs are less than the outputs, so my version is just as safe as yours. And the DOS problem is equivalent. Come on you are a math guy, you can surely see that without me needing to explain it you.

And if you think about it a while you will realize, by inverting the operations and using a ring signature, mine has advantages suchas that not all have to sign in the first round before proceeding to the second round (they get excluded from second round too). Yet the DOS issue remains in the final.

You'd always being the protocol by specifying the inputs in which you intend to sign. Signature authority over inputs is the principle scarcity that allows you to may the system dos-attack resistant. After the inputs are signed, outputs can be specified in a cheat proof way, and then the only avenue for disruption is refusing to sign which can be addressed by blacklisting your inputs (and other rate limiting tokens) and restarting.

Well now you see your error. You can reread my post again, and admit I was correct.

If a party fails to sign, everyone else is convinced that its because they are jamming the process (intentionally or maliciously) and then can all ban (ignore in the future) whatever costly identity they used to enter the mix, or — if there is no other mechanism— that particular txin which they used.

And exactly how do you propose to identify that adversary in a decentralized setting? ;) My point is you can't, at least not without breaking anonymity, and anonymity was the entire point of mixing.

And my post to which you are replying is in fact explaining the DOS (denial-of-service) is insoluble if you can't identify the participants in order to rate-limit them.And again in that post you admit there is a DOS problem. You didn't solve it. And you can't solve it in a decentralized setting unless you have non-ephemeral identification of the participants. Which is precisely the point of my prior post to which you are replying

You are asserting it, (over and over again) but it doesn't make it true. It was explained in adequate detail previously enough for other people to understand it and implement tools that address it.

Quote

Incorrect. What I wrote is functionally equivalent to what you described. The point is the transaction can be jammed in the final round.

It's actually not, since it's not actually possible in the Bitcoin protocol to do what (it sounds like) you're describing, but more importantly performing the operation in that order defeats the anti-dos. If you lead with the inputs they provide a trivial anti-dos mechanism.

Quote

And exactly how do you propose to identify that adversary in a decentralized setting? ;) My point is you can't, at least not without breaking anonymity, and anonymity was the entire point of mixing.

Because they fail to sign. There is no need to identify them beyond identifying their input coins to achieve rate limiting, and no need to identify the input/output correspondence.

I'll repeat it, since maybe other people are having problems following the link:

An example (using the blind signature approach, simplified for equal values) is that each participant cryptographically blinds their desired output, and then signs their blinded output using the keys from their intended inputs. They then present to the group their inputs (and assuming those inputs are not black-listed) everyone in the group blind-signs each of the outputs. Then everyone connects again with new connections (e.g. a new circuit in tor) and presents their unblinded outputs and their signatures. Now everyone knows that all of the provided outputs were from authorized parties— but not the correspondence. The transaction is composed and— back on their original connections— they all sign. If someone doesn't sign, it means they're jamming the process, everyone blacklists theirs inputs and automatically restarts. The network naturally rate limits them via the finite supply of available outputs. (of course, if you want you can attack other valuable identities to the first step, like coin burning or what have you, if the natural network rate limit isn't enough).

This is just one example of a way to address this. There are several other ones possible— and discussed early on in this thread. Other ones include publishing commitments and then if the process fails having everyone reveal their intended outputs (which they then discard and never use) in order to avoid being banned, or using an anonymous accumulator instead of blind signing to control access.

Keep your ad hominem attacks out of it please. I asked kindly for technical comments.

I think you misunderstand what an ad hominem attack is. If gmaxwell had called you are blithering fool, that would qualify. As it were, he pointed out that your posts have been incorrect and confused, and then backed it up with specifics. That's not attacking the man, that's attacking the content (which was full of errors and confused).

You might try answering gmaxwell's assertion that ratelimiting is, in fact, not an issue instead of merely stipulating that it is insoluble.

For my own part, I would question that there is a non-ephemeral identification of participants, namely by requiring the inputs first. The inputs would serve as an identification and if any problems were subsequently to arise, they could be blacklisted.

For my own part, I would question that there is a non-ephemeral identification of participants, namely by requiring the inputs first. The inputs would serve as an identification and if any problems were subsequently to arise, they could be blacklisted.

But if the inputs are really not connectable to the outputs could I jam the transaction by using outputs that add up to greater than my inputs?In this case could anyone work out that it was me that put in the outputs that made the transaction not balance?

But if the inputs are really not connectable to the outputs could I jam the transaction by using outputs that add up to greater than my inputs?In this case could anyone work out that it was me that put in the outputs that made the transaction not balance?

No, instead they prevent you from doing that in the first place.

E.g. in the blinded example: When you provide your inputs everyone sees your values, and you specify "this is a blinded X btc output" and they all sign that output with a key which corresponds to X btc, and obviously refuse to do so if your input isn't at least X. Later you reveal your output, and they know its value by which keys signed it.

This isn't to say that implementing any of this is interesting. The state machine to achieve success in all cases ends up very complicated. (This is also why I think that blinded but quasi-centeralized e.g. where a semi trusted party coordinates are probably more interesting for initial deployment).

And my post to which you are replying is in fact explaining the DOS (denial-of-service) is insoluble if you can't identify the participants in order to rate-limit them.

And again in that post you admit there is a DOS problem. You didn't solve it. And you can't solve it in a decentralized setting unless you have non-ephemeral identification of the participants. Which is precisely the point of my prior post to which you are replying

You are asserting it, (over and over again) but it doesn't make it true. It was explained in adequate detail previously enough for other people to understand it and implement tools that address it.

Quote

Incorrect. What I wrote is functionally equivalent to what you described. The point is the transaction can be jammed in the final round.

It's actually not, since it's not actually possible in the Bitcoin protocol to do what (it sounds like) you're describing, but more importantly performing the operation in that order defeats the anti-dos. If you lead with the inputs they provide a trivial anti-dos mechanism.

And precisely how do you identify which input is the adversary when the correlation of the inputs and the outputs is necessarily cryptographically blinded?

As far as I can see, you can't.

I am confident that now you see the functionally w.r.t. to anti-DOS of what I described and what you described are equivalent, i.e. any one who is the least bit mathematical can see that the salient mathematical foundation of CoinJoin is that the correlation between the inputs and outputs must be cryptographically blinded, thus it makes no difference mathematically for anti-DOS whether the inputs or outputs are specified in the first round of the protocol.

As for whether my proposed protocol of putting the outputs in the first round is implementable on the Bitcoin blockchain, it is irrelevant since we are talking about a general protocol here and an altcoin could be designed to allow a transaction where outputs and inputs can be signed to point to the transaction nonce (a hash of any number) plus the addresses of the inputs OR outputs. I didn't bother to check how Bitcoin signs the transactions, because it is conceptually irrelevant to our discussion. Perhaps in Bitcoin the signature of the transaction must include all the inputs AND outputs. The reason I presented my formulation (in fact I mentioned the ring signatures idea from Adam Back in the Zerocoin thread months ago in this thread) is because it is more powerful conceptually than one gmaxell described. I thought gmaxell would appreciate that since I think he is a math guy.

This is an extremely interesting idea. Could you elaborate on how the Zerocoin transaction stages map to the stages of CoinJoin transaction creation?

For non-decenteralized coincoin, you simply pass around a transaction and sign it. It's a single sequence and an atomic transaction, you'd make two loops through the users, one to discover the inputs and outputs, and another to sign them. There really aren't stages to it.

Making a decenteralized CoinJoin secure, private, and resistant to DOS attack (people refusing to sign in order to make it fail) is trickier... for the privacy and dos attack resistance you can use ZC:

Presume the participants for a transaction are sharing some multicast medium and can all communicate. They need to accomplish the task of offering up inputs (txid:vout) for inclusion in the transaction and then, in an unlinkable way, providing outputs to receive their coins.

Each participant connects and names bitcoin input(s), an address for change (if needed), and the result of performing a ZC mint transaction to add to the ZC accumulator. They sign all this with the keys for the corresponding inputs proving its theirs to spend.

Then all the parties connect again anonymously and provide ZC redeem transactions which specify where the resulting bitcoins should go.

Zerocoin (ZC) requires a trusted party to generate the parameters, thus it is the antithesis of decentralized, so you have a logical error above.

This isn't the only way to do this in a decentralized manner, the way to do it with blind signatures is fairly similar:

Each participant connects, names Bitcoin input(s), an address for change (if needed), a key for blind signing, and a blinded hash of the address they want paid. They sign all this with the keys for the corresponding inputs proving its theirs to spend.

Each participant then blind signs the blinded hashes of all participants (including themselves).

And so how can you correlate which input is the one who didn't blind sign all?

As far as I can see, you can't.

I've dug very deep (into cryptography research papers) lately into trying to find a way to delink inputs from outputs without a trusted party, and I have realized that mathematically it can't be done. It is a fundamental conceptualization.

The only way to delink without anti-DOS is to use an accumulator commitment scheme with common NP-hard parameters that can be presented in an NIZKP (non-interactive zero knowledge proof) which will always require a trusted party to generate the common parameters for the trapdoor math.

This is just one example of a way to address this. There are several other ones possible— and discussed early on in this thread. Other ones include publishing commitments and then if the process fails having everyone reveal their intended outputs (which they then discard and never use) in order to avoid being banned, or using an anonymous accumulator instead of blind signing to control access.

That isn't anti-DOS.

Each spender commits a hash of his intended output. Then everyone does the blinded protocol. If the blinded protocol fails, everyone including the adversary reveals the link between inputs and outputs, because by definition the output key must be an abundant resource so that it is not costly to reveal it and generate a new one to try again.

And precisely how do you identify which input is the adversary when the correlation of the inputs and the outputs is necessarily cryptographically blinded?As far as I can see, you can't.

The input is identified by the fact that it fails to sign a provably valid transaction.

Quote

And exactly how do you propose to identify that adversary in a decentralized setting? ;) My point is you can't, at least not without breaking anonymity, and anonymity was the entire point of mixing.

Quote

Because they fail to sign. There is no need to identify them beyond identifying their input coins to achieve rate limiting, and no need to identify the input/output correspondence.

...by the fact that they fail to sign.

Quote

I will quote from your more detailed description upthread.

You're now quoting from a different approach. I listed several. The one which I specifically identified in our discussion here used plain chaum blinded signature. (The others should work fine too— but if you mix things up its hard to have a coherent discussion)

Quote

Zerocoin (ZC) requires a trusted party to generate the parameters, thus it is the antithesis of decentralized, so you have a logical error above.

ZC initialized with an RSA UFO has no trusted initialization, in fact— they make the updates much larger but thats harmless for data not going in the blockchain. Additionally if you do use the efficient trusted initialization the ZC accumulator approach still has perfect zero knoweldge. Compromise of the state allows someone to make false proofs (dos attacks in this context). Though these points are not terribly relevant because I wasn't talking about the ZC approach.

Quote

And so how can you correlate which input is the one who didn't blind sign all?

Because they refuse to sign the transaction. Everyone knows that all the outputs provided in the transaction were the unique outputs provided by the inputting parties (because they have been signed by all participants). So they all know the transaction is valid.

(of course, if it fails before you finish the unblinding, — you explain below how thats handled)

Quote

I've dug very deep (into cryptography research papers) lately into trying to find a way to delink inputs from outputs without a trusted party, and I have realized that mathematically it can't be done. It is a fundamental conceptualization.The only way to delink without anti-DOS is to use an accumulator commitment scheme with common NP-hard parameters that can be presented in an NIZKP (non-interactive zero knowledge proof) which will always require a trusted party to generate the common parameters for the trapdoor math.

You've apparently not done much research at all, as you are not aware of RSA UFOs (which are described in some of the very first papers about those sorts of accumulators), you are not aware of non-trapdoor NIZK (e.g. fiat-shamir/random oracle only), and ... apparently you're not aware of anything as simple as a blind signature.

Quote

Each spender commits a hash of his intended output. Then everyone does the blinded protocol. If the blinded protocol fails, everyone including the adversary reveals the link between inputs and outputs, because by definition the output key must be an abundant resource so that it is not costly to reveal it and generate a new one to try again.

I'm glad you agree that the case where the protocol fails before all the blind signatures are collected is easily resolved. If it fails after transaction signing has begun, then—because the blind signatures assure everyone that the transaction was correct— you know the non-signer is the adversary.

But if the inputs are really not connectable to the outputs could I jam the transaction by using outputs that add up to greater than my inputs?In this case could anyone work out that it was me that put in the outputs that made the transaction not balance?

No, instead they prevent you from doing that in the first place.

E.g. in the blinded example: When you provide your inputs everyone sees your values, and you specify "this is a blinded X btc output" and they all sign that output with a key which corresponds to X btc, and obviously refuse to do so if your input isn't at least X. Later you reveal your output, and they know its value by which keys signed it.

Don't the inputs need to be signed to a specific block chain transaction?

Each participant connects, names Bitcoin input(s), an address for change (if needed), a key for blind signing, and a blinded hash of the address they want paid. They sign all this with the keys for the corresponding inputs proving its theirs to spend.

Each participant then blind signs the blinded hashes of all participants (including themselves).

Each participant then reconnects anonymously and discloses their unblinded values and all the signatures. Because all the participants can see all the signatures, they know all are authentic. They sign, and if they refuse to sign everyone is convinced that the refusing signer is attempting to jam and bans them.

And exactly how do you propose to identify that adversary in a decentralized setting? ;) My point is you can't, at least not without breaking anonymity, and anonymity was the entire point of mixing.

Quote

Because they fail to sign. There is no need to identify them beyond identifying their input coins to achieve rate limiting, and no need to identify the input/output correspondence.

...by the fact that they fail to sign.

Quote

I will quote from your more detailed description upthread.

You're now quoting from a different approach. I listed several. The one which I specifically identified in our discussion here used plain chaum blinded signature. (The others should work fine too— but if you mix things up its hard to have a coherent discussion)

I will not respond to this part of your reply at this time, so as to not further confuse the line of discussion above and below.

Zerocoin (ZC) requires a trusted party to generate the parameters, thus it is the antithesis of decentralized, so you have a logical error above.

ZC initialized with an RSA UFO has no trusted initialization, in fact— they make the updates much larger but thats harmless for data not going in the blockchain. Additionally if you do use the efficient trusted initialization the ZC accumulator approach still has perfect zero knoweldge. Compromise of the state allows someone to make false proofs (dos attacks in this context). Though these points are not terribly relevant because I wasn't talking about the ZC approach.

I was aware of the RSA UFO claim from the ZC research paper, but Adam Back's comments seem to imply (?) it isn't a realistic option (so to save time I trusted what I interpreted to be his expert opinion). I just now skimmed this research paper:

And so how can you correlate which input is the one who didn't blind sign all?

Because they refuse to sign the transaction. Everyone knows that all the outputs provided in the transaction were the unique outputs provided by the inputting parties (because they have been signed by all participants). So they all know the transaction is valid.

I've dug very deep (into cryptography research papers) lately into trying to find a way to delink inputs from outputs without a trusted party, and I have realized that mathematically it can't be done. It is a fundamental conceptualization.The only way to delink without anti-DOS is to use an accumulator commitment scheme with common NP-hard parameters that can be presented in an NIZKP (non-interactive zero knowledge proof) which will always require a trusted party to generate the common parameters for the trapdoor math.

You've apparently not done much research at all, as you are not aware of RSA UFOs (which are described in some of the very first papers about those sorts of accumulators), you are not aware of non-trapdoor NIZK (e.g. fiat-shamir/random oracle only), and ... apparently you're not aware of anything as simple as a blind signature.

I was aware of RSA UFOs as stated above. I was also aware of the Fiat-Shamir research paper below where the square roots (on mod n curve) stored on a smart card can't be factored (mod n) by the verifier (in polynomial time) and thus these roots are hidden by multiple interactive challenge rounds that employ a mathematical product that hides the actual values but requires the sum to be equal, and this can be converted to non-interactive (NI) via the Fiat-Shamir transformation by employing a one-way cryptographic hash function to issue the random challenges.

Each spender commits a hash of his intended output. Then everyone does the blinded protocol. If the blinded protocol fails, everyone including the adversary reveals the link between inputs and outputs, because by definition the output key must be an abundant resource so that it is not costly to reveal it and generate a new one to try again.

I'm glad you agree that the case where the protocol fails before all the blind signatures are collected is easily resolved.

How is that not a DOS attack on the input signatures that were already made?

Zerocoin (ZC) requires a trusted party to generate the parameters, thus it is the antithesis of decentralized, so you have a logical error above.

ZC initialized with an RSA UFO has no trusted initialization, in fact— they make the updates much larger but thats harmless for data not going in the blockchain. Additionally if you do use the efficient trusted initialization the ZC accumulator approach still has perfect zero knoweldge. Compromise of the state allows someone to make false proofs (dos attacks in this context). Though these points are not terribly relevant because I wasn't talking about the ZC approach.

I was aware of the RFC UFO claim from the ZC research paper, but Adam Back's comments seem to imply (?) it isn't a realistic option (so to save time I trusted what I interpreted to be his expert opinion). I just now skimmed this research paper:

On further reading, apparently UFOs are impractical because there isn't an entropy source that can be trusted to be random over such large domains. Please feel free to correct me if I am mistaken about the requirement.

We shift our unreliability of trust from unknowing if someone intercepted the computation of N = PQ to the unreliability of unknowing whether our input entropy could be attacked at any time in the future.

The research paper suggests in "2.1 On the generation of public random strings" to use stock market data, but there is hidden periodicity in the stock market data:

E.g. in the blinded example: When you provide your inputs everyone sees your values, and you specify "this is a blinded X btc output" and they all sign that output with a key which corresponds to X btc, and obviously refuse to do so if your input isn't at least X. Later you reveal your output, and they know its value by which keys signed it.

Don't the inputs need to be signed to a specific block chain transaction?

Eventually, after the transaction is formed according to the blind signatures.

Quote

Could you please explain to me how an input can sign a "provably valid" block chain transaction without knowing the outputs?

At the point they sign the transaction they know the outputs (or else the transaction wouldn't yet exist).

Quote

I was aware of the RSA UFO claim from the ZC research paper, but Adam Back's comments seem to imply (?) it isn't a realistic option (so to save time I trusted what I interpreted to be his expert opinion). I just now skimmed this research paper

Zerocoin itself was already not realistic inside Bitcoin due (among other reasons) to the large transaction that you have to put into the blockchain. UFOs make them larger by a small multiple. Sending a few extra tens of KB outside of Bitcoin probably isn't an issue.

Quote

On further reading, apparently UFOs are impractical because there isn't an entropy source that can be trusted to be random over such large domains. Please feel free to correct me if I am mistaken about the requirement.

WTF?! Like in everything else you use a cryptographically strong PRNG which holds as long as some underlying hash function holds, and if the hash function is distinguishable with unknown inputs from a random oracle you're already hosed in every other protocol (including your DSA signatures).

Quote

Compromise of the trusted PQ in ZC allows the trusted party to double-spend coins. Thus I assume for the CoinJoin case, it would cause the number of outputs to not match inputs, so thus a form of DOS.

Yes? and so what? First— I note that you're continuing to waste time discussing the more complicated ZC thing when that wasn't what I was speaking about and do not recommend people implement (I noted it as a possibility for those were excited about ZC to find a potential application for the technology). Secondly— who cares if maybe someone kept a trapdoor and could just DOS attack? If you were really worried about that case you can just keep around a couple parameter sets, track how often you fail in each case and prefer ones where you've never been dos attacked (with the users taking a majority decision or something like that).

And so how can you correlate which input is the one who didn't blind sign all?

Because they refuse to sign the transaction. Everyone knows that all the outputs provided in the transaction were the unique outputs provided by the inputting parties (because they have been signed by all participants). So they all know the transaction is valid.

But the DOS can occur during the blinding signing of the outputs.

Great. If the DOS attack occurs during the blind signing of the output tokens then everything is totally trivial then. Since every inputting user is required to blind sign everyone else output token, if they don't— you know who's jamming the process and you ban them.

Here is an overview of all the places a user could refuse to participate further:

(0) If a user refuses to sign an initial introduction message that specifies their input and their blinded output (and other parameters like blind signing keys to be used), then they're just not participating as producing that message is how they join in.

(1) If a user refuses to sign the blinded outputs of all the other users their inputs are blacklisted as the blind signing of everyone's output tokens is not anonymous (relative to inputs).

(2) If a user (now reconnected anonymously relative to inputs) refuses to reveal their unblinded outputs, this attempt is aborted, all honest users reveal their blinding factors and withholder is deanonymized and their inputs banned.

If we've made it this far we have a set of outputs which were provably created by the people who created the inputs, though we don't know the correspondence. We can form a transaction and know that the transaction matches their wishes. So we do.

(3) If any input does not sign for the resulting transaction we blacklist them because we know the transaction is accurate at this point.

I was aware of the RSA UFO claim from the ZC research paper, but Adam Back's comments seem to imply (?) it isn't a realistic option (so to save time I trusted what I interpreted to be his expert opinion). I just now skimmed this research paper

Zerocoin itself was already not realistic inside Bitcoin due (among other reasons) to the large transaction that you have to put into the blockchain. UFOs make them larger by a small multiple. Sending a few extra tens of KB outside of Bitcoin probably isn't an issue.

I agree the extra size is not likely a factor for use offchain such as a decentralized CoinJoin.

Zerocoin is also not realistic inside Bitcoin because if a trusted party could create unlimited Bitcoins, that would violate basic principle of Bitcoin. That same trust issue may or may not apply if used in CoinJoin.

I elaborate below why am not convinced UFOs would solve that trust issue if used in Bitcoin.

On further reading, apparently UFOs are impractical because there isn't an entropy source that can be trusted to be random over such large domains. Please feel free to correct me if I am mistaken about the requirement.

WTF?! Like in everything else you use a cryptographically strong PRNG which holds as long as some underlying hash function holds, and if the hash function is distinguishable with unknown inputs from a random oracle you're already hosed in every other protocol (including your DSA signatures).

I would need to look and think more deeply about the math he showed there, but seemed like he was saying that we can predict the occurrence of primes in a product probabilistically thus I am having the conjectured thought (to explore more when I have more time) that the requirements on the period (in the applicable domain space) over which the assumption that the (approximation to the) Random Oracle model must hold true may be implicitly much more vast than when we apply hash functions in Z. I am curious to think more about what he actually proved and didn't prove.

I think there is much more depth to this than we can go into now. And I haven't had the time yet to wrap my mind completely around the math in that paper on UFOs.

Why don't we ask Adam Back? He is a neutral party and I think he may know more about the deeper implications of the mathematical assumptions in that RSA-UFO paper.

Or we can simply agree to stop discussing about Zerocoin or RSA-UFOs, which would be fine by me.

Compromise of the trusted PQ in ZC allows the trusted party to double-spend coins. Thus I assume for the CoinJoin case, it would cause the number of outputs to not match inputs, so thus a form of DOS.

Yes? and so what? First— I note that you're continuing to waste time discussing the more complicated ZC thing when that wasn't what I was speaking about and do not recommend people implement (I noted it as a possibility for those were excited about ZC to find a potential application for the technology).

I am replying to your comments. If you stop talking about Zerocoin, then I can stop responding about Zerocoin.

I am curious about Zerocoin as a solution for CoinJoin since I am fairly certain that your proposed protocol for CoinJoin can be DOS-attacked (see my reason below).

Secondly— who cares if maybe someone kept a trapdoor and could just DOS attack? If you were really worried about that case you can just keep around a couple parameter sets, track how often you fail in each case and prefer ones where you've never been dos attacked (with the users taking a majority decision or something like that).

That is a very interesting idea! Since knowing PQ doesn't allow you to snoop on the other participants' anonymity, that might be workable.

And then we don't need RSA-UFOs.

I don't see why you need to track how often there is failure. You simply discard a PQ where there was a DOS attack, because that is 100% evidence that PQ is compromised.

E.g. in the blinded example: When you provide your inputs everyone sees your values, and you specify "this is a blinded X btc output" and they all sign that output with a key which corresponds to X btc, and obviously refuse to do so if your input isn't at least X. Later you reveal your output, and they know its value by which keys signed it.

Don't the inputs need to be signed to a specific block chain transaction?

Eventually, after the transaction is formed according to the blind signatures.

Quote

Could you please explain to me how an input can sign a "provably valid" block chain transaction without knowing the outputs?

At the point they sign the transaction they know the outputs (or else the transaction wouldn't yet exist).

And so how can you correlate which input is the one who didn't blind sign all?

Because they refuse to sign the transaction. Everyone knows that all the outputs provided in the transaction were the unique outputs provided by the inputting parties (because they have been signed by all participants). So they all know the transaction is valid.

But the DOS can occur during the blinding signing of the outputs.

Great. If the DOS attack occurs during the blind signing of the output tokens then everything is totally trivial then. Since every inputting user is required to blind sign everyone else output token, if they don't— you know who's jamming the process and you ban them.

Here is an overview of all the places a user could refuse to participate further:

(0) If a user refuses to sign an initial introduction message that specifies their input and their blinded output (and other parameters like blind signing keys to be used), then they're just not participating as producing that message is how they join in.

(1) If a user refuses to sign the blinded outputs of all the other users their inputs are blacklisted as the blind signing of everyone's output tokens is not anonymous (relative to inputs).

(2) If a user (now reconnected anonymously relative to inputs) refuses to reveal their unblinded outputs, this attempt is aborted, all honest users reveal their blinding factors and withholder is deanonymized and their inputs banned.

If we've made it this far we have a set of outputs which were provably created by the people who created the inputs, though we don't know the correspondence. We can form a transaction and know that the transaction matches their wishes. So we do.

(3) If any input does not sign for the resulting transaction we blacklist them because we know the transaction is accurate at this point.

I really cannot understand why you find this difficult to understand.

Two orthogonal issues.

First, an adversary could make a 1 Satoshi input and DOS on the (3) step. You ban that address but adversary has billions more at neglible cost.

I suppose you could set a minimum input amount to avoid this. But still no problem for the adversary, he passes his BTC through a mixer can comes to hit you again and again.

I am sorry to bring you bad news Gregory but with a non-atomic operation in the decentralized case you can always be DOS-attacked. Zerocoin may be the solution?

But if the inputs are really not connectable to the outputs could I jam the transaction by using outputs that add up to greater than my inputs?In this case could anyone work out that it was me that put in the outputs that made the transaction not balance?

No, instead they prevent you from doing that in the first place.

E.g. in the blinded example: When you provide your inputs everyone sees your values, and you specify "this is a blinded X btc output" and they all sign that output with a key which corresponds to X btc, and obviously refuse to do so if your input isn't at least X. Later you reveal your output, and they know its value by which keys signed it.

Appears you are saying that as a participant when I provide my input, I also specify the amount of my output?

Two orthogonal issues.First, an adversary could make a 1 Satoshi input and DOS on the (3) step. You ban that address but adversary has billions more at neglible cost.I suppose you could set a minimum input amount to avoid this. But still no problem for the adversary, he passes his BTC through a mixer can comes to hit you again and again.I am sorry to bring you bad news Gregory but with a non-atomic operation you can always be DOS-attacked. Zerocoin may be the solution?

Transaction fees and confirmation times should slow down the attacker.

Two orthogonal issues.First, an adversary could make a 1 Satoshi input and DOS on the (3) step. You ban that address but adversary has billions more at neglible cost.I suppose you could set a minimum input amount to avoid this. But still no problem for the adversary, he passes his BTC through a mixer can comes to hit you again and again.I am sorry to bring you bad news Gregory but with a non-atomic operation you can always be DOS-attacked. Zerocoin may be the solution?

Transaction fees and confirmation times should slow down the attacker.

As for slowing down, the adversary can have many parallel addresses in play so I don't think so.

Transaction fees might work if they are significant enough. I haven't studied how much the tx fees are in Bitcoin much. I think I read that certain txs can be 0 for some cases?

If the adversary is mixing through CoinJoin transactions (hehe, uses what he also DOS-attacks against itself), then the blockchain tx fee is going to be shared between all parties of the CoinJoin transaction, so could it be insignificant?

Edit: I've just realized the adversary can eliminate the transaction fees too, by spending those banned amounts as he normally would (e.g. day trading), thus he doesn't incur any extra cost.

Edit#2: unless all decentralized CoinJoins share their ban lists (which is quite impractical to achieve as it is the antithesis of decentralization), adversary can just round-robin through them.

Surely you understand that the word "unless" means that if UFOs are not a solution,

Actually I think they're fine for this without the UFOs, I only brought them up because you were insisting things that were add odds with their eAppears you are saying that as a participant when I provide my input, I also specify the amount of my output?

I'm sometimes reading this topic, occasionally, and it seems always the same. Actually, its getting worse.Like with almost everything: plenty of ideas, but no solution whatsoever.

As for this specific topic, it basically seems like the level of the misery is just increasing.My advise: talk less, do more - it will solve all your problems, I promise!

Why do people even care to waste their time on pointless discussions?I could have saved so much of my own time, if I had only known an answer to such a stupid question :)I guess it must be some kind of entertainment, like watching TV, because I cannot believe someone would be wasting his time on this kind of pointless forum arguments, though still thinking that he actually somehow helps the mankind.We are talking about tens of pages of a "technical" topic (and not only this one!), lasting for years, with practically no actual applications - it must be just an entertainment, what else?Unless it's a new kind of science: a theoretical engineering... Though I would still rather count it as a stupid kind of philosophy :)

Also my statement that the CoinJoin protocol can be DOS-attacked was correct.

It was a bit difficult to explain these facts w.r.t. to gmaxell's semi-coherent, incomplete explanations of his protocol. But I think I was able to help him to specify the essential requirements of his protocol.

As for this specific topic, it basically seems like the level of the misery is just increasing.My advise: talk less, do more - it will solve all your problems, I promise!

The solution was provided by gmaxell. Use Zerocoin which is an atomic operation from inputs -> available outputs. But it won't work for Bitcoin's current block chain design, because even if we could (which we currently can't) we don't want to put the Zerocoin accumulator on the block chain because we don't want to trust the PQ thus we want to the accumulator to have a preset short-term lifespan and all inputs and outputs must specify themselves with that time limit. However this can't work in Bitcoin because inputs have to sign the output addresses. Thus in Bitcoin the specification of the output addresses would make it a non-atomic operation thus it can be DOS-attacked.

The solution for an altcoin (or Bitcoin if we can make such a radical change) is to make the transaction id a nonce and have the inputs and outputs sign that nonce. If the outputs are greater than inputs, then the transaction is invalid. In the rare event the outputs are greater than inputs, then we know to throw away and don't reuse the Zerocoin accumulator's PQ (because its trust is compromised) and try again.

Could someone kindly give a status update on when will we have a real-world, usable CoinJoin (besides the implementation on Blockchain.info)? This thread is huge, and I'm sure many casual readers would like to see a tl;dr to learn will this result in a usable client soon, or what's the plan?

I found the thread when reading this article from 7 months ago. What has happened since?http://bitcoinmagazine.com/6630/trustless-bitcoin-anonymity-here-at-last/

I find it a good idea to 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. Hope someone will manage it!

Could someone kindly give a status update on when will we have a real-world, usable CoinJoin (besides the implementation on Blockchain.info)? This thread is huge, and I'm sure many casual readers would like to see a tl;dr to learn will this result in a usable client soon, or what's the plan?

I found the thread when reading this article from 7 months ago. What has happened since?http://bitcoinmagazine.com/6630/trustless-bitcoin-anonymity-here-at-last/

can someone kindly give a status update when we will havemoney distributed to developers to work on a free and fair and decentralized coin join?

Could someone kindly give a status update on when will we have a real-world, usable CoinJoin (besides the implementation on Blockchain.info)? This thread is huge, and I'm sure many casual readers would like to see a tl;dr to learn will this result in a usable client soon, or what's the plan?

I found the thread when reading this article from 7 months ago. What has happened since?http://bitcoinmagazine.com/6630/trustless-bitcoin-anonymity-here-at-last/

I'm still actively working on the implementation I have started Coinmux (http://coinmux.com). I have taken a break for the last month after spending 3+ months working on it nights and weekends. Hopefully there is a Bitcoin God that wants to offer me a job to work on it full time. :)

@solex, I don't know if it's ever been articulated. That and the fact that the coins haven't moved was basically my gripe, not a specific jab at @nanobit (although, this is open-source software developed by volunteers: asking for time estimates is bad form).

I'd be curious to know what a "complete" implementation is. I'm guessing no one other than the owners of the donated BTC can say for sure... and AFAIK, they haven't said yet.

The OP mentions "complete", which I imagine would be a coinjoin implementation which would be considered by Core Dev worthy of inclusion in the reference client (needing cosmetic, standardizing and/or translation changes or only). Now this may remain a theoretical assessment if the goal is to see 3rd party implementations such as blockchain.info's.

Coinmux *seems* very good, and must be a front-runner, subject to informed criticism such as the input from Cryddit.

@solex, I don't know if it's ever been articulated. That and the fact that the coins haven't moved was basically my gripe, not a specific jab at @nanobit (although, this is open-source software developed by volunteers: asking for time estimates is bad form).

I'd be curious to know what a "complete" implementation is. I'm guessing no one other than the owners of the donated BTC can say for sure... and AFAIK, they haven't said yet.

The OP mentions "complete", which I imagine would be a coinjoin implementation which would be considered by Core Dev worthy of inclusion in the reference client (needing cosmetic, standardizing and/or translation changes or only). Now this may remain a theoretical assessment if the goal is to see 3rd party implementations such as blockchain.info's.

Coinmux *seems* very good, and must be a front-runner, subject to informed criticism such as the input from Cryddit.

@solex, I don't know if it's ever been articulated. That and the fact that the coins haven't moved was basically my gripe, not a specific jab at @nanobit (although, this is open-source software developed by volunteers: asking for time estimates is bad form).

Agreed.

I'll not take the "seems" statement as an insult. :) Coinmux has got quite a way to go from where it is now to where i envision it when finished. And if "complete" means that the implementation is merged into the reference client, i'll never get there as i did not write it in C/C++ (and i'd probably end up writing some pretty shitty C/C++ anyway).

I'll not take the "seems" statement as an insult. :) Coinmux has got quite a way to go from where it is now to where i envision it when finished. And if "complete" means that the implementation is merged into the reference client, i'll never get there as i did not write it in C/C++ (and i'd probably end up writing some pretty shitty C/C++ anyway).

My IT experience is not in the area which means I can determine for sure how good it is. It sounds good!! :-)Shouldn't have to be ready for merging, or in c++, and that's why I mentioned translating. It is the prototype which matters.

Could someone kindly give a status update on when will we have a real-world, usable CoinJoin (besides the implementation on Blockchain.info)? This thread is huge, and I'm sure many casual readers would like to see a tl;dr to learn will this result in a usable client soon, or what's the plan?

I found the thread when reading this article from 7 months ago. What has happened since?http://bitcoinmagazine.com/6630/trustless-bitcoin-anonymity-here-at-last/

I'm still actively working on the implementation I have started Coinmux (http://coinmux.com). I have taken a break for the last month after spending 3+ months working on it nights and weekends. Hopefully there is a Bitcoin God that wants to offer me a job to work on it full time. :)

Themgp, that looks really interesting! I'm sure others wish you could work on it full time, too! :) How far away is it from being usable for an average Bitcointalker?

Was the plan to pay 100% to the author of the first complete implementation, or for piece-work in progress?

Any payouts would need to be discussed with the other signers, but my thinking had been to pay most of it to to the most substantive complete and usable implementation, and partial amounts to smaller efforts (e.g. people who built toy tools and things only a developer could love). I had also planned on doing the payout itself as a coinjoin, and using a small bit of the funds to pay people to join into the coinjoin. :)

Could someone kindly give a status update on when will we have a real-world, usable CoinJoin (besides the implementation on Blockchain.info)? This thread is huge, and I'm sure many casual readers would like to see a tl;dr to learn will this result in a usable client soon, or what's the plan?

I found the thread when reading this article from 7 months ago. What has happened since?http://bitcoinmagazine.com/6630/trustless-bitcoin-anonymity-here-at-last/

I'm still actively working on the implementation I have started Coinmux (http://coinmux.com). I have taken a break for the last month after spending 3+ months working on it nights and weekends. Hopefully there is a Bitcoin God that wants to offer me a job to work on it full time. :)

Themgp, that looks really interesting! I'm sure others wish you could work on it full time, too! :) How far away is it from being usable for an average Bitcointalker?

The main problem right now is getting an available set of users to do a CoinJoin - the idea doesn't work if no one is using it. I think if i had a few weeks of solid work on Coinmux, it would be something where a user with a general understanding of bitcoin addresses and public/private keys that wanted to increase their privacy would want to use it. Hopefully I can find the time soon.

The alpha version of the coinjoin is just barely working but is allowing us to test the basic usability concepts, we're polishing it during next days, and the wallet is going to take some time to come out of alpha/beta, nonetheless people is playing with it both in testnet and mainnet.

The coinjoin now is simple two people coinjoin, as such we just make sure the 2 parties are the only ones who know the outputs correspondence, no need to hide from each other.

This is accomplished by talking over an unsecured channel where each peer publishes their pubkey with coinjoin announces, then others will answer doing ecdh, the initiator will choose one and they will continue talking to each other till they reach an agreement.

Our usability goes like this:

Anyone can set (a branch or pocket in) their wallet in "mixing" state, meaning it will be listening for coinjoin offers to mix available funds into new addresses.

For people sending, the wallet always tries to mix by announcing a coinjoin for the send value. If it can't mix it will send anyways in 60 seconds (at the moment).

Our idea is that this simple form of coinjoin can take off then we can add more complex coinjoin announcements or protocols. It is fully integrated in the normal workings of the wallet and it should work with other features like above you can see a coinjoin that went together with a stealth since the user is just sending stealth.

It seems to work pretty all right as long as at least a few wallets are mixing, and even if the current implementation is almost the simplest trustless mixing implementation i hope you can appretiate the potential.

Also looking forward to implement more advanced forms of coinjoin although our focus now would be to finish off what we have so it will be solid and easily extendable as a platform for development of other protocols. Also to note other wallets or tools can definitely join the same lobby and join together with darkwallets, but there is none yet, we plan to at least make one such simple tool.

Is there a central server involved in your implementation? I'm not trying to spread FUD, it's just there is conflicting information out there on the net. What you describe here sounds like it is p2p. Where are the announce messages posted?

how much is libbitcoin (http://libbitcoin.dyne.org/) (Bitcoin core implementation of Dark Wallet as I understand so far) compatible to "Bitcoin Core" the reference implementation of the Bitcoin protocol?

as I understood central servers are necessary like the Electrum central servers. are they Open Source software? where can I find this implementation? until now the client is Open Source but is the server code also available?

Is there a central server involved in your implementation? I'm not trying to spread FUD, it's just there is conflicting information out there on the net. What you describe here sounds like it is p2p. Where are the announce messages posted?

The clients meet in a lobby, that right now is the gateway they connect for other services. This works as an irc room. We're not making security assumptions there and the clients encrypt for the channel (useless for public announcement channel like this case) and then for the peer (using curve25519 dh).

What there is not is a pool, all mixing is coinjoin and the funds would never leave the client till signed together with someone.

Clients are sharing public keys and will engage in private communications after the initial announce, for now always through the "chat". Nothing is cleartext and the server has no role other as work like a broadcast medium with channel selection.

The gateway servers are now isolated but the plan soon is have them federate over a tuple space (probably through python entangled) (so anyone can join through tuple space instead of the websocket channel)

The clients can later choose other transports, as our protocol is purely logical.

how much is libbitcoin (http://libbitcoin.dyne.org/) (Bitcoin core implementation of Dark Wallet as I understand so far) compatible to "Bitcoin Core" the reference implementation of the Bitcoin protocol?

as I understood central servers are necessary like the Electrum central servers. are they Open Source software? where can I find this implementation? until now the client is Open Source but is the server code also available?

About how compatible it is, I can't really answer myself just that it should be following the bitcoin protocol and we don't have any "propietary" extensions or anything like that. Of course it's going to need heavy testing, auditing etc and we are open and wellcome anyone that helps on that.

About servers, yes the model is similar to electrum. Since the server is opensource you can install it in you server, and in the future there is nothing against you can just run it in you laptop or some parts of it, ie we have no long running assumption everyone *has to be connected to our lobby or to a server*.

We're soon releasing more installers and howtos about server configuratiojn or autonomous config by installing everything (or some part) in your computer.

Edit2: We have a thread for discussing DarkWallet technicals: https://bitcointalk.org/index.php?topic=592493.0. Will be better if we leave this thread for coinjoin specifics and do any dw specifics there.

Our approach does depend that different wallets can find a common medium to broadcast for coinjoin announces.

Other than that, the technique doesn't depend on the server itself, our mechanics is like ctx: https://gist.github.com/luke-jr/5409899 but we don't do it over the bitcoin network.

So the clients, after having chosen a common place to announce, in our case our gateway lobby:

0. Some are listening for offers1: Send announcements to start a join (now looking for a peer, but could look for more), with a pubkey (now its using the same one, but can be one per-announcement and will be).2. Other peers answer over ecdh, they will both offer inputs outputs, sign and broadcast over the private encrypted channel.

We believe the base we have can now have more hardened approaches tested, we provide a framework. This is a medium where we can do cryptographers dinner, or dissent protocols. This is just the beginning but it's a minimum that should work for getting the whole thing running.

Our goal is now apply the minimum necessary improvements, so on release this will also be making some claims about privacy, it's not making them right now, we're just offering information about where we are, so together with you people we can make it best.

We also invite other's to join forces and implement their techniques on our platform.

Edit: Added more detailed information about how we do it right now at: https://wiki.unsystem.net/index.php/DarkWallet/CoinMixing#Alpha_mixer

@caedes, why not have a peer-to-peer broadcast-flood channel for announcing joint transaction availability? Maybe even reuse one that is already available, well maintained, and has known security properties, like say the bitcoin network itself? And then do direct connections to the followon stages?

@caedes, why not have a peer-to-peer broadcast-flood channel for announcing joint transaction availability? Maybe even reuse one that is already available, well maintained, and has known security properties, like say the bitcoin network itself? And then do direct connections to the followon stages?

@caedes, why not have a peer-to-peer broadcast-flood channel for announcing joint transaction availability? Maybe even reuse one that is already available, well maintained, and has known security properties, like say the bitcoin network itself? And then do direct connections to the followon stages?

Yes as genjix says we're waiting for specific proposal of how to approach it, when we designed the system that was the idea that we could use the bitcoin network to overcome some of the adversary problems.

extremely interesting thread...what struck my eye was the slow validations which can cause a major clog with transactions when Dark Coin (based off of CoinJoin) gets bigger, right? The more coins transacted the slower the confirmations am I right in saying that?

No, not in a meaningful sense. Validation is very cheap. You do run into block size limits if you're trying to transact too much at once, but any privacy system is limited in its privacy by transaction volume.

"Dark Coin" really strikes me as pointless. The whole idea in coinjoin is that coinjoin is already part of the design of Bitcoin. There is no advantage in having a new and different system. If you're going to do something incompatible, losing Bitcoin's network effect in the process, then you can do something much stronger.

It also depresses me somewhat to see people talking about darkcoin (or even zerocoin/zerocash) when bytecoin (https://bytecoin.org/) has a privacy system with much better properties than CoinJoin (it's similar to CJ except you safely join with offline coin holders, and all users are participants), something made possible by the fact that it doesn't have to fit within the existing Bitcoin network, and it's completely practical, reasonably performant and deployed for some time now. But strangely, it's virtually unheard of... Bytecoin's privacy properties are in some sense weaker than zerocoin's— since its like a supercharged coinjoin— but the cryptography is much stronger and much more efficient, so in practice I'd expect it to have better anonymity just due to it being much more practical (also as evidence to it existing as a deployed system). ... so yea, if you actually are interested in privacy technology in a non-bitcoin system, Bytecoin seems to have pretty much nailed it.

It also depresses me somewhat to see people talking about darkcoin (or even zerocoin/zerocash) when bytecoin (https://bytecoin.org/) has a privacy system with much better properties than CoinJoin (it's similar to CJ except you safely join with offline coin holders, and all users are participants), something made possible by the fact that it doesn't have to fit within the existing Bitcoin network, and it's completely practical, reasonably performant and deployed for some time now. But strangely, it's virtually unheard of... Bytecoin's privacy properties are in some sense weaker than zerocoin's— since its like a supercharged coinjoin— but the cryptography is much stronger and much more efficient, so in practice I'd expect it to have better anonymity just due to it being much more practical (also as evidence to it existing as a deployed system). ... so yea, if you actually are interested in privacy technology in a non-bitcoin system, Bytecoin seems to have pretty much nailed it.

Thanks for introducing me to Bytecoin/CryptoNote. Some solid cryptography being used (in theory) and some great improvements over bitcoin. Unfortunately the fact that there is another coin called bytecoin (http://bytecoin.biz/) is very confusing and bytecoin doesn't really have any formal documentation other than this page (https://wiki.bytecoin.org/wiki/Protocol_rules). Time to do some source code reading!

Thanks for introducing me to Bytecoin/CryptoNote. Some solid cryptography being used (in theory) and some great improvements over bitcoin. Unfortunately the fact that there is another coin called bytecoin (http://bytecoin.biz/) is very confusing and bytecoin doesn't really have any formal documentation other than this page (https://wiki.bytecoin.org/wiki/Protocol_rules). Time to do some source code reading!

Yea, the Bytecoin/Bytecoin thing caused me to not notice it for a long time.

The cryptographically interesting Bytecoin has a reasonable whitepaper: https://bytecoin.org/old/whitepaper.pdf Some of the things it does appear to be pointless or ill-advised to me and I would have counciled otherwise— but as far as the privacy aspect goes, the ring signature approach appears top notch. The privacy depends on the decisional DH problem, so perhaps you could argue that its privacy has a slightly weaker cryptographic story than the basic discrete log stuff (computational DH) but in the curve they're using its believed to be equally strong. In any case, anything that has reduced the privacy question to asking about cryptographic assumptions has gone pretty good.

Sorry for the OT tangent here. Though there may be some good bitcoin-relevant privacy things to mine out of the bytecoin design.

Thanks for introducing me to Bytecoin/CryptoNote. Some solid cryptography being used (in theory) and some great improvements over bitcoin. Unfortunately the fact that there is another coin called bytecoin (http://bytecoin.biz/) is very confusing and bytecoin doesn't really have any formal documentation other than this page (https://wiki.bytecoin.org/wiki/Protocol_rules). Time to do some source code reading!

Yea, the Bytecoin/Bytecoin thing caused me to not notice it for a long time.

The cryptographically interesting Bytecoin has a reasonable whitepaper: https://bytecoin.org/old/whitepaper.pdf Some of the things it does appear to be pointless or ill-advised to me and I would have counciled otherwise— but as far as the privacy aspect goes, the ring signature approach appears top notch. The privacy depends on the decisional DH problem, so perhaps you could argue that its privacy has a slightly weaker cryptographic story than the basic discrete log stuff (computational DH) but in the curve they're using its believed to be equally strong. In any case, anything that has reduced the privacy question to asking about cryptographic assumptions has gone pretty good.

Sorry for the OT tangent here. Though there may be some good bitcoin-relevant privacy things to mine out of the bytecoin design.

It's hard to believe you're not a major bytecoin holder of some sort? Monero is a fork without the massive premine/instamine/slowmine without release whatever it was of bytecoin, I imagine your opinion about it is the same if they share cryptonote?

It's hard to believe you're not a major bytecoin holder of some sort? Monero is a fork without the massive premine/instamine/slowmine without release whatever it was of bytecoin, I imagine your opinion about it is the same if they share cryptonote?

As hard as it is to believe, people other than me do occasionally have really good ideas. :) ... (No, I'd only heard about it a couple months ago and looked into it in depth until the last week). I think all these altcoins are horribly ill-advised in their altcoinness. You're in the wrong subforum and thread if you want to talk about cryptocurrency speculation— my interest here is just in the techniques— and I'm not going to credit some random code aping fork for other people's work when talking about them.

(In case anyone had the impression that I thought bytecoin was all love and wonder: the implementation is currently really immature and somewhat buggy— and perhaps not likely to improve if its authors are now getting voted off the island in a fork. The POW is very slow to validate, and seems generally ill-advised to me (see https://download.wpsoftware.net/bitcoin/asic-faq.pdf), the adaptive blocksize stuff seems dangerous and the coin burning excuse for it can't work as expected in the long run since miners can get paid out of band, ... but the privacy design is very good, though even there its incompatible with pruning (but so is everything else). Of course, all these concerns also apply to forks that just aped the code.).

It's hard to believe you're not a major bytecoin holder of some sort? Monero is a fork without the massive premine/instamine/slowmine without release whatever it was of bytecoin, I imagine your opinion about it is the same if they share cryptonote?

As hard as it is to believe, people other than me do occasionally have really good ideas. :) ... (No, I'd only heard about it a couple months ago and looked into it in depth until the last week). I think all these altcoins are horribly ill-advised in their altcoinness. You're in the wrong subforum and thread if you want to talk about cryptocurrency speculation— my interest here is just in the techniques— and I'm not going to credit some random code aping fork for other people's work when talking about them.

(In case anyone had the impression that I thought bytecoin was all love and wonder: the implementation is currently really immature and somewhat buggy— and perhaps not likely to improve if its authors are now getting voted off the island in a fork. The POW is very slow to validate, and seems generally ill-advised to me (see https://download.wpsoftware.net/bitcoin/asic-faq.pdf), the adaptive blocksize stuff seems dangerous and the coin burning excuse for it can't work as expected in the long run since miners can get paid out of band, ... but the privacy design is very good, though even there its incompatible with pruning (but so is everything else). Of course, all these concerns also apply to forks that just aped the code.).

kinda sad darkcoin isnt implementing ring sigsmasternodes are coinjoin servers where miners must pay taxi'm interested to understand how that differs to federated darkwallet gatewaysstill, all power to drk... 4th crypto now

Sharedcoin is a blockchain.info product. You can read about it on their website, but I don't think it was based on any external design, just a mixing service cooked up by one of their engineers.

Darkcoin and darkwallet also have nothing in common either. Despite co-opting the name, darkcoin's darksend doesn't appear to have anything to do with coinjoin. Their description and illustration in their thread shows some sort of centralized mixing service (more akin to sharedcoin), and indeed their distribution mechanism involves a reward for "masternodes" which perform the mixing with these fresh coins. It would be nice if someone from that project could chime in here and explain just what it is trying to accomplish, because the available technical descriptions are scarce and contradictory.

Darkwallet does indeed implement coinjoin, albeit using a centralized matchmaking service to setup the mixes. I have been informed by the developers that this is a temporary mechanism and they are working towards a fully p2p solution. They do not use the blind signing or ring signature mechanisms which are required to scale to more than 2 participants without revealing ownership of outputs.

e.g. on https://darkcointalk.org/threads/coinjoin-in-bitcoin-and-darksend.560/or http://www.reddit.com/r/DRKCoin/comments/1zlv36/what_does_darkcoin_offer_that_couldnt_be_done/or some/alot other sites they talk about CoinJoin in DarkSend

maaku, the mixers are connected through a p2p protocol so anyone can set one up, however I think the idea (according to Peter Todd) is to use the Bitcoin network as a mixnet.I don't think we can use ring signatures unless bitcoin adopted ed25519... or am I mistaken?also it can scale >2 participants, because you do multiple rounds (share outputs, share inputs, give signatures).

cbeast, self-censorship is why threat is so effective. the real people who will adopt our tools won't be yuppie students buying coffee at the bar, it will be new digital black markets & we market to them. the tools go beyond mere payments into governance, markets and new forms of association between humans. the effect is deeper. bitcoin is more than a payments innovation despite what others want to make us believe. I'm not shuffling its massive potential under the carpet through fear of retribution and spending my time making Facebook apps.

I think dark cryptocurrencies are too powerful a tool for our civilization in its current state. Governments must use whatever means necessary to control its development for the safety and security of law-abiding citizens.

The problem here is that you don't know the difference between reality and projection. Your apocalypse fantasy (bitcoin=plutonium) is something you should be talking about with a therapist - it has nothing to do with Bitcoin.

genjix: Yup. Scaling works out nicely too because the additional CoinJoin traffic will never be more than a small multiple of the existing transaction traffic, so doing all the CoinJoin communication via global broadcast messages is actually reasonably and efficient enough; gives good privacy for that communication. You can also reuse bitcoin age as a limited resource for anti-dos.

It's not as pretty as more clever crypto, e.g. the zerocash project that I'm also now working with, but has the huge advantage that its flaws are easy to understand and predictable. We want diversity in the level of engineering in the solutions we come up for to solve problems; CoinJoin + zerocash are two totally different approaches, and if one day we can use both we're more likely to actually achieve privacy.

The problem here is that you don't know the difference between reality and projection. Your apocalypse fantasy (bitcoin=plutonium) is something you should be talking about with a therapist - it has nothing to do with Bitcoin.

At worst it is an exaggerated analogy. The analogy relates to the newness of the technology. Bitcoin is based in math theory and the technology is accessible to all. Just because we have a technology, does that mean everyone should be allowed to use it? Does that go for any technology? Howabout drug manufacturing? Howabout explosives? Should anyone be able to do anything they want without restrictions?

The problem here is that you don't know the difference between reality and projection. Your apocalypse fantasy (bitcoin=plutonium) is something you should be talking about with a therapist - it has nothing to do with Bitcoin.

At worst it is an exaggerated analogy. The analogy relates to the newness of the technology. Bitcoin is based in math theory and the technology is accessible to all. Just because we have a technology, does that mean everyone should be allowed to use it? Does that go for any technology? Howabout drug manufacturing? Howabout explosives? Should anyone be able to do anything they want without restrictions?

Your morals are not my morals. Who is the decider? Do you support a free and open internet?And yes, I definitely would like cheap medicinal knock off drugs flooding into the markets, and more kids playing with explosives and becoming scientists. Maybe you want to arrest people who write virus coding tutorials also?

Your mistake is thinking that compliance buys curries you special favour... but at the risk of what? There are bigger things at stake here (https://wiki.unsystem.net/index.php/Bitlaw). Bitcoin is not unmovable code and math, it is consensus. It's imperative we develop this technology, strong, resilient and decentralised. Part of my goal is getting people to think and question things they've held as true. I think we can inspire an ideal through symbolic acts of disobedience, inspiring courage in others to stand with us.

As you demonstrated in your post, the threat is real and here. The world has changed and it's time to adapt, survive and thrive. Either that or go extinct the way of the dinosaurs. And you know what? Maybe that threat you saw was more imagined than you realised. And maybe those threats, just maybe they were a paper tigers and fears unfounded. We will always be on the right side of history because we are about humanity. Dynamism, love, art, energy, change, passion, reality, risk, colour, soul.

@genjix, I think you misunderstood my point about multiple parties. Without blinding or ring signatures or other crypto magic, it is not possible to have multiple participants where the other participants don't know which outputs correspond with which participants (the exception for 2 users is simply that if there is only one other person participating, then obviously whatever outputs are not yours are his, not matter what fancy crypto is used). This is important because CoinJoin is useful for far more than mere mixing. Joint transactions are also the mechanism by which matching donations or crowdfund campaigns can be organized (see Mike Hearn's Lighthouse app), exchange transactions of colored coin assets can be arranged, and various cross-chain atomic trade protocols. Scaling up these applications to multiple participants without loss of privacy is very important.

@genjix, I think you misunderstood my point about multiple parties. Without blinding or ring signatures or other crypto magic, it is not possible to have multiple participants where the other participants don't know which outputs correspond with which participants (the exception for 2 users is simply that if there is only one other person participating, then obviously whatever outputs are not yours are his, not matter what fancy crypto is used). This is important because CoinJoin is useful for far more than mere mixing. Joint transactions are also the mechanism by which matching donations or crowdfund campaigns can be organized (see Mike Hearn's Lighthouse app), exchange transactions of colored coin assets can be arranged, and various cross-chain atomic trade protocols. Scaling up these applications to multiple participants without loss of privacy is very important.

I think it is.

Here's how we did it in the initial CoinJoin implementation we made.

* There's an anonymous chatroom (pre-negotiated shared secret in public room) accessible over Tor.* Some dudes submit various outputs.* Some dudes submit various inputs.* Server replies back with a tx.* Some dudes submit valid signatures.

Darkwallet does indeed implement coinjoin, albeit using a centralized matchmaking service to setup the mixes.

Just to clarify, we (darkwallet) don't exactly use a centralized matchmaking service, nor did we do at any point (as I would define it anyways). We did use a centralized matchmaking server in our first proof of concept on this thread.

The current scheme works on top of any chat service, where we initially integrated a simple chat in our lobby and now it's the same lobby but the channels exist in a p2p network of all gateways so clients can connect to any gateway or gateways seed from any other gateway.

You are right otherwise we don't yet use ring or blind signatures at the moment, so restricted to 2 party coinjoins, but the general design is done so we can (more or less) easily implement more complex coinjoin protocols.

* There's an anonymous chatroom (pre-negotiated shared secret in public room) accessible over Tor.* Some dudes submit various outputs.* Some dudes submit various inputs.* Server replies back with a tx.* Some dudes submit valid signatures.

If you are not linking outputs to inputs in the submission (say, by signing the request containing the outputs with the keys of the inputs), then you are leaving the protocol vulnerable to very easy to execute denial of service attacks. If you do close that DoS hole by signing the outputs with the inputs, then the sever operator at the very least knows the linkages and could log this information.

The solution, as explained in the OP, is blinding: link the inputs to the blinded outputs, and later anonymously reveal the outputs and the unblinded signature from the server. Then the participants know that the output was one of the original blinded outputs (because the server signed it), but they don't know which one. Even in a two-party mix with a facilitating server, the server doesn't know which output belongs to whom. If there is a DoS withholding of a signature at the end, the honest participants can elect to back out and reveal their blinding factors, thereby demonstrating their own linkages and preventing themselves from being DoS banned.

BTW, blinding is super easy to do. Using RSA it like a half-dozen lines of code.

There is absolutely no reason to use fixed units. It adds no anonymity, and increases blockchain traffic.

This surprised me. Surely a transaction with inputs 5,5,5,5 and outputs 5,5,5,5 will have better privacy characteristics than one with inputs 15, 5 and outputs 1,2,3,14? Or am I misunderstanding what "fixed units" mean?

The promised update to the original Zerocoin/Zerocash paper (http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf) has been released and it claims to reduce the size of a Zerocash transaction to under 1 kB and the time to verify a coin's spending transaction to under 6 ms. I have not fully read the paper yet, but am wondering if anyone has investigated these claims and whether or not these improvements would fully remove the barriers that previously prevented the protocol's integration into Bitcoin?

I am posting this here since I assume that there is a reasonable degree of overlap between those interested in Zerocash and those interested in CoinJoin. I apologize if this has already been addressed but I have been away for a while and am trying to catch up. I know that Peter Todd is advising the Zerocash team so I'm sure he has some valuable insight.

The promised update to the original Zerocoin/Zerocash paper (http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf) has been released and it claims to reduce the size of a Zerocash transaction to under 1 kB and the time to verify a coin's spending transaction to under 6 ms. I have not fully read the paper yet, but am wondering if anyone has investigated these claims and whether or not these improvements would fully remove the barriers that previously prevented the protocol's integration into Bitcoin?

I am posting this here since I assume that there is a reasonable degree of overlap between those interested in Zerocash and those interested in CoinJoin. I apologize if this has already been addressed but I have been away for a while and am trying to catch up. I know that Peter Todd is advising the Zerocash team so I'm sure he has some valuable insight.

It sounds exciting from what I've heard, but it probably won't go into Bitcoin directly. We need to keep Bitcoin's consensus pure and untouched. We don't nearly know enough.

The promised update to the original Zerocoin/Zerocash paper (http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf) has been released and it claims to reduce the size of a Zerocash transaction to under 1 kB and the time to verify a coin's spending transaction to under 6 ms. I have not fully read the paper yet, but am wondering if anyone has investigated these claims and whether or not these improvements would fully remove the barriers that previously prevented the protocol's integration into Bitcoin?

I am posting this here since I assume that there is a reasonable degree of overlap between those interested in Zerocash and those interested in CoinJoin. I apologize if this has already been addressed but I have been away for a while and am trying to catch up. I know that Peter Todd is advising the Zerocash team so I'm sure he has some valuable insight.

It sounds exciting from what I've heard, but it probably won't go into Bitcoin directly. We need to keep Bitcoin's consensus pure and untouched. We don't nearly know enough.

I find this response a bit confusing. In what way would Zerocash affect Bitcoin's consensus, assuming a one-to-one conversion rate? As for not knowing nearly enough, the whitepaper is pretty detailed and still seems to make provisions for including the protocol directly into Bitcoin. I don't mean to be argumentative, but I consider truly anonymous payments to be a "killer feature" that could very negatively affect Bitcoin's value if it lags behind. Of course there's no rush but it would seem prudent to me to start collecting a bounty.

maaku, you do actually have to read the post before making OT admonishments

He was asking about Zerocash. Zerocash has nothing to do with CoinJoin, and has it's own thread. I'd happy to discuss it there. In very short summary: Zerocash is not and never has been considered for inclusion on the bitcoin block chain. When the author references bitcoin he means the bitcoin protocol generally.

@Michael_S the point is that you multiple mixes, as well as opportunistic mixes each time you transact. Each mix increases the anonymity set. No one is claiming perfect anonymity a la Zerocash.

yep that's how ZeroCash and CoinJoin could work together. Both are pretty cool systems.

CoinJoin would be for your day to day payments.

ZeroCash would be for anonymising your savings.

(I'm just projecting here don't know full details) It seems like their plan is to build a layer on top of Bitcoin like how MasterCoin works. And that the ZC ledger tracks the Bitcoin one so you can convert to and from the ZC system. That's really exciting if so.

AFAIK ZeroCash needs a trusted accumulator. So it's just a science prototype and wont become a cryptocurrency, no one will use a cryptocurrency where:

- if an NSA agent contributed to the "trusted setup" there will be no privacyor- if an Mark Karpeles guy contributed to the "trusted setup" he can generate/create more coins than announced (as his crime would be invisible in the block chain)

Why use technologies based on trust, when we have trustless ones. Satoshi created Bitcoin specifically with the idea/key feature of not depending on trusting a third party.

maaku, you do actually have to read the post before making OT admonishments

He was asking about Zerocash. Zerocash has nothing to do with CoinJoin, and has it's own thread. I'd happy to discuss it there. In very short summary: Zerocash is not and never has been considered for inclusion on the bitcoin block chain. When the author references bitcoin he means the bitcoin protocol generally.

@Michael_S the point is that you multiple mixes, as well as opportunistic mixes each time you transact. Each mix increases the anonymity set. No one is claiming perfect anonymity a la Zerocash.

Surely a discussion about the way new developments in the Zerocash project relate to Coinjoin actually belong in their own exclusive thread, no? Technically, I mean.

In very short summary: Zerocash is not and never has been considered for inclusion on the bitcoin block chain

Considering the billions of dollars of other people's money that's at stake here, that seems like something that needs a public discussion and not a decree by fiat.

Quote from: maaku

When the author references bitcoin he means the bitcoin protocol generally.

Here's a direct quote from page 10 of the paper: "Zerocash can be integrated into Bitcoin or forks of it (commonly referred to as "altcoins"); we later describe how this is done."

Quote from: genjx

(I'm just projecting here don't know full details) It seems like their plan is to build a layer on top of Bitcoin like how MasterCoin works. And that the ZC ledger tracks the Bitcoin one so you can convert to and from the ZC system. That's really exciting if so.

I think that's being considered but I'm not sure if it's their final plan. It seems to me that, given some BTC developers' hostility toward their technology, they'd have an incentive to strike out on their own. As far as I know the infrastructure for Bitcoin sidechains is not yet in place so they can't go that route.

Quote from: dewdeded

AFAIK ZeroCash needs a trusted accumulator. So it's just a science prototype and wont become a cryptocurrency, no one will use a cryptocurrency where:

- if an NSA agent contributed to the "trusted setup" there will be no privacyor- if an Mark Karpeles guy contributed to the "trusted setup" he can generate/create more coins than announced (as his crime would be invisible in the block chain)

Why use technologies based on trust, when we have trustless ones. Satoshi created Bitcoin specifically with the idea/key feature of not depending on trusting a third party.

Zerocash needs a "one time trusted setup of public parameters". It's not unique in that sense. Many cryptography systems can be broken if certain constants are chosen in a particular way. Bitcoin itself could potentially be broken if its curve parameters were backdoored in some way (see https://bitcointalk.org/index.php?topic=151120.0). I don't know exactly what the Zerocash team's plan to instill confidence in their public parameters is but it seems like a surmountable complaint.

Bitcoin itself could potentially be broken if its curve parameters were backdoored in some way (see https://bitcointalk.org/index.php?topic=151120.0).

Incorrect. People have speculated that potentially an attacker powered by non-public mathematical breakthroughs could select parameters in a way to make a system weaker against publicly-unknown attacks which require specific improbable curve characteristics. This is pure conjecture, however— though it's something prudent to be cautious about, it is not a known backdoor vector by itself. The process for selecting curve parameters already excludes known classes of bad curves, if we knew about any other classes we'd exclude those too. In the case of Bitcoin our parameters were selected in a way where performance considerations removed their degrees of freedom (like the ed25519 parameters were selected), and are all explicable from first principles. In fact, they have an additional property that even if you drop some of the performance characteristics, and increment from the smallest possible parameter requirement the first curve of prime order you find is the one Bitcoin uses. Other cryptosystems also use nothing up my sleeve numbers, where an abundance of caution demands the designers pick them in a way that limit their degrees of freedom but at the same time no one knows of a way where control could be used secretly to do something bad— it's just a good practice, not a backdoor closed.

In the case of the GGPR'12 based SNARKs there is no comparable way to generate the parameters: The creation of the prover/verification keys requires computation using secret values, which— if known— completely compromise the soundness of the proofs. Here the backdoor is very concrete— not theoretical— when you know just a couple of the secrets you can do a few multiplies and have a false proof. Worse, there is no known way to use a nothing up my sleeve number to pick the parameters to convince people that no one could know the secrets. The best you can do is use process, like the CA system does (but potentially way better) to convince people of security. This isn't insurmountable for _many_ applications, but it is not at all comparable to EC curve parameters, there is nothing in curve parameter selection that looks like a magic number where if the attacker knows it all is lost. As far as I know there nothing like this in widespread use, the nearest parallel I can think of is the backdoor in DUAL_EC DRBG, though in that case the backdoor was a "surprise" and no process to prove that the potential backdoor wasn't weaponized (because it was)— which certantly makes it more concerning. There are a fair number of proposed _theoretical_ cryptosystems which have similar assumptions (e.g. Any of the neat uses of obfuscation involve the obfuscation being established by a trusted party), but I'm not aware of these systems being put into production. One reason for this may be because theoreticians find trusted initialization to be more acceptable than practitioners do— the theoreticians just posit "A spherically honest cow in random-oracle derived motion faithfully creates the parameters", the practitioners are the ones that have to figure out how to approximate the spherical cow using three chickens, a reed-solomon code, and a priest.

Quote

It seems to me that, given some BTC developers' hostility toward their technology, they'd have an incentive to strike out on their own

Funny, I've seen similar disinformation published before (http://www.reddit.com/r/Bitcoin/comments/25wo3s/zerocash/chloalr)— that person was unwilling (unable) to substantiate it— can you do better? The comments I made on Zerocoin (https://bitcointalk.org/index.php?topic=175156.msg1826596#msg1826596) were, I think, reasonably positive— but at the same time the system as it was wasn't suitable for deployment, and was later replaced by a complete reboot with much better performance (also evidence by the fact that no altcoin has deployed it, though they made a nice implementation of the cryptosystem available). I don't think there was anything hostile there, I've spent time with the developers of it and I think they're great guys, ... and I don't know any other developers who have been hostile about it either, so I'd really like to know what you're talking about.

This has really gone off-topic, but I thought leaving the FUD sitting around would be harmful.

A careless join is one in which the correct solution is obviously the most plausible. Note that evaluating different solutions to the matrix lends itself well to parallel processing, there is no time limit since everything is permanently recorded in the blockchain, and mass surveillance doesn't require 100% accuracy.

Probably the only way to make CoinJoin useful in real-world situations is to build into the clients the exact same type of analysis tools attackers will use to reverse the joins so that clients can evaluate any proposed join prior to agreeing to it. (That's a good subject for the other thread).

I like your remark about time limit and 100% accuracy. It remembers me an interview of a computer scientist working for an US intel agency. He was explaining how they were building a different paradigm for search: sometimes you ask a question and you don't get an answer because it's just too early. If you don't ask again later, you'll never know the answer. But if you let the question pending, till the "right" data is gathered and aggregated, then you start to get something very efficient.

You can apply the same principle to transaction graph analysis. Even if you're very carefull about the privacy of your transactions, one-time coinjoin is not enough if others participants are less carefull and can be deanonymized later.For now, systematic coinjoin (as proposed by DarkWallet) seems the most serious option to enhance privacy since it would create a combinatorial explosion and would significantly raise the cost of deanonymisation. But I guess it also comes with a lot of others issues to solve (delay required, constraints on amounts, ...).

Moreover, till now, main heuristics used for analysis of the transaction graph are "quite simple" (tainting, "address reuse" and "change address" patterns) and I guess it's just the first generation (at least which is publicized). I'm quite sure that more elaborated tools (temporal patterns, behavorial patterns) combined with side-channels attacks (data gathered from peripheral systems like exchanges, merchants, ...) could provide stunning results.

Moreover, till now, main heuristics used for analysis of the transaction graph are "quite simple" (tainting, "address reuse" and "change address" patterns) and I guess it's just the first generation (at least which is publicized). I'm quite sure that more elaborated tools (temporal patterns, behavorial patterns) combined with side-channels attacks (data gathered from peripheral systems like exchanges, merchants, ...) could provide stunning results.

The problem is that those tools are all being developed behind closed doors, which gives the attackers an advantage. Too many people think a low taint score displayed on blockchain.info provides them with meaningful protection.

I'll predict though that for all this investment money flowing into Bitcoin startups, not one VC is going to fund investment into open source graph analysis tools that could help individuals measure their privacy and warn them before they do something that will compromise it.

Andytoshi and I spent some time trying to formalize a notion of "coinjoin entropy"— e.g. how many possible mappings of inputs to outputs are possible given the values. A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.

We didn't actually solve the entropy question for the non-concurrent payment case, it's an interesting question.

The problem is that those tools are all being developed behind closed doors, which gives the attackers an advantage. Too many people think a low taint score displayed on blockchain.info provides them with meaningful protection.

I'll predict though that for all this investment money flowing into Bitcoin startups, not one VC is going to fund investment into open source graph analysis tools that could help individuals measure their privacy and warn them before they do something that will compromise it.

100% agree. I'm interested in this subject and I thought about the opportunity to build such a tool for the community since data and technology are available.

But I came up with the following conclusions :- it seems very difficult to fund a company like this one (well, you could plan to sell a closed product to some agencies like Fincen, banks... but it sounds like a small market)- human analysts are still required and I'm not sure that many people in the community are ready to invest a lot of time as unpaid volunteers. So it seems difficult to build a sustainable community around an open platform like this one.

BTW, I would be glad to be proven wrong and be funded to build a tool like this one. ;)

A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.

well, you could plan to sell a closed product to some agencies like Fincen, banks... but it sounds like a small market

I'm sure there's plenty of money available to fund that.

The question is whether or not you can get funding to produce the tools that let the general public protect themselves from it.

Agree with that.

Unfortunately, I fear there's an asymmetry which isn't in favor of this kind of project for now.

Projects are funded by entities which have some interest in the project and projects "tracking" users are more appealing to corporations and VC since there's a big data trend in the corporate world with an expected financial ROI. I guess it's not a political or ideological choice. They just do what they're supposed to do: business.

On the other hand, privacy friendly projects have not a clear financial ROI. For now. Funding this kind of project is more a "militant" choice than a financial one. For now. Moreover, Bitcoin is still presented as an anonymous and shadowy financial system by a majority of mainstream media, which is far from the reality but does not help people to understand the challenges at stake. I fear it's not specific to Bitcoin and that very few people are really aware of the challenges posed by technologies like internet or cryptocurrencies in term of privacy.

Dark activities have nothing to do with that (sorry eric schmidt). We need to think a new model of society, interconnected, in which a resource (data) has gained a massive increased value without any market mechanism fixing this value. For now.

Incorrect. People have speculated that potentially an attacker powered by non-public mathematical breakthroughs could select parameters in a way to make a system weaker against publicly-unknown attacks which require specific improbable curve characteristics. This is pure conjecture, however— though it's something prudent to be cautious about, it is not a known backdoor vector by itself. The process for selecting curve parameters already excludes known classes of bad curves, if we knew about any other classes we'd exclude those too. In the case of Bitcoin our parameters were selected in a way where performance considerations removed their degrees of freedom (like the ed25519 parameters were selected), and are all explicable from first principles. In fact, they have an additional property that even if you drop some of the performance characteristics, and increment from the smallest possible parameter requirement the first curve of prime order you find is the one Bitcoin uses. Other cryptosystems also use nothing up my sleeve numbers, where an abundance of caution demands the designers pick them in a way that limit their degrees of freedom but at the same time no one knows of a way where control could be used secretly to do something bad— it's just a good practice, not a backdoor closed.

In the case of the GGPR'12 based SNARKs there is no comparable way to generate the parameters: The creation of the prover/verification keys requires computation using secret values, which— if known— completely compromise the soundness of the proofs. Here the backdoor is very concrete— not theoretical— when you know just a couple of the secrets you can do a few multiplies and have a false proof. Worse, there is no known way to use a nothing up my sleeve number to pick the parameters to convince people that no one could know the secrets. The best you can do is use process, like the CA system does (but potentially way better) to convince people of security. This isn't insurmountable for _many_ applications, but it is not at all comparable to EC curve parameters, there is nothing in curve parameter selection that looks like a magic number where if the attacker knows it all is lost. As far as I know there nothing like this in widespread use, the nearest parallel I can think of is the backdoor in DUAL_EC DRBG, though in that case the backdoor was a "surprise" and no process to prove that the potential backdoor wasn't weaponized (because it was)— which certantly makes it more concerning. There are a fair number of proposed _theoretical_ cryptosystems which have similar assumptions (e.g. Any of the neat uses of obfuscation involve the obfuscation being established by a trusted party), but I'm not aware of these systems being put into production. One reason for this may be because theoreticians find trusted initialization to be more acceptable than practitioners do— the theoreticians just posit "A spherically honest cow in random-oracle derived motion faithfully creates the parameters", the practitioners are the ones that have to figure out how to approximate the spherical cow using three chickens, a reed-solomon code, and a priest.

Thank you for correcting my misleading statement. There are definitely are significant trust differences between the two processes. Your explanation will come in handy as more discussions about Zerocash surface.

Quote from: gmaxwell

I don't think there was anything hostile there, I've spent time with the developers of it and I think they're great guys, ... and I don't know any other developers who have been hostile about it either, so I'd really like to know what you're talking about.

I don't think that you in particular are hostile to anonymity nor am I suggesting that any of the Bitcoin developers have personal issues with any of the Zerocash developers. But I also know that there are many agendas at play in the Bitcoin world and not all of them include the type of anonymity that Zerocash provides.

I still think that there will have to be a public conversation about Zerocash, particularly after its developers have revealed how they plan on instilling confidence in their parameters, but I will save it for another thread.

Andytoshi and I spent some time trying to formalize a notion of "coinjoin entropy"— e.g. how many possible mappings of inputs to outputs are possible given the values. A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.

Sound logic, but it's not even necessary - since there is no such thing as "a Bitcoin", it is impossible to make a deterministic linkage between inputs and outputs. If the system was designed to actually transfer distinguishable units ('things') from one account to another, then the many-many mapping of txs wouldn't actually make sense (because somewhere in the guts of the code it would be deciding which bill with which serial number goes to which output, which would mean that de facto it was a set of one-one txs in disguise).

Andytoshi and I spent some time trying to formalize a notion of "coinjoin entropy"— e.g. how many possible mappings of inputs to outputs are possible given the values. A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.

We didn't actually solve the entropy question for the non-concurrent payment case, it's an interesting question.

The "entropy" will depend upon the model of attacker. Start by enumerating those.

Academic discussions aside, in any case what has been actually implemented in Dark Wallet is that you have two classes of users: people who want to send money now, and people who have coins that they want to mix. The latter don't have any particular requirements on the exact amounts they want mixed, so they copy the amounts the former are sending, guaranteeing that at least two outputs are identical and have two possible senders. Blockchain.info's CoinJoin implementation is similar, with blockchain.info operating maintaining a pool of funds that is used to copy exact output amounts.

Future implementations can and will improve on these concepts, but again, what's implemented now takes output indistinguishably into account and provides reasonably good privacy already.

The "entropy" will depend upon the model of attacker. Start by enumerating those.

The attacker knows everything in the blockchain. The attacker knows the identity of the payer or payee of some small number of transactions. The attacker wants to follow these identified funds forwards or backwards and expand their knoweldge recursively. The CJ users want the attackers analysis to fail, for themselves (most importantly) and for third parties.

I think of two main attack objectives— where the attacker is trying to identify a single user and where success/failure depends on how persuasive the evidence the attacker can extract for that single user. And one where the attacker is trying to broadly deanonymize everyone in order to feed larger scale analysis. For this latter attack the defender's is successful if they're able to increase the noise level of the analysis by a non-trivial amount at low cost to themselves, e.g. success in this latter cases is completely continuous.

I outlined some more specific attack objectives in the original post— things like people you do business with being able to determine your income, net worth, supplies costs, or prices.

Andytoshi and I spent some time trying to formalize a notion of "coinjoin entropy"— e.g. how many possible mappings of inputs to outputs are possible given the values. A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.

We didn't actually solve the entropy question for the non-concurrent payment case, it's an interesting question.

I'm ready to accept that CoinJoin can be viable with outputs of different sizes.

Next question: what about information leaked via script types?

I think we can assume that in the near future there will be several types of scripts in common use: P2PKH, multisig, and stealth. We can also assume that the frequency with which these scripts types are used will vary between different classes of users (merchants vs customers).

Even if the amounts associated with inputs and outputs don't make the join trivially reversible, how do you stop the scripts from acting as a side channel that can deliver enough information to make the join reversible?

I think gmaxwell should clarify that the bitcoin coinjoin model is centralised whereas Darkcoin has decentralised coinjoin. So, I can't see that it is pointless. His support for ring signatures is academic in the sense of "nice in theory but frankly not workable in real life". Those that have experience ring sigs know how buggy and alpha the software is.

Gmaxwell and his bitcoin devs should also realise that the IRS has already mapped out all significant bitcoin addresses to social security numbers, whilst they debate the alpha tech of ring sigs but yet are doing nothing to fix the privacy issue. The bitcoin dev team are looking like they are stalling on privacy. It's time they do something about it instead of opining this and that.

I think gmaxwell should clarify that the bitcoin coinjoin model is centralised whereas Darkcoin has decentralised coinjoin.

I think you should keep your garbage pump and dump crap out of this thread, put it someplace people won't annoy me by reporting it.

The things I described above in this thread can be implemented in a decentralized manner, as is described in some depth in post five. What darkcoin does doesn't sound decentralized at all— it depends on selected servers— but whos to say? Last I checked software was both closed source and not even working. When darkcoin was announced it claimed what it was implementing, however, was coinjoin.

Quote

looking like they are stalling

Bitcoin is openly developed software, anyone who wants to work on it can contribute to it, and last I checked none of the people who have ever worked on it are your payroll. If you're honestly concerned about privacy in Bitcoin you could do some things to help improve it. Pumping some sketchy altcoin in the wrong sub-forum, however, is not going to help, nor is attacking people who have no responsibility to serve your interests.

For some context for those confused about where this little OT tangent came from, someone wrote a fairly scathing analysis of DarkCoin (https://bitcointalk.org/index.php?topic=641178.0), basically making a case that it's a substanceless effort promoted by misleading marketing. Unfortunately, in making their argument they linked back here... drawing along some vigilant defenders. I'll continue deleting any more darkcoin posts that show up.

I think gmaxwell should clarify that the bitcoin coinjoin model is centralised whereas Darkcoin has decentralised coinjoin.

I think you should keep your garbage pump and dump crap out of this thread, put it someplace people won't annoy me by reporting it.

The things I described above in this thread can be implemented in a decentralized manner, as is described in some depth in post five. What darkcoin does doesn't sound decentralized at all— it depends on selected servers— but whos to say? Last I checked software was both closed source and not even working. When darkcoin was announced it claimed what it was implementing, however, was coinjoin.

Quote

looking like they are stalling

Bitcoin is openly developed software, anyone who wants to work on it can contribute to it, and last I checked none of the people who have ever worked on it are your payroll. If you're honestly concerned about privacy in Bitcoin you could do some things to help improve it. Pumping some sketchy altcoin in the wrong sub-forum, however, is not going to help, nor is attacking people who have no responsibility to serve your interests.

The "entropy" will depend upon the model of attacker. Start by enumerating those.

My attempt to collect a few random thoughts on the subject (long post).

1/ First studies in this field have modeled the blockchain as transactions graph and/or addresses graph. In a generic way, the enlarged blockchain ecosystem can be modeled as a graph in which nodes are:- Txo : associated to a given amount and controlled by a given script- Entity (human / organizational / machine) : controls txos by controlling associated scripts (alone or with others entities)- Tx : acts like "micro-mixers" of txos (amounts of input txos are mixed/splitted and forwarded to output txos)Note: the description is purposefully simplified, but it should be enough for the discussion.

2/ An attacker has 2 objectives: - deanonymization of entities - determination of the links between input and output of transactions

These 2 objectives are not orthogonal. They're mutually reinforcing. Every information gained for one can be used for the other.

Deanonymization of entities

3/ It often starts with side-channel attacks:- information gathering (bitcoin addresses, id, emails, ...) from various sources (forums, social networks, db managed by exchanges, merchants, ...). These information allow to associate deanonymized entities to a subset of the txos. Solutions like Stealth addresses help to address this issue.- network eavesdropping (like the one described here (https://bitcointalk.org/index.php?topic=632124.0)). It's a 2-steps process (at least): a - association of an ip address to a tx b - association of an entity (person, ...) to the ip address c - for more complex scenarii (mixed or coinjoin txs) ip address has to be associated to a subset of the input txos of the tx.

4/ As stated by gmaxwell, starting from the txos associated to deanonymized entities, the attackers want to follow the deanonymized funds forwards or backwards and expand their knowledge recursively. It leads us to the second objective.

Determination of links between inputs and outputs of transactions

5/ I think the problem can (should ?) be addressed in a probabilistic way. An attacker doesn't need 100% certainty before deciding of an action. She just needs to be above a given threshold of confidence. If a bunch of the analysis can be automated, the attacker can study several alternative hypotheses and decide which one seems the best.

6/ Taint analysis is the first tool usable for this kind of analysis. The result has 100% certainty (it's just a basic "read" of the blockchain) but produces limited insights.

7/ You can use some heuristics to enrich information provided by taint analysis. First studies in the domain used very simple heuristics like multi-input transactions and shadow addresses (see the paper "Evaluating User Privacy in Bitcoin") but gave quite good results. This privacy issue was addressed by avoiding address reuse and some new proposal like mixers or coinjoin txs. You can also use some "best-guess" heuristics like the one used by blockchain.info to determine which output is payment and which one is change.

8/ The more you know about entities, the more you can use sophisticated heuristics. For example, an attacker can use a specific knowledge (2 persons live in the same city and are occasional users of localbitcoin) in order to infer that the input of a coinjoin tx is linked to a specific output (if she already knows which input/output is controlled by these 2 persons). The attacker has not 100% certainty about this inference but it could be a reasonable hypothesis.

9/ Coinjoin has been proposed as an additional solution to strengthen privacy. As already stated by gmaxwell, it does not provide 100% anonymity but can provide better privacy. With proper design it helps to increase the cost to retrieve a given quantity of information (links between input and output). But as stated above, coinjoin remains attackable if you have side-channel informations.

Here's a "dumb" example. The attacker is an intel. agency with access to a huge amount of side-channel infos. As an analyst of this agency, I investigate on a man (let's call him Charlie) suspected to finance a terrorist attack by repeated small bitcoin transactions. Our hypothesis is that funds are received by another person (Mr. X) suspected to sell the coins on localbitcoin to gather dollars which will be used to buy some materials for the attack (I told you, it's a dumb scenario). Today, I want to analyze a given coinjoin transaction because I know that Charlie controls one of its inputs. Let's say that this coinjoin tx has 3 inputs and 3 outputs, all with same amount. The agency has a program of massive surveillance which tells me that :- input A is controlled by a woman suffering a cancer (information retrieved from her facebook account)- input B is controlled by Charlie- input C is controlled by a teenager (boy - information retrieved from snapchat)- output D is controlled by a small e-commerce website running on tor and selling weed- output E is controlled by a porn website- output F is controlled by an unknown entity, for now.

According to additional information that I can access, I will be able to build different hypotheses with more or less confidence:Hyp1) The woman has bought some weed to cure her pain and the teenager has watched some porn. Charlie may have send some coins to Mr. X and I should investigate deeper the output FHyp2) If I know that Charlie smokes weed may be this tx is just a false positive for my investigation => Charlie has bought some weed. The woman has nothing against a porn movie from time to time and the teenager...has bought a video game.Hyp3) [use your own fantasy here]...

I think you get the idea. This thought experiment illustrates a few interesting facts:- to be effective, this kind of attack requires side-channels informations. The more information you have, the more effective you are.- let's forget the "paranoïd" scenario that intel. agencies want to do massive surveillance just because they can do it or because they pursue some nasty goals. This experiment shows that to do their job (investigating potential serious threats) intel. agencies "have to" break privacy of all users (I don't argue it's good or bad, I just draw a logical conclusion. So please, do not yell at me)- to strengthen his privacy Charlie could chain several coinjoin txs but this solution has a major drawback: if coinjoin txs are rare among "normal" users, chaining several txs becomes a real red flag telling "Hey ! I prepare (do) something illegal"- as proposed by others persons, systematic coinjoin txs for all users would produce a combinatorial explosion. It's not perfect anonymity but it would raise very significantly the cost of this kind of attack.

Automated analysis (machine learning algorithms, ...)

10/ To my knowledge, few studies have used this kind of tool until now but they could be very effective (see the paper "Unsupervised Approaches to Detecting Anomalous Behavior in the Bitcoin Transaction Network"). By trying to detect repeated patterns in the blockchain, this approach helps to infer additional information. The rationale is simple : some activities are associated to very specific patterns. For example, it's likely that transactions corresponding to mining pools paying the miners or gambling sites paying the players have very specific characteristics.

Another example is provided by the MTGox's source code which was leaked a few month ago. It was quickly identified that there was an automatic process in place to split/merge amounts in their hot wallet. This knowledge was later used to detect that some funds were transfered according to this pattern (a few days before MTGox officially states that some funds had been retrieved). In this case, the pattern has been provided by a leak but you get the idea on how this kind of information can be used to reach the 2 objectives of the attacker.

11/ Patterns corresponding to automated (and non-random) processes should be the easiest to detect but it does not seem impossible that human operations could also be processed by studying temporal or behavorial patterns. For example, if you live in Europe it's likely that you send your txs at very different GMT hours compared to american or asian users.

Conclusion

12/ The current model provided by bitcoin (or by bitcoin with occasional coinjoin txs) is ultimately very close to the current situation of the interweb. Thus, it's quite straightforward to deduce the different levels of attacks and attackers:- Group A : Intel. agenciesThey have access to a massive amount of side-channel information already gathered from various sources. They will get the best results. Since not all side-channels information are not obtained by legal (official) means, these information don't always allow an official (legal) reaction.- Group B : Large corporationsThey have access to some amounts of side-channel information by providing paying services requiring the user to provide some personal informations. They'll be able to extract additional information by merging these data with data from the blockchain but at a lower level than group A. They'll an incentive to monetize these information by selling them to others entities (marketing, ads, ...).- Group C : Basically the rest of the worldWe have occasional access to some side-channel information by our direct interaction with others bitcoiners. Individually, it'll be difficult to extract significant information by merging these data with data from the blockchain.

13/ A bitcoin bank located in an exotic island and providing offchain transactions could remain the best solution for those wanting to hide illegal activities like money laundering.

14/ In this matter, I would say that the current bitcoin model does not change a lot of things compared to the current statu quo (even if bitcoin remains a great technology and a great innovation)

2/ An attacker has 2 objectives: - deanonymization of entities - determination of the links between input and output of transactions

These 2 objectives are not orthogonal. They're mutually reinforcing. Every information gained for one can be used for the other.

I think defining it as a submodular function of those two concerns is a great starting point. Not a lot to be done on #1, at least on-blockchain, is there?

If we are just comparing between what we have now and what we could have, I think it's vastly superior. For now, at least in the US, the feds snoop on all our credit card purchases, without a warrant. Probably enough evidence for a warrant, but not for conviction of any particular crime.

Getting beyond that with reasonably not too much effort will be the real challenge.

p.s. Anyone know of any good annotated datasets of transactions? Unsupervised learning is notoriously ??? to interpret.

I think defining it as a submodular function of those two concerns is a great starting point. Not a lot to be done on #1, at least on-blockchain, is there?

Well, bitcoin can't prevent an attacker to gather side-channel information but it can try to obfuscate links between personal information (email, social network id, ...) and addresses in the blockchain. Stealth addresses seem a promising solution for this. Moreover, deanonymization of entities is a recursive process fed by all the results obtained while working on the 2nd objective. Thus, coinjoin seems a useful tool to raise the cost of deanonymization.

If we are just comparing between what we have now and what we could have, I think it's vastly superior. For now, at least in the US, the feds snoop on all our credit card purchases, without a warrant. Probably enough evidence for a warrant, but not for conviction of any particular crime.

I could be wrong but I think it's just a matter of time before the 2 situations converge. The current trend seems to be more and more SPV clients and web wallets operated by regulated corporate entities. I guess merchants will have some duties too. Thus, if US feds have access to credit card purchases, accessing raw deanonymized informations should not be a problem for them. Of course, it remains solutions like coinjoin but I think they'll be a niche if they're opt-in features.

Getting beyond that with reasonably not too much effort will be the real challenge.

It's a very interesting point. My take is that it has 2 parts : - what is technically doable - which level of privacy is desired (according to the 3 groups defined in previous post)

It's easy to feel the tensions created inside the community by the latter. But even if the community was able to reach a consensus (an utopia) it would have huge consequences. Imagine the reaction of governments, corporations, investors if the whole community states that it wants perfect privacy and be protected from all kind of attacks. Ultimately, having a blurred position on this subject is surely the "best" option to increase the acceptance of bitcoin and reach mass adoption. But the price to pay is that it introduces a ghost in the place which exacerbates tensions (a good example here https://bitcointalk.org/index.php?topic=635317.0).

p.s. Anyone know of any good annotated datasets of transactions? Unsupervised learning is notoriously ??? to interpret.

Nope. Possible solutions to cope with this problem: - use an experimental approach (by injecting coins in the system as done by Moser for his paper "Anonymity of Bitcoin Transactions - An Analysis of Mixing Services") - rely on the community to get additional data (think to people who've shared their Gox addresses with the community to help investigate the bank run)

This point highlights the gap between the 3 groups of attackers (group A has an obvious advantage with its ability to gather side-channel information).

In two weeks, this site is going to release an open source tool that purports to de-anonymize Shared Coin transactions.

http://www.coinjoinsudoku.com/advisory/

Coming from the perspective that it's impossible to improve that which is not measured, I'm glad to see tools like this appear. Hopefully in the future we'll be able to evaluate privacy claims in a more empirical and objective way and so be more likely to have tools that actually work.

Peter Todd has made an interesting statement in the comments of this coindesk's article (http://www.coindesk.com/blockchains-sharedcoin-users-can-identified-says-security-expert/).

Quote

What Dark Wallet actually implements is to have two classes of users, those who need a transaction done immediately, and those who are mixing coins. The latter group simply copies the output amounts of the former group, providing a set of two outputs in every CoinJoin transaction whose ownership is unknown. SharedCoin does the same thing, but with blockchain.info acting as that coin mixing group.

I may be wrong but it seems likely that bc.i uses a same pool of coins over and over for the sharedcoin txs. It's not impossible that, with some efforts, someone could identify which txos in the transaction graph are concerned (i.e. belong to bc.i), decreasing a bit more the level of privacy offered. To be effective and avoid this kind of privacy leak, coinjoin should use a large pool of mixing coins (the 2nd group of users in Peter's comment) and avoid reusing the same mixing coins over and over (with a frequency which allows to identify them).

Btw, it's likely that decentralized solutions like darkwallet are the easiest way to achieve this goal if they have enough traction and can maintain a large mixing pool.

I'm implementing distributed coinjoin to a couple of alt coins. I guess it can be applied to bitcoin also.

Shortly the algo:Coinjoin offers are broadcasted as normal transactions, but on other channel, using message "ctx".These offers are collected to a complete coinjoin transaction by first sorting the offers, then all participants sign it in turns based on sorting order and transmits them on the ctx channel. When the last finds it is complete, it transmits the complete transaction using normal tx message.

So it's trivially identifiable whose outputs are whose based on the observed offers?

I have been wondering that too. Coinjoin itself protects transactions on blockchain only. However it requires someone to log all transactions 24 hours / day.

It is one improvement which should be done some day. The offers should be encrypted, so only the participants can decrypt all inputs. Then it would reveal only one address, and that might be generated to be used only once, maybe with 0 output. Other possibility would be to share the offers throught encrypted channel.

Peter Todd has made an interesting statement in the comments of this coindesk's article (http://www.coindesk.com/blockchains-sharedcoin-users-can-identified-says-security-expert/).

Quote

What Dark Wallet actually implements is to have two classes of users, those who need a transaction done immediately, and those who are mixing coins. The latter group simply copies the output amounts of the former group, providing a set of two outputs in every CoinJoin transaction whose ownership is unknown. SharedCoin does the same thing, but with blockchain.info acting as that coin mixing group.

I may be wrong but it seems likely that bc.i uses a same pool of coins over and over for the sharedcoin txs. It's not impossible that, with some efforts, someone could identify which txos in the transaction graph are concerned (i.e. belong to bc.i), decreasing a bit more the level of privacy offered. To be effective and avoid this kind of privacy leak, coinjoin should use a large pool of mixing coins (the 2nd group of users in Peter's comment) and avoid reusing the same mixing coins over and over (with a frequency which allows to identify them).

Btw, it's likely that decentralized solutions like darkwallet are the easiest way to achieve this goal if they have enough traction and can maintain a large mixing pool.

The more times your output is the same address the easier it would become to trace your coins.

I have an idea about a way to perform a decentralized Coinjoin so that individual participants are unable to map inputs to outputs - without the need for an anonymity network or blinded signatures.

As a disclaimer, although I have experience programming I am not well-practiced in cryptography, so forgive me if I make any egregious mistakes and waste everyone’s time.

Given the IP addresses and public keys for all N Coinjoin participant nodes, I envision the following onion routing protocol (inspired by what is used in Tor):

1. Decide upon a random path which visits every node once and ends up back at our node.

2. Using Onion Routing, send a multi-level encrypted message along this path. Each node by using its private key to decrypt the message will be able to see where the message was supposed to originate from, the bitcoin addresses to be used as inputs, and where to send the message to next. The rest of the message will only be able to be further decrypted by the next destination. When the message gets back to us, it should have visited every node in the path.See: http://en.wikipedia.org/wiki/Onion_routing

3. Same protocol, but with output addresses (can be done in parallel with the input addresses).

4. Same protocol, but with our signature of the completed transaction.

5. Broadcast transaction.

In theory, each node will be unable to tell from what node the input and output addresses originated. However, I see several serious issues with this proposal, and would welcome even more critique:

Timing Attacks: If a node receives the message early in the process, it is more likely that that the sender owns the associated addresses. This may be mitigated through random delays or other, more clever schemes.

Message Size: A node may be able to analyze the size of the message to determine how far along it is. To counter this, a randomly-sized allotment of junk data should be included in the inner-most message.

Slow: this protocol takes N time, as the message must be forwarded to each node.

DDOS: What is to stop some other node from screwing everyone over? It is possible to see if our message was tampered with (using random numbers, accumulating counters, etc.), but it would still be difficult to make the protocol resistant to malicious nodes mucking everything up and wasting everyone’s time.

Sybil Attacks: You’re pretty much screwed. Tor has similar issues, this is one thing you really can’t do anything about (other than favoring IP addresses that are likely to be in physically separate locations)

Other stuff: It’s probably out there, I just can't think of it at the moment.

Well, what about the positives? Assuming all the negative obstacles are surmountable:

Inputs are not linked to IP addresses.

Outputs are not linked to IP addresses.

Inputs are not linked to outputs any more than can be determined from looking at the finalized transaction.

No anonymity network required. This is important as P2P over, say, Tor is a pain.

No reconnecting required. You are not required to meet up with the same nodes again.

If you are behind a NAT router or firewall blocking inbound connections, you can hire an open node as a proxy. As only you have access to your private key, you can have this node forward/receive your messages without worrying about it snooping (granted, it can still cause as much trouble as the other nodes, and you probably have to compensate the proxy owner by including a small transfer in your transaction).

Would using ring signatures work as a method of mixing without having to trust a server even though they are using one? Provably fair mixing?

Have the clients connect and have all the inputs define the initial state of the cryptonote type ring signatures. Each person then shuffles the ring and they are only able to follow their own coins. They then specify the outputs in the ring whatever they are. Once everyone is happy they are getting paid they all sign. No one, not even server would be able to follow who is getting what. And even if the person had one input they could have multiple outputs depending on what they specify in the ring.

I am currently working on a Java library which facilitates decentralized CoinJoin-ing using a BitcoinJ backend.

As of this moment the library only works with fixed CoinJoin participants, I have yet to implement participant discovery (that's next on the list).It also is very insecure at the moment, as I hacked together some sections in order to test general principles. It will be some time before the code is solid enough to not be embarrassing :\

This is a test CoinJoin transaction between only 2 users. In this example I set the change and output address to be the same. The general caveats of a CoinJoin transaction still apply: each change address is clearly linked with an output address, and therefore by using blockchain analysis it may still be possible to link addresses. True anonymity requires minimal address reuse and tools for managing taint.

For now, though, I just send an unconfirmed transaction to a new address of fixed size, then use that unconfirmed transaction as part of the CoinJoin. Needless to say, for this scheme 0 confirmation coinjoins should not be accepted! Regardless, I am trying to write the library to be adaptable as possible to different types of CoinJoins, including coinjoins where each user has multiple inputs, casual coinjoins, and coinjoins without any change address.

Currently peer discovery is implemented with a centralized server. The server waits for N users to connect, then sends a message containing the IP Address and port of all participants. This approach is vulnerable to denial of service and is a single point of failure, but on the up-side any compliant server can be used. I still believe distributed peer discovery is ideal, but that can always be added later.

The centralized method is also NAT-friendly if Tor is used. Here is an idea for anonymous peer discovery and communication:

1. Each participant starts a Tor Hidden Service.2. Using Tor, each participant connects to a peer discovery server, which is itself a Hidden Service. It announces the ID of its Hidden Service and open port.3. The server then sends each participant a list of the Hidden Services. The participants then connect to these Servers and proceed with the decentralized CoinJoin process.

+ No traffic ever leaves the Tor network+ No port forwarding / NAT traversal is required (in this sense it is more user-friendly than a non-anonymous

It should be noted that in order to prevent inputs and outputs from being linked by participants more complicated measures such as the blind signatures discussed on the first page must be used.

P.S.Here is an example of a 10-way CoinJoin I generated using my library:http://tbtc.blockr.io/tx/info/894d10fea8e017789e80e2965d3421572e42e19ba8c6f51ce4a22b3c40b0f831

This is similar to what a CoinJoin transaction would look like in practice, except a more secure implementation would mix the outputs around better.

This is very safe, however it is not very private. It is essentially not possible to "lose" your coins doing this, however it has been proven that these types of transactions can be traced by inspecting the blockchain.

This is very safe, however it is not very private. It is essentially not possible to "lose" your coins doing this, however it has been proven that these types of transactions can be traced by inspecting the blockchain.

Don't confuse blockchain.info's completely broken "Shared Send"— they provide no privacy at all for reasons unrelated with this thread. The privacy implications of well constructed CoinJoins are discussed in some depth in the initial post and some other posts in this thread.

I have coded a simple implementation of CoinJoin.https://bitcointalk.org/index.php?topic=730321.msg8254585

It makes no assumptions about how peers communicate but instead provides ascii-armored raw transactions similar to the PGP format which can be shared on any text-based protocol such as a Tor hidden service forums, Bitmessage chans, I2P eepsites, Freenet pages or something like that.

Currently peer discovery is implemented with a centralized server. The server waits for N users to connect, then sends a message containing the IP Address and port of all participants. This approach is vulnerable to denial of service and is a single point of failure, but on the up-side any compliant server can be used. I still believe distributed peer discovery is ideal, but that can always be added later.

The centralized method is also NAT-friendly if Tor is used. Here is an idea for anonymous peer discovery and communication:

1. Each participant starts a Tor Hidden Service.2. Using Tor, each participant connects to a peer discovery server, which is itself a Hidden Service. It announces the ID of its Hidden Service and open port.3. The server then sends each participant a list of the Hidden Services. The participants then connect to these Servers and proceed with the decentralized CoinJoin process.

+ No traffic ever leaves the Tor network+ No port forwarding / NAT traversal is required (in this sense it is more user-friendly than a non-anonymous

It should be noted that in order to prevent inputs and outputs from being linked by participants more complicated measures such as the blind signatures discussed on the first page must be used.

P.S.Here is an example of a 10-way CoinJoin I generated using my library:http://tbtc.blockr.io/tx/info/894d10fea8e017789e80e2965d3421572e42e19ba8c6f51ce4a22b3c40b0f831

This is similar to what a CoinJoin transaction would look like in practice, except a more secure implementation would mix the outputs around better.

If you are writing a Java library and are planning on using a DHT, have a look at TomP2P. Its what i used in http://coinmux.com (http://coinmux.com).

So let me try and figure this out this is a little out of my league but here it goes:

Effectively you are creating a mixing service within the Bitcoin network itself? Making privacy better because no one can track where you sent your Bitcoin because it is split up and combined with other peoples transactions. Surely this has already been done by several mixing services?

Wouldn't this create more legal problems for Bitcoin? If this is what you want to achieve surely it's illegal because this can be abused very easily.

So let me try and figure this out this is a little out of my league but here it goes:

Effectively you are creating a mixing service within the Bitcoin network itself? Making privacy better because no one can track where you sent your Bitcoin because it is split up and combined with other peoples transactions. Surely this has already been done by several mixing services?

Wouldn't this create more legal problems for Bitcoin? If this is what you want to achieve surely it's illegal because this can be abused very easily.

It also has technical benefits for the network in terms of reduced overheads.

btw, bitcoin is legal, it has no "legal problems". You are probably confused by the enormous legal complexities of handling government fiat.

So let me try and figure this out this is a little out of my league but here it goes:

Effectively you are creating a mixing service within the Bitcoin network itself? Making privacy better because no one can track where you sent your Bitcoin because it is split up and combined with other peoples transactions. Surely this has already been done by several mixing services?

Wouldn't this create more legal problems for Bitcoin? If this is what you want to achieve surely it's illegal because this can be abused very easily.

It also has technical benefits for the network in terms of reduced overheads.

btw, bitcoin is legal, it has no "legal problems". You are probably confused by the enormous legal complexities of handling government fiat.

I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.

Making Bitcoin illegal in every country if this is enabled. Unless I'm not fully grasping something I think that's what this is all about and could cause a few problems.

I can see why this would be beneficial to the network and the general user of Bitcoin but I can also see it enabling thieves even more.

I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.

I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.

You're gonna *love* my next blog post...

Link it to me and I'll tell you if I "love" it or not ;)

/ot

I'm really trying to figure this out and try to address some of my concerns and I believe this would result in a lot of accusations flying out.

money needs to be functional as an economic unit ... rather than fulfill every utopian fantasy bestowed upon it

Well that's always been my defense when explaining Bitcoin to people and they point out the issues with recent happening with mt gox and money laundering. Bitcoin does nothing less than cash does related to the legal side of things.

But, I'm just saying this sort of thing is adding fuel to the engine and could potentially make things a lot worse.

I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.

You're gonna *love* my next blog post...

Link it to me and I'll tell you if I "love" it or not ;)

/ot

I'm really trying to figure this out and try to address some of my concerns and I believe this would result in a lot of accusations flying out.

I'm going to explain how Bitcoin can be used as a defencive weapon that allows the younger generation to avoid paying the debts bestowed upon them by the older generation, and how if they wield it correctly they'll collapse the fiat debt ponzi scheme, the tax base, and the US Dollar itself, with specific instructions for how to get started.

This would require all nodes to run Tor! Why not do the CoinJoin negotiation over BTC's network protocol, which the nodes participate in anyway? This way, those who use BTC through Tor also do the negotiation through Tor, but no one has to.

This would require all nodes to run Tor! Why not do the CoinJoin negotiation over BTC's network protocol, which the nodes participate in anyway? This way, those who use BTC through Tor also do the negotiation through Tor, but no one has to.

There is little benefit to negotiation over the Bitcoin network protocol for traditional CoinJoin's besides eliminating the need for an additional networking layer.

On the downside, adding additional messages to the network protocol is likely an irksome process, and is not very flexible. A separate network may be rapidly iterated upon, and other shared transactions other that traditional CoinJoins may be added.

In regards to Tor, for Java there exists the Orchid library, which allows Tor to be easily integrated within Java applications. The main benefit of using Tor Hidden Services (to me at least, if I am understanding things correctly) is not really anonymity, but rather NAT traversal. Without Tor, you have to keep a port open to allow users to connect to you node and perform a decentralized CoinJoin. Tor hidden services connect to Tor Relays, and therefore do not require any ports to be open. As long as the NAT/firewall allows outgoing Tor connections, everything works out.

EDIT:I forgot to mention, a downside of using Tor is that TomP2P and all other Java DHT libraries that I know of require ports to be open to ensure the integrity of DHT (if no nodes are hosting the DHT information, what's the point?). As such, in order to make the DHT robust the code would have to be extended to facilitate Tor Hidden services. This doesn't even address the fact that using a DHT to facilitate CoinJoining between number of users n>2 is a real pain.

Hence, decentralizing peer discovery is a job for another dayweek month.

1) Implement HD wallets (about 95%+ done, and works fine in testnet Dev build, but still need to update LocalTrader and other minor things to work with it)2) Move the entire infrastructure to Tor, meaning our nodes will be run as hidden servers, only accessible through Tor, and Mycelium Wallet will have Tor built in (hopefully this won't cause problems in blocked countries, like China or Iran)3) Implement CoinJoin, using our nodes that are used for address lookup and broadcasts, to collect and broadcast mixing requests. Likely enable this as a default feature. We'll have to figure out if we'll need to follow the DarkWallet model of letting some users leave their coins to mix, or if we have enough transaction volume to do it on the fly. Maybe we'll even link with DarkWallet servers, and use the people looking to mix there.

3) Implement CoinJoin, using our nodes that are used for address lookup and broadcasts, to collect and broadcast mixing requests. Likely enable this as a default feature. We'll have to figure out if we'll need to follow the DarkWallet model of letting some users leave their coins to mix, or if we have enough transaction volume to do it on the fly. Maybe we'll even link with DarkWallet servers, and use the people looking to mix there.

The larger the pool the better and it might make it easier for ad hoc transactions if everyone cooperated on using popular servers.

As part of ongoing efforts of the Monero Project, a small program has been generated that allows you to do 1-of-N ring signatures using a secp256k1 keypair and a keyring of public keys. The program signs both binaries and text files.

https://github.com/monero-project/urs

To build and install, use this command after installation of Go:

Code:

go get -u -v github.com/monero-project/urs/...

According to the paper, unique ring signatures are anonymous except in the case of signing the same message multiple times (in which case X and Y in the signature appear to be the same).

http://csiflabs.cs.ucdavis.edu/~hbzhang/romring.pdf

A potential usage might be to sign gitian asserts from a trusted keyring anonymously that contains well known members of the Bitcoin project. Another usage would be for members of a trusted community of Bitcoin users to anonymously vote for some proposal by signing it separately and publishing their signatures.

Thanks to Hein Meling for the initial URS implementation, Conformal Systems for their immensely useful libraries, and gmaxwell for inspiration.

Another interesting use could be a type of ring signature coinjoin? A group gets together and determines the inputs. The ring signatures are used for each person to pick their outputs and can even have multiple outputs of different values. Once the group has enough messages specifying the output addresses the coinjoin transaction is created and signed. If any party of the group cheats the output values will total to be too high and the transaction is discarded.

This is a good idea. In the original coinjoin thread (https://bitcointalk.org/index.php?topic=279249.0) gmaxwell described a blinding scheme wherein users would initially provide their outputs in blinded form, have them blindsigned by the central server (or the "leader" node in a p2p setup) (or all participating parties, which is bandwidth-heavy), then reconnect anonymously to unblind them. For a p2p setup this means that somebody has to produce the blind signatures: either a leader must be selected, which adds complexity to the protocol, or every party signs every output, which leads to O(n^2) scaling.

With a ring signature on the other hand, each party would anonymously sign only their own outputs -- all nodes participate equally, with O(n) signatures. (Of course, the ring signatures are O(n) in size, so you might say this is still O(n^2) scaling. But since every signature uses the same keyring, this doesn't need to be passed around. Just the signature itself plus a blinding factor Q (one per signature, no need to use different ones per key in this case) as described in an earlier post.)

1) Implement HD wallets (about 95%+ done, and works fine in testnet Dev build, but still need to update LocalTrader and other minor things to work with it)2) Move the entire infrastructure to Tor, meaning our nodes will be run as hidden servers, only accessible through Tor, and Mycelium Wallet will have Tor built in (hopefully this won't cause problems in blocked countries, like China or Iran)3) Implement CoinJoin, using our nodes that are used for address lookup and broadcasts, to collect and broadcast mixing requests. Likely enable this as a default feature. We'll have to figure out if we'll need to follow the DarkWallet model of letting some users leave their coins to mix, or if we have enough transaction volume to do it on the fly. Maybe we'll even link with DarkWallet servers, and use the people looking to mix there.

For CoinShuffle:Are denominations best? I'm just wondering if each user specified multiple output addresses in separate encrypted containers would the amounts provide some type of clue to the originator?

I'm thinking of CoinShuffle while doing payments. If an item costs 1.2 btc then the wallet could do a CoinShuffle for 2 btc sending one output to the actual payment and the change to an address they control.

Summary:One party waits for a mix (by enabling mixing on a pocket). Another wants to mix on demand.

Allow waiting party to specify a mixing fee that will be paid to its change address by the other side.

I suggest this will create a mixing market and increase mixing volume.

----------------------------------------------------------

A proposal for an improvement to darkwallet's coinjoin system.

Darkwallet's coinjoin works with two parties. One party will wait around with bitcoins they wish to mix. Another party will connect with them whenever they want to do a transactions and the two parties will do a coinjoin. By analogy with exchange matching engines, I will call the first party the coinjoin maker and the second the coinjoin taker.

The idea is that there will be people acting as makers who will slowly mix their coins for the benefit of the takers who want to immediately mix.

Here is an example of a darkwallet coinjoin transactionhttps://blockchain.info/tx/c38aac9910f327700e0f199972eed8ea7c6b1920e965f9cb48a92973e7325046

As you can see, the change addresses can be linked with the inputs but the address with outputs of 0.01btc cannot be linked. Mixing is achieved.The maker/taker model solves the problem of having to wait around for someone who wants to coinjoin exactly the same amount as you.

There are a few small problems with this. I will propose an improvement.

First, the only people motivated enough to mix will be people who already have desire privacy. So, for the example of someone wanting to privately buy contraception and hide the fact from their parents, mixing may result in their coins being mixed with drug money. It is easy to imagine this ecosystem being split between 'clean' coins mostly owned by investors and 'dirty' coins owned by 'undesirables' of society. It's easy to imagine a blacklist system being made which these two groups are seperated and cannot cross the barrier of blacklists, which would be highly damaging to bitcoin fungiblility.

Secondly, there is little incentive to act as a coinjoin maker when you could just be a coinjoin taker and get your mixing done without any waiting.

Thirdly, a small number of coinjoin makers leaves open the possiblity of three-letter agencies offering coinjoin making, and using that role to deanonymize darkwallet coinjoins.

Proposal: Pay the coinjoin makers. They will put up offers to do coinjoin along with a fee they ask. The coinjoin transaction would be built up in a similar way to the above example, with the coinjoin maker fee being added to the associated change address and taken away from the coinjoin taker's change address.

An implication of this is that darkwallet coinjoin mixing will become like an almost-riskless savings account. We already see that holders of bitcoin are willing to earn just 0.006% per day by lending btc on the bitfinex exchange, and that contains a substantial risk that bitfinex will go disappear or be hacked taking all the bitcoins with it.Darkwallet coinjoin with a maker's fees would be far less risky, the bitcoin private keys would never leave the owner's computer. This would likely result in investors pouring in. The huge relative supply of bitcoins along with the drought of other worthy bitcoin investments is likely to drive down the fees of mixing as the investors bid each other down.

The coinjoin takers will have access to tens of thousands of clean, untainted bitcoins to mix with at a very low price. The makers will have access to a very low risk investment for their bitcoins. Bitcoin fungiblility as a whole will benefit because the entire economy and flow of money will be more interrelated, making blacklists completely unfeasable. The market for coinjoin makers may end up so deep and liquid that three-party or even four-party coinjoins may become managable to organise.

Proposal: Pay the coinjoin makers. They will put up offers to do coinjoin along with a fee they ask. The coinjoin transaction would be built up in a similar way to the above example, with the coinjoin maker fee being added to the associated change address and taken away from the coinjoin taker's change address.

Doesn't seem like a terrible idea. I do wonder though, could this potentially compromise the privacy of coinjoin makers based on the unique fee amounts that they charge? If I'm charging 0.5773% per transaction, that might make it easy to identify which transactions I'm involved in. Or does this not matter?

If it does, perhaps some sort of fee standardization or fuzzing should be included. Makers could be required to choose a specific fee tier (1%, 0.5%, 0.1%, 0.05%, etc). Alternatively, makers could choose a range in which to make offers (such as 0.1%-0.9%), and randomly change their offer every time their offer is taken or every 10 minutes that it sits untaken.

Providing a financial incentive seems a good way to increase adoption of privacy tools and transform dormant bitcoins in active money.

Moreover, some coinjoin txs (like the example in your post) provide a low entropy and it's really easy to link outputs.By transferring a fee from taker to maker, the tx becomes more similar to a regular tx in term of entropy and you can't link outputs with 100% certainty.The "downside" is that these txs still have a specific signature (#outputs >=4) different from the most usual txs (#outputs = 2).

Just a detail: Don't think your proposal will "solve" the third point from your post. Having more makers is nice but it won't remove attackers. And some could argue that your proposal will just help to fund them ;)

I do wonder though, could this potentially compromise the privacy of coinjoin makers based on the unique fee amounts that they charge? If I'm charging 0.5773% per transaction, that might make it easy to identify which transactions I'm involved in. Or does this not matter?

An individual maker's fees won't be too different from anyone else because of market forces. There will surely be many many people offering to make coinjoin at almost exactly the same fee.

But you're right that coinjoin doesnt hide the fact that coinjoin is taking place. In the posted example (tx hash: c38aac9...) we know its a coinjoin but have no idea which 0.01btc output belongs to whom.

Moreover, some coinjoin txs (like the example in your post) provide a low entropy and it's really easy to link outputs.By transferring a fee from taker to maker, the tx becomes more similar to a regular tx in term of entropy and you can't link outputs with 100% certainty.The "downside" is that these txs still have a specific signature (#outputs >=4) different from the most usual txs (#outputs = 2).

Yep, it's inherent in coinjoin that you cant hide easily the fact that a coinjoin took place.Individual outputs are still mixed though.

Just a detail: Don't think your proposal will "solve" the third point from your post. Having more makers is nice but it won't remove attackers. And some could argue that your proposal will just help to fund them ;)

I never said it would :)(Maybe implied it)

It's similar to the situation with tor nodes. More honest nodes make it harder for the NSA.

Darkwallet's coinjoin works with two parties. One party will wait around with bitcoins they wish to mix. Another party will connect with them whenever they want to do a transactions and the two parties will do a coinjoin. By analogy with exchange matching engines, I will call the first party the coinjoin maker and the second the coinjoin taker.

The idea is that there will be people acting as makers who will slowly mix their coins for the benefit of the takers who want to immediately mix.

Here is an example of a darkwallet coinjoin transactionhttps://blockchain.info/tx/c38aac9910f327700e0f199972eed8ea7c6b1920e965f9cb48a92973e7325046

As you can see, the change addresses can be linked with the inputs but the address with outputs of 0.01btc cannot be linked. Mixing is achieved.The maker/taker model solves the problem of having to wait around for someone who wants to coinjoin exactly the same amount as you.

There are a few small problems with this. I will propose an improvement.

First, the only people motivated enough to mix will be people who already have desire privacy. So, for the example of someone wanting to privately buy contraception and hide the fact from their parents, mixing may result in their coins being mixed with drug money. It is easy to imagine this ecosystem being split between 'clean' coins mostly owned by investors and 'dirty' coins owned by 'undesirables' of society. It's easy to imagine a blacklist system being made which these two groups are seperated and cannot cross the barrier of blacklists, which would be highly damaging to bitcoin fungiblility.

Secondly, there is little incentive to act as a coinjoin maker when you could just be a coinjoin taker and get your mixing done without any waiting.

Thirdly, a small number of coinjoin makers leaves open the possiblity of three-letter agencies offering coinjoin making, and using that role to deanonymize darkwallet coinjoins.

Proposal: Pay the coinjoin makers. They will put up offers to do coinjoin along with a fee they ask. The coinjoin transaction would be built up in a similar way to the above example, with the coinjoin maker fee being added to the associated change address and taken away from the coinjoin taker's change address.

An implication of this is that darkwallet coinjoin mixing will become like an almost-riskless savings account. We already see that holders of bitcoin are willing to earn just 0.006% per day by lending btc on the bitfinex exchange, and that contains a substantial risk that bitfinex will go disappear or be hacked taking all the bitcoins with it.Darkwallet coinjoin with a maker's fees would be far less risky, the bitcoin private keys would never leave the owner's computer. This would likely result in investors pouring in. The huge relative supply of bitcoins along with the drought of other worthy bitcoin investments is likely to drive down the fees of mixing as the investors bid each other down.

The coinjoin takers will have access to tens of thousands of clean, untainted bitcoins to mix with at a very low price. The makers will have access to a very low risk investment for their bitcoins. Bitcoin fungiblility as a whole will benefit because the entire economy and flow of money will be more interrelated, making blacklists completely unfeasable. The market for coinjoin makers may end up so deep and liquid that three-party or even four-party coinjoins may become managable to organise.

Another idea: Instead of or in addition to specifying a max fee they're willing to pay, takers could specify an amount of time that they're willing to wait, and their wallet would pick a max fee based on that (similar to the new dynamic transaction fees in bitcoin-qt).

If a taker specifies a max fee of zero, in addition to looking for a zero-fee maker to pair with, their wallet should also look for other takers with similar transaction sizes to pair them with. Senders could even specify that they want to receive a fee rather than paying one, effectively turning them into makers as well, except that they want to send bitcoins in the process, rather than just idly mixing their funds.

These options do increase the complexity of the pairing algorithm, but would allow for a wider variety of preferences to be expressed on the mixing market. Incentivizing idle-mixing is a great idea, but we don't want to discourage send-mixing just because all the idle-mixers start expecting payment for it.

@belcher:The idea surely requires some more thoughts (potential incentives for sybil attacks, ...) but I like the analogy with mining.Miners are incentivized to ensure network security by blocks rewards and txs fees.With this model, users are incentivized to ensure better network privacy thanks to "coinjoin fees".Note that people at unsystem may have considered a similar idea (see bottom of this page (https://wiki.unsystem.net/en/index.php/DarkWallet/CoinMixing)).

Another idea: Instead of or in addition to specifying a max fee they're willing to pay, takers could specify an amount of time that they're willing to wait, and their wallet would pick a max fee based on that (similar to the new dynamic transaction fees in bitcoin-qt).

If a taker specifies a max fee of zero, in addition to looking for a zero-fee maker to pair with, their wallet should also look for other takers with similar transaction sizes to pair them with. Senders could even specify that they want to receive a fee rather than paying one, effectively turning them into makers as well, except that they want to send bitcoins in the process, rather than just idly mixing their funds.

These options do increase the complexity of the pairing algorithm, but would allow for a wider variety of preferences to be expressed on the mixing market.

Interesting idea. IMHO,we should make a distinction between what is defined at protocol level (e.g pairing of maker & taker if fees match) and more complex behaviours implemented by wallets (e.g. taker defines the max fee he wants to pay and how long he can wait and the wallet applies a strategy to get a coinjoin which optimizes user's goals).But I fully agree that UX will be key for adoption and that we should avoid too complex schemes.

Incentivizing idle-mixing is a great idea, but we don't want to discourage send-mixing just because all the idle-mixers start expecting payment for it.

That's another very good point but I'm not sure I reach the same conclusion.

Being a "constant" maker implies a few things :- your computer remains online and consumes energy => being a maker implies a cost (not comparable to mining costs but there's a cost)- you keep mixable coins in an hot wallet instead of a cold wallet => being a maker implies some risks

I'm sure that privacy enthusiasts may accept the cost and risk and become "constant" makers without a reward but this free model doesn't incentivize others people to become "constant" makers. The risk is that send-mixing is discouraged because there isn't enough makers and mixing takes too much time.

With fees, we may expect a range of offers (from 0 fee proposed by privacy enthusiasts to some X,Y, ... fees proposed by others makers).It seems reasonable to think that a fair "market price" should appear even if some makers may still propose 0 fee mixing in order to maintain the system.

@belcher:The idea surely requires some more thoughts (potential incentives for sybil attacks, ...) but I like the analogy with mining.Miners are incentivized to ensure network security by blocks rewards and txs fees.With this model, users are incentivized to ensure better network privacy thanks to "coinjoin fees".Note that people at unsystem may have considered a similar idea (see bottom of this page (https://wiki.unsystem.net/en/index.php/DarkWallet/CoinMixing)).

Yes. There's some good points raised by waxwing and others on the reddit thread that appeared.https://pay.reddit.com/r/Bitcoin/comments/2ku4tc/darkwallet_forward_from_irc_coinjoin_proposal/

Also painlord2k had suggested an idea like this too on the dev mailing list in Nov 2013. The idea is quite obvious so I'm not surprised its been thought of a few times.

So Sybil attacks.On the one hand it seems more honest coinjoin makers, motivated by their income, is a good thing because they crowd out the sybils.On the other hand, now the sybils get paid too so their cost of maintaining a maker (running a computer online, owning large amounts of bitcoins) is slightly reduced.Then there's also the coinjoin makers who were there in the status quo, people who just want to mix coins, don't mind waiting and would be willing to mix for free.I'm not sure which way it would swing. I intuitively think Sybils will find it harder in the fee-paying model but I'm not sure how to prove or disprove that.

Now for a Sybil attack new identities need to be cheap and easy to create. But Sybil coinjoin makers are actually expensive to create and maintain because they must have bitcoins which cant be used anywhere else while the attack goes on. If bitcoiners are happy with mining power being proportional to processor power, I imagine they will be happy with coinjoin making power proportional to bitcoin ownership.

Maybe an analogy helps to clarify somehow? If tor nodes were paid would sybils find it harder or easier? If bitcoin nodes were paid would sybil nodes find it harder or easier to operate?

As it seems that just-mined-bitcoins have a higher value on privacy, it would be cool to have something that show this to the end user.Something that show that some "offers" are better than others.

IMHO I would be against reducing the fungibility of bitcoins. Part of the purpose of all this coinjoin stuff is to keep bitcoins fungible so that it can be a good form of money.But your idea could be implemented by the makers publishing the UTXO they will use, and the takers can scan the entire blockchain to see how close it is to a coinbase transaction.

To people who like this idea. Be honest, how much did you like the part about generating an income from your own hoarded bitcoins. :)I'm guessing the psychological effect of earning interest on your coins, even if its only a few thousand satoshis a day, will be very strong.You all love getting money for doing nothing. Of course you do, that's part of the reason you chose to save and invest (In bonds, shares, and yes, bitcoins) rather than consume your entire income.

So we have to be careful our greed and entrepreneurial rapture don't blind us to some problem (sybil attack, etc)

So Sybil attacks.On the one hand it seems more honest coinjoin makers, motivated by their income, is a good thing because they crowd out the sybils.On the other hand, now the sybils get paid too so their cost of maintaining a maker (running a computer online, owning large amounts of bitcoins) is slightly reduced.Then there's also the coinjoin makers who were there in the status quo, people who just want to mix coins, don't mind waiting and would be willing to mix for free.I'm not sure which way it would swing. I intuitively think Sybils will find it harder in the fee-paying model but I'm not sure how to prove or disprove that.

Now for a Sybil attack new identities need to be cheap and easy to create. But Sybil coinjoin makers are actually expensive to create and maintain because they must have bitcoins which cant be used anywhere else while the attack goes on. If bitcoiners are happy with mining power being proportional to processor power, I imagine they will be happy with coinjoin making power proportional to bitcoin ownership.

Performing a coinjoin makes the maker's funds unavailable for a little while, right? Or can it be done safely with unconfirmed outputs? Either way, it might make sense to require inputs to have a certain number of confirmations in order to drive up the cost of a sybil attack. If the attacker can't make their funds available again immediately after performing a mix, they'll be severely limited in the number of mixes they're able to participate in. Perhaps takers could specify a minimum number of confirmations that they want the maker's inputs to have.

Takers will need to be wary of automatically accepting the lowest-priced mix offers, since that will give attackers a way to get their offers taken more often than those of comparatively higher-fee honest makers. Some sort of fuzzing is probably in order, i.e. "pick a random offer from available offers with fee from 0% to 0.5%" rather than "pick the lowest offer available, not to exceed 0.5%". Depending on how paranoid the taker is, they may want to do one or more coinjoin sends back to themselves, then a final coinjoin send to their intended recipient, increasing their odds of getting at least one good mix.

Quote

To people who like this idea. Be honest, how much did you like the part about generating an income from your own hoarded bitcoins. :)I'm guessing the psychological effect of earning interest on your coins, even if its only a few thousand satoshis a day, will be very strong.You all love getting money for doing nothing. Of course you do, that's part of the reason you chose to save and invest (In bonds, shares, and yes, bitcoins) rather than consume your entire income.

So we have to be careful our greed and entrepreneurial rapture don't blind us to some problem (sybil attack, etc)

Got me. I'm currently lending a significant chunk of my bitcoin savings on Bitfinex, though I'm not entirely certain that my income from it outweighs the counterparty risk. I'd love to be able to eliminate the counterparty risk entirely.

Without fees, I'd still operate as a coinjoin maker, since I want financial privacy for myself, I want to "stick it to the man", and I want to help others gain financial privacy as well. However, being paid would make the difference between acting as a maker part time with small amounts and doing so full time with large amounts. Which is the whole point of this proposal, after all. :)

A quick thought : I think the answer will depend on the type of attacker you consider. My previous comment about 3 letters agency was almost a joke but I think that for this kind of "attacker", reward/no reward doesn't make any difference because of their financial resources. Having a financial incentive may increase the number of makers and you can expect that some people won't be catched by the attacker but I'm not really sure it will make a big difference.

To people who like this idea. Be honest, how much did you like the part about generating an income from your own hoarded bitcoins. :)I'm guessing the psychological effect of earning interest on your coins, even if its only a few thousand satoshis a day, will be very strong.You all love getting money for doing nothing. Of course you do, that's part of the reason you chose to save and invest (In bonds, shares, and yes, bitcoins) rather than consume your entire income.

So we have to be careful our greed and entrepreneurial rapture don't blind us to some problem (sybil attack, etc)

Human "greed" is precisely the interesting factor for this model.Privacy usually comes with a cost (in term of UX or financial cost, ...) and no "obvious" reward (except for people having a "shadow" activity). The outcome is that digital privacy is at a very low level for many people. IMHO, introducing a reward may be an important factor to increase adoption.

Let's make a parallel with bitcoin security. This security is enforced by mining and full nodes.Mining comes with a reward and hashpower is skyrocketing. Full nodes have no reward and their number is almost constant or decreasing...

Hi everybody, i have a question regarding the cascads and transaction fees.

So, in the first post it says that you can get better anonymity when you cascade your outputs.

If i have 5 BTC and find e.g. 3 People who also want to anonymize 5 BTC i can make a CoinJoin transcation tx_1 with them. The first (minor) problem is, that we have to pay transaction fees. So every praticipant have inputs with at least 5.1 BTC (0.1 BTC for fees). If we have that, we can make the transaction tx_1 where the outputs have a value of 5 BTC.The problem that i see is, that if i want to cascade, say 3 times, i have to pay transaction fees every time.I see two ways one could do that.

1. The transaction fees for the second transaction, which uses the output from transaction tx_1 is paid only from that output/input. So i have to find participants who want to make a CoinJoin Transaction with an Output of 4.9 BTC (5BTC - 0.1 Fee) which could be hard, or i find participants who want to make a transaction with less than 4.9 BTC. If i allow participants with lower values the rest is send to an change address of mine. But in this case i can't , in the beginning, know how much Bitcoins i have left in the output after say three cascades.So if i want a cascade of three and at the end i want to have 5 anonymous BTCs the first Input must be 5.3 BTC -> output ist 5.2. The second Input is 5.2 BTC -> output 5.1 BTC. The third Input is 5.1 BTC -> 5.0 output.I think it could be hard to find participants with exactly the amount of Inputs that i need. Furthermore i have to know in advance how long my cascade has to be and how much bitcoins i want in the end.

2. The transaction fees is paid by another Input.So Alice makes transaction tx_1 with an Input of 5.1 BTC -> output is 5.0 BTC.The second transaction tx_2 consists of the Input with 5.0 BTC from the last transaction, and a new Input with 0.1 BTC for my fees.Assume an attacker who can match all Bitcoin addresses to the person behind these addresses excluding the output addresses used for outputs in CoinJoin transactions.If Alice uses an address for the transaction fees input , which the attacker can match to Alice, the attacker knows which output of tx_1 belongs to Alice. Why?The attacker knows who participates in tx_1 because he knows the persons behind the inputs. The only thing he doesn't knows is, which ouput belongs to which participan. But if one output is used in a second transaction in which Alice pays the fees for, and no other input in that transaction could come from Alice, the only plausible way is, that Alice is the owner of the ouput from tx_1 which is used in tx_2. In that case the anonymity of the CoinJoin Transaction tx_1 is broken.This even works if the fee Input comes from another CoinJoin transaction. You just have to look at the inputs of the CoinJoin transaction uses for the fee input, if one input matches an address of Alice you can be pretty sure, that the output from tx_1 also belongs to Alice.

So my question is, am i missing something, or is this really a problem when using cascades in CoinJoin. Cause i see no other option than the first case, if you want to use cascades and don't want the anonymity broken by the fees.

Hi everybody, i have a question regarding the cascads and transaction fees.

So, in the first post it says that you can get better anonymity when you cascade your outputs.

If i have 5 BTC and find e.g. 3 People who also want to anonymize 5 BTC i can make a CoinJoin transcation tx_1 with them. The first (minor) problem is, that we have to pay transaction fees. So every praticipant have inputs with at least 5.1 BTC (0.1 BTC for fees). If we have that, we can make the transaction tx_1 where the outputs have a value of 5 BTC.The problem that i see is, that if i want to cascade, say 3 times, i have to pay transaction fees every time.I see two ways one could do that.

1. The transaction fees for the second transaction, which uses the output from transaction tx_1 is paid only from that output/input. So i have to find participants who want to make a CoinJoin Transaction with an Output of 4.9 BTC (5BTC - 0.1 Fee) which could be hard, or i find participants who want to make a transaction with less than 4.9 BTC. If i allow participants with lower values the rest is send to an change address of mine. But in this case i can't , in the beginning, know how much Bitcoins i have left in the output after say three cascades.So if i want a cascade of three and at the end i want to have 5 anonymous BTCs the first Input must be 5.3 BTC -> output ist 5.2. The second Input is 5.2 BTC -> output 5.1 BTC. The third Input is 5.1 BTC -> 5.0 output.I think it could be hard to find participants with exactly the amount of Inputs that i need. Furthermore i have to know in advance how long my cascade has to be and how much bitcoins i want in the end.

2. The transaction fees is paid by another Input.So Alice makes transaction tx_1 with an Input of 5.1 BTC -> output is 5.0 BTC.The second transaction tx_2 consists of the Input with 5.0 BTC from the last transaction, and a new Input with 0.1 BTC for my fees.Assume an attacker who can match all Bitcoin addresses to the person behind these addresses excluding the output addresses used for outputs in CoinJoin transactions.If Alice uses an address for the transaction fees input , which the attacker can match to Alice, the attacker knows which output of tx_1 belongs to Alice. Why?The attacker knows who participates in tx_1 because he knows the persons behind the inputs. The only thing he doesn't knows is, which ouput belongs to which participan. But if one output is used in a second transaction in which Alice pays the fees for, and no other input in that transaction could come from Alice, the only plausible way is, that Alice is the owner of the ouput from tx_1 which is used in tx_2. In that case the anonymity of the CoinJoin Transaction tx_1 is broken.This even works if the fee Input comes from another CoinJoin transaction. You just have to look at the inputs of the CoinJoin transaction uses for the fee input, if one input matches an address of Alice you can be pretty sure, that the output from tx_1 also belongs to Alice.

So my question is, am i missing something, or is this really a problem when using cascades in CoinJoin. Cause i see no other option than the first case, if you want to use cascades and don't want the anonymity broken by the fees.

I hope you can unterstand what i mean.

GreetingsDuky

I think I have a rough understanding of what you're pondering. I believe that OP has dropped transaction fees from the introduction for simplicity and from the tone it should be clear that he's primarily interested in a little extra privacy as opposed to hardened secrecy.

If we assume the hostile environment of your scenario 2 and desire regular, thorough mixing then I would first think about dropping the "all inputs/outputs should be of the same size" assumption. Of course, we'd have to take care here not to allow varying input/output sizes to reveal too much information. If we want regular mixing we really also ought to tackle the issue of combining outputs (always a pain). Here's a first thought:

Inputs

(5)

Outputs

(110)

Party_A:

1.5671 BTC

1 x

1 BTC

0.3894 BTC

29 x

0.1 BTC

0.0015 BTC

25 x

0.01 BTC

Party_B:

1.5000 BTC

33 x

0.001 BTC

Party_C:

0.7082 BTC

22 x

0.0001 BTC

0.0203 BTC

(Fee: 0.0013 BTC)

I'm afraid I lack the time to explain everything I'm thinking here but I hope this example transaction gives you an idea or two. I'll happily try to tackle a follow-up question if you have one.

The coinjoiner bots meet in an IRC channel. The bots announce their orders in an open-outcry trading pit style. Transaction data is sent between users as IRC private messages. Encryption is a planned feature to stop the IRC server eavesdropping. I have plans one day to move away from IRC entirely and have the users meet in some kind of peer to peer network.

The coinjoiner bots meet in an IRC channel. The bots announce their orders in an open-outcry trading pit style. Transaction data is sent between users as IRC private messages. Encryption is a planned feature to stop the IRC server eavesdropping. I have plans one day to move away from IRC entirely and have the users meet in some kind of peer to peer network.

Only pocket change amounts for now, if anyone found an exploit bug they could theoretically clean out your wallet. My yield generator bot is running happily right now, I've already earned about 25000 satoshi.

I will be working on an Electrum plugin to make it easy to use. Electrum doesn't have a testnet version which is one reason we've moved to the mainnet now.

In order to further incentivize work in this space there is now a multisignature escrow bounty fund:

3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk (bitcoin:3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk) (yes, Bitcoin addresses can also start with a 3)

This is a two-of-three multisignature escrow with myself, Theymos, and Pieter Wuille as signers. To release any coin sent to this address at least two of these people must sign the transaction.

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.

Please feel free to contribute to the above address to support work on this infrastructure.

I would like to make a claim on this fund for work done on Compact Confidential Transactions (subject to the ongoing peer review).

https://bitcointalk.org/index.php?topic=1085436.msg11597427

CoinJoin should 'just work' in this scheme, and has a similar interface to gmaxwell's Confidential Transactions for keeping participant's balances hidden from other participants.

Participants generate some random inputs, and same number of random outputs, to themselves with a zero sum, and ensure that they do not introduce any fuzz over/underflow, so the fee is fixed.

An alternative approach, is to let participants share only their fee delta, guaranteeing that everyone makes the same fee adjustment, in which case the number of outputs can also differ to the number of inputs for each participant.

If anyone puts in too much or too little, their sum, and the whole transaction sum, won't come out as zero and the transaction will be invalid.

In order to further incentivize work in this space there is now a multisignature escrow bounty fund:

3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk (bitcoin:3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk) (yes, Bitcoin addresses can also start with a 3)

This is a two-of-three multisignature escrow with myself, Theymos, and Pieter Wuille as signers. To release any coin sent to this address at least two of these people must sign the transaction.

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.

Please feel free to contribute to the above address to support work on this infrastructure.

I would like to make a claim on this fund for work done on Compact Confidential Transactions (subject to the ongoing peer review).

https://bitcointalk.org/index.php?topic=1085436.msg11597427

CoinJoin should 'just work' in this scheme, and has a similar interface to gmaxwell's Confidential Transactions for keeping participant's balances hidden from other participants.

Participants generate some random inputs, and same number of random outputs, to themselves with a zero sum, and ensure that they do not introduce any fuzz over/underflow, so the fee is fixed.

An alternative approach, is to let participants share only their fee delta, guaranteeing that everyone makes the same fee adjustment, in which case the number of outputs can also differ to the number of inputs for each participant.

If anyone puts in too much or too little, their sum, and the whole transaction sum, won't come out as zero and the transaction will be invalid.

It looks like you might need to write some code, as the post says "for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users."

It looks like you might need to write some code, as the post says "for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users."

Just as well that it does not say "for completed code". Otherwise I would be going against the thing. In a knowledge economy, new knowledge (and new code) takes a lot of completed works. Anyway, the review is not complete yet so my claim might not be valid. And even if it is valid or invalid logically, the fund is ultimately at the discretion of two individuals. If they want to encourage or discourage this kind of research is up to them.

In order to further incentivize work in this space there is now a multisignature escrow bounty fund:

3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk (bitcoin:3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk) (yes, Bitcoin addresses can also start with a 3)

This is a two-of-three multisignature escrow with myself, Theymos, and Pieter Wuille as signers. To release any coin sent to this address at least two of these people must sign the transaction.

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.

Please feel free to contribute to the above address to support work on this infrastructure.

Multisig address construction details:

Code:

Key from Theymos:-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256

Here is a public key of mine, usable for the CoinJoin bounty fund:02d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b-----BEGIN PGP SIGNATURE-----

The bounty fund will pay out [...] for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.

Would this suite Joinmarket? https://bitcointalk.org/index.php?topic=919116

Was the work proposed in this thread?

I guess only gmaxwell knows the answer to this question. In my eyes Joinmarket is going further than what has been suggested in this thread as it adds the incentive necessary for CoinJoin to actually go somewhere.

I will be working on an Electrum plugin to make it easy to use. Electrum doesn't have a testnet version which is one reason we've moved to the mainnet now.

At this point, do you have an Electrum plugin? If so, where to go to find it?Am assuming at this point, it's probably here..https://github.com/JoinMarket-Org/joinmarket/issues/44and alsohttps://github.com/JoinMarket-Org/joinmarket/tree/electrum-pluginIf there's a particular file that needs attention/work pls. advise.

The electrum plugin would work by having a sidecar daemon that the plugin sends transaction information to and obtains an unsigned coinjoin transaction. The files are electrum-plugin-daemon.py and electrum-plugin.py, although that branch is probably quite stale.

IMHO, it could be used as a load balancing device for a system with a fixed block size limit. CoinJoins happen automatically to help compress more transactions into the available block space. This could provide a good argument against a scheme with a continuously variable block size, or to a scheme with no limit at all (although I don't think anyone has yet made any serious proposal for the latter). It also illustrates that CoinJoin really is just that, joining inputs and outputs into single transactions, regardless of the utility you're seeking from doing so.

IMHO, it could be used as a load balancing device for a system with a fixed block size limit. CoinJoins happen automatically to help compress more transactions into the available block space. This could provide a good argument against a scheme with a continuously variable block size, or to a scheme with no limit at all (although I don't think anyone has yet made any serious proposal for the latter). It also illustrates that CoinJoin really is just that, joining inputs and outputs into single transactions, regardless of the utility you're seeking from doing so.

Interesting. What is the effective 'compression' of doing several individual TX versus a single CoinJoin containing the same TXs?

IMHO, it could be used as a load balancing device for a system with a fixed block size limit. CoinJoins happen automatically to help compress more transactions into the available block space. This could provide a good argument against a scheme with a continuously variable block size, or to a scheme with no limit at all (although I don't think anyone has yet made any serious proposal for the latter). It also illustrates that CoinJoin really is just that, joining inputs and outputs into single transactions, regardless of the utility you're seeking from doing so.

Interesting. What is the effective 'compression' of doing several individual TX versus a single CoinJoin containing the same TXs?

There's a fair proportion of header/data for single output -> pair of outputs, but mamadmankan is only identifying the first steps in the line of thinking that led to stuff like SegWit and Lightning.

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.

If JoinMarket did not qualify, and CoinShuffle (or ShuffleCoin?) did not also qualify, what would do it? Does it have to be completely decentralized? Can it be something that relies on a "super-node" or even a third party website, bot or api? (Someone collects possible transactions and makes everyone sign it once a day or once an hour or something.)

How do you define "practical reality for Bitcoin users"?

Did I miss any other attempts at implementing this aside from CoinShuffle and JoinMarket?

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.

If JoinMarket did not qualify, and CoinShuffle (or ShuffleCoin?) did not also qualify, what would do it? Does it have to be completely decentralized? Can it be something that relies on a "super-node" or even a third party website, bot or api? (Someone collects possible transactions and makes everyone sign it once a day or once an hour or something.)

How do you define "practical reality for Bitcoin users"?

Did I miss any other attempts at implementing this aside from CoinShuffle and JoinMarket?

Coinshuffle is really an enhancement protocol on top of any coinjoin implementation, it's not a coinjoin implementation itself. There hasn't as yet been an implementation using it (correct me if I'm wrong), so from that point of view the question doesn't apply to coinshuffle, although Mycelium are currently working on one.

I have a question: When I am doing a transaction and I send my signed tx to the network. Could someone else take that transaction and add a additional signed input to the tx. So this would mean that my tx gets coinjoined without my approval, would that be accepted by the network?

I have a question: When I am doing a transaction and I send my signed tx to the network. Could someone else take that transaction and add a additional signed input to the tx. So this would mean that my tx gets coinjoined without my approval, would that be accepted by the network?

Greets

From what I understand, that is not possible; or not practical. You'll have to coinjoin your transactions first before sending it to the network.

It may be possible with the replace-with-fee thingie, but if the first transaction gets confirmed, then the second one won't work anymore as it will be a double-spend.

For CoinJoin to work, people need to join their signed tx first. The only way I see this working is some sort of third-party that does the joining, or some app that does it for everyone involved, at the same time, or waiting within a set time.

I think what's happening is people meet up and then agree to do a CoinJoin, either in chat or through some app or website, the third-party not being able to steal any coins in the process.

Effective coinjoin that doesn't create metadata patterns of its own is hard.

If you want the capital-S Solution, the Zerocoin protocol is down the hall - but it wasn't, and won't be, implemented in Bitcoin because the cryptographic accumulator comes with ridiculous compute-time overhead for verifying spends.

If you want a lowercase-s Solution, Dash has its mixing masternodes; some node operator posts a big bond to the block chain to get to be trusted for pooling, and then people run their transactions through a dozen different masternodes that cant see what each other are doing to get them thoroughly mixed before they go on to the block chain. This doesn't suck, but it's also not ideal; those masternodes are "trusted" in the sense that if they cooperate they can de-anonymize transactions.

But coinjoin, in the absence of mixing services (aka masternodes) to join transactions between arbitrary people who've never heard of each other, creates exactly the kind of metadata it seeks to avoid. People analyze the block chain and coinjoined transactions attract attention because they are anomalous in terms of how their inputs and outputs are connected to other tx. When the chain is analyzed further, the snoops can identify which actors know each other and cooperated together to create the coinjoin.

But coinjoin, in the absence of mixing services (aka masternodes) to join transactions between arbitrary people who've never heard of each other, ...

That's the thing. The only missing element is a decentralized version of this. Mixing services that do CoinJoin can exist, I'm just wondering if that qualifies for the bounty here.

The few CoinJoin transactions that exist now can be analyzed, but when the volume and frequency of such transactions get big enough and often enough, it's practically impossible to analyze, especially if all actors are anonymous ...

All that people really need to give up is a little inconvenience, because they have to run their coins through such "masternodes", it's not automatic.

Normal people can send their CoinJoin transactions and their coins to some "masternode" while they sleep. A few hundred people to a few thousand people do this and in 8 hours to a day later you don't know who owns what coins. If this is done daily or with other mixers, every day, every month, the whole year ... do we achieve our goal then?

When you have XAB mod G, (where X and G are public) you can find B if you know A, or you can find A if you know B, but you can't find AB, or A, or even B, unless you know the factors of G.

So you can multiply the exponent by a couple of factors and produce a new accumulator - and nobody can tell what the factors were. But later you can undo it, because you know what the factors were. And you can do this even if a dozen other people have since added or removed values to the accumulator, in any order.

In a lot of ways, what the people forming a coinjoin are doing is passing around an accumulator. None of them knows what the others are putting in, but each is able to check the final accumulator and make sure their own input is part of it (ie, their values are still factors of the exponent). And then if they break it down in a different order, at no time does it acquire the same value as it had at any previous state or one easily related to such - but it returns to the same initial state when everybody's value has been taken out of it.

That's sort of a truncated version of what Zerocoin does - but if you work out the details, you might be able to do it without that horrible zero-knowledge signature of knowledge proof. People would only have to verify steps and final result of a single join per block.

The way things are now, snoops looking at the block chain can mostly tell which transactions were made by the same people as other transactions. If they identify a single thing as belonging to a particular person (which is usually easy, because among other things they listen on the network to get the IP addresses where tx originate) then they can generally walk it back and identify every other transaction that person has ever made from that wallet.

People generally don't think this is okay. Even if they're not crooks they don't necessarily want everybody else to know when and where they bought a dirty magazine and some hand lotion - or, you know, bondage gear or any number of other things that are just plain private.

So they look for a way to mix up transactions; store txOuts in the block chain somehow where snoops can't tell which belongs to whom. When a hundred people do a coinjoin, you take a bunch of different transactions, and make them into one giant transaction, with maybe hundreds of different txIns and txOuts - and now the snoops can't tell any more which of the txOuts belongs to whom. If you then open a new wallet and put the txOuts from the coinjoin into it and no txOuts from your old wallet, they'll never be able to link the purchases you made (or payments you received) before the coinjoin with the ones after it. At most they'll be able to tell such-and-such a purchase group of purchases after the coinjoin was made by one of the hundred people who participated in this coinjoin transaction.

But it's dastardly hard to do this in such a way that when you're exchanging messages to set up the coinjoin, you don't give the eavesdropping snoops enough information to suss out which txOuts from the coinjoin belong to whom. Especially since everybody has to be able to verify that the transactions are correct.

So what you try to do is things like Diffie-Hellman key exchange, where you can have two people (or in this case way more than two) find a secret value together (in diffie-hellman a key; in coinjoin a whole transaction) without giving snoops any clues.

This is made harder by the difference between the two use cases. In Diffie-Hellman the parties don't care much what the value winds up being; only that they agree on what it is and nobody who's been listening to them can suss it out. But with coinjoin you care a whole lot about exactly what the value is, because the value you're trying to agree on has to be a valid transaction that does what you want it to do.

So we need things more complicated than just hashes and bit commitments and signatures; we need things like cryptographic accumulators and commutative encryption, which are sort of esoteric and usually really compute expensive.

Somebody figured out a way to do it with a compound-exponential accumulator under a modulus (called the ZeroCoin protocol) but it's ridiculously compute-intensive; it would mean everybody has to spend five minutes or so just checking correctness after each block, and people with 'weak' machines couldn't check those tx at all. I've been wondering about a way to do it using single-exponential accumulators and bit commitments.

Note: An 'accumulator' is a keyed transformation such that

A ==> Encrypt with key1, key2, key3, etc, in any order ==> Decrypt with key1, key2, key3, etc in any order ==> A.

You could use something like that to show that you have one of the keys that went into creating it, without revealing which. That is, assuming you manage to not reveal the key that went into creating it when you encrypt it the first time. Which, if you don't, makes the transaction hard to check....

Is there a difference between a CoinJoin transaction and a regular bitcoin transaction that has many inputs and many outputs? What I mean is, for example, I have a large wallet with 10 different and unconnected unspent bitcoins, in 10 separate addresses. Then since I am the owner of that wallet, I can do a transaction and use those 10 as inputs to a transaction that pays out or sends out bitcoins to 20 different addresses.

What I'm wondering is if there is a fundamental difference between that, and a CoinJoin transaction with 9 other people.

Yes, I've read and re-read the original post and this entire thread, I'm just seeking clarification if I am understanding this correctly.

Is there a difference between a CoinJoin transaction and a regular bitcoin transaction that has many inputs and many outputs? What I mean is, for example, I have a large wallet with 10 different and unconnected unspent bitcoins, in 10 separate addresses. Then since I am the owner of that wallet, I can do a transaction and use those 10 as inputs to a transaction that pays out or sends out bitcoins to 20 different addresses.

What I'm wondering is if there is a fundamental difference between that, and a CoinJoin transaction with 9 other people.

Yes, I've read and re-read the original post and this entire thread, I'm just seeking clarification if I am understanding this correctly.

There's no difference other than that with a coinjoin the inputs are owned by different people whereas with the transaction you made all the inputs were owned by you.

Before coinjoin, you could look at a transaction and be pretty certain that all its inputs were owned by the same wallet. People would use this information to cluster addresses into groups.

After coinjoin that assumption is no longer valid. Multiple parties can cooperate to sign a single transaction where they each own some of the inputs. This makes clustering by ownership harder to do.

Is there a difference between a CoinJoin transaction and a regular bitcoin transaction that has many inputs and many outputs? What I mean is, for example, I have a large wallet with 10 different and unconnected unspent bitcoins, in 10 separate addresses. Then since I am the owner of that wallet, I can do a transaction and use those 10 as inputs to a transaction that pays out or sends out bitcoins to 20 different addresses.

What I'm wondering is if there is a fundamental difference between that, and a CoinJoin transaction with 9 other people.

In terms of the bytes that appear in the transaction itself, there is no difference.

The difference is all in what the snoops can infer from the bytes. When you make that transaction you described, the snoops would look at the block chain and say,

Oh, these twenty new addresses were all funded by the same transaction. Therefore all the funding came from the same source (because almost always it's a single source sending money). And since this doesn't look like a purchase (purchases typically have one large output and one much smaller "change" output) it must have been a logistical or bookkeeping movement of coins. So we're going to assume that now all twenty of these new addresses are owned by the same person.

Later on, they'll confirm it if, say, one of those 20 outputs gets spent, and you get a millibitcoin of change, and then later that millibitcoin of change gets spent in the same transaction as another of those 20 outputs, or as change from another of those 20 outputs - they go, Aha, look! This new evidence means that what we thought about the addresses being owned by the same person, is now confirmed! These two txOuts were owned by the same person, and now we can link all the purchases that were made with both of them!

Now consider what happens with a coinjoin. Alice is buying an Anvil, Bob is buying a Book. Carol is buying a Coat, Dave is buying a duck, and so on.... Maybe Zebulon is buying a Zebra, who knows. They do a coinjoin transaction, and there's an output to the blacksmith shop and an output to the bookstore, and an output to the clothier, and also outputs to Alice, Bob, Dave, Carol, and everybody else - and the outputs are all kinds of different sizes instead of just being clearly "payment" and "change."

Superficially, it looks like the same transaction. Some number of inputs, some number of outputs. But the snoops looking at it say, "Oh, all these inputs must have come from the same person, and it doesn't look like a regular purchase, so we'll assume all the outputs are going to the same person too...." except this time they're wrong. They'll pretty quickly figure out (because the way merchants combine the money that they get paid is very obvious) which outputs went to merchants and how much each merchant got. They may be able to backtrace a lot of the unconnected txIns to figure out who owned them before the transaction. But they will never figure out who it was that bought the duck, who it was that bought the book, and who it was that bought the zebra. The best they'll be able to say is, "one of these people whose coins went into the transaction."

And by the same token, even after they figure out which outputs were paid to merchants, they won't know which of those people now have the other outputs, until or unless those other people spend them along with txOuts they can link to that person. Again, best they'll be able to say is "one of these people whose coins went into the transaction."

But this requires that Alice, and Bob, and Carol, and Dave, etc have a way to set up the coinjoin that Eve can't figure out. Even if Eve is one of the people putting coins into the coinjoin and getting coins out, she shouldn't be getting information about what other people are putting in and getting out.

But it's dastardly hard to do this in such a way that when you're exchanging messages to set up the coinjoin, you don't give the eavesdropping snoops enough information to suss out which txOuts from the coinjoin belong to whom. Especially since everybody has to be able to verify that the transactions are correct.

So what you try to do is things like Diffie-Hellman key exchange, where you can have two people (or in this case way more than two) find a secret value together (in diffie-hellman a key; in coinjoin a whole transaction) without giving snoops any clues.

I realise this doesn't fully speak to what you're musing on in that post, but thought it might add to the discussion:

In Joinmarket we use E2E encryption authenticated to the bitcoin pubkeys that the different parties use as inputs to prevent MITM. This prevents a non-participant from learning the linkages.

As to preventing counterparties knowing the linkages, that's discussed in the first post(s) here. There are several ways to do it. The simplest is to have a server that's trusted, obviously suboptimal. You can add blind signing with network-level anonymisation to cut the connection between the proposal and the signing. To achieve the same effect you can use Coinshuffle. But, these two approaches don't address the Sybil problem - if all your counterparties are the same person, they learn the linkages by elimination.

Joinmarket allows one of the participants to act as the central coordinator - called the taker - and so only the taker gets the full defence against others knowing linkages - and so pays for that privilege (albeit in practice the payment is ultra-small). the other participants still get the defence against outside parties knowing the linkage due to the E2E encryption. And the Sybil problem remains; while we have some ideas about making it harder (see e.g. here: https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8 , although there are other ideas/things to be said), we haven't implemented it.

The network level snooping: as where tx broadcasts originate - can be addressed with Tor to some extent. We also have things like randomising which participant broadcasts the transaction (a feature that belcher recently added). But as you mention there's also the issue of where you source the data to verify inputs (e.g. if you use a centralised blockchain API it's decidedly suboptimal).

On the topic of whether a coinjoin is discoverable/watermarkable let's say, I'd say a couple of things: if coinjoins follow an identifiable pattern, it certainly doesn't mean that they're useless; the main effect that a coinjoin output (i.e. equal sized output) is fundamentally indistinguishable from its neighbour coinjoin outputs is still true. That's the main effect we're looking for. The only conceivable negative is that the inputs to such a transaction are marked "This wallet closure is suspicious"; although I think any good "Bitcoin citizen" should prefer to use coinjoins where it's practical, since this is a currency and it's intended to be fungible. I've tried to make most of my recent retail payments with coinjoins.

Wallet closure analysis *is* damaged (severely) by use of coinjoins and that's the intention. Trying to make them invisible (i.e. not have properties distinct from non-coinjoins) seems like a high bar to set, and a moving target. I know Kristov Atlas has been looking into how transaction structures could be standardized to facilitate this; it seems like a hard goal to reach, but worth looking into.

Second, Joinmarket coinjoins are fairly easily found (with some false positives of course), see e.g.: https://github.com/AdamISZ/JMPrivacyAnalysis/blob/master/tumbler_privacy.md#identifying-joinmarket-transaction-types and Adlai's even made a tool to automate finding them on the blockchain: https://github.com/adlai/cjhunt.

TLDR I don't think coinjoins being identifiable is such a bad thing; even the most brain-dead construction is better for privacy than a non-coinjoin in any case, and by a long way.

I have a question: When I am doing a transaction and I send my signed tx to the network. Could someone else take that transaction and add a additional signed input to the tx. So this would mean that my tx gets coinjoined without my approval, would that be accepted by the network?

Greets

Not possible unless you explicitly chose to use non-standard sighash flags (and even then! possibly it could happen with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY).

I have a question: When I am doing a transaction and I send my signed tx to the network. Could someone else take that transaction and add a additional signed input to the tx. So this would mean that my tx gets coinjoined without my approval, would that be accepted by the network?

Greets

Not possible unless you explicitly chose to use non-standard sighash flags (and even then! possibly it could happen with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY).

Or in layman's terms, by default every signature is signing the complete set of inputs and outputs. If you change any input or output the signatures become invalid.

But for people to do the CoinJoin, they all have to sign the same transaction, thus the possibility of a denial of service attack (by pretending to be part of the process but not signing the transaction.)

From what I understand, this "network level snooping" can only be done live, or someone or something is watching a good number of nodes, because the blockchain data itself does not store ip addresses. The transaction doesn't have any ip address information either. And where the transaction is first relayed is no indication that that is the one that actually sent it. And in any case, with a CoinJoin with a good number of real people, it doesn't matter who sent it as everyone else signed it, the one who actually broadcasts the transaction can be anyone, or even a completely different entity, or went through Tor or a VPN or from some random internet cafe. (Spammers do it all the time and are rarely or never caught.)

So, the problem is: too big a CoinJoin, (like with a few thousand) is hard to pull off, and some people might not go through with it. Too small, (such as 2 or 3 or 4 inputs and outputs) and its too easy to analyze.

So, if someone comes up with a "trusted" server, or shall I say "trustless" server, even if it is suboptimal, then that's still a good thing as long as that server is not compromised, or it doesn't keep logs after every transaction or something like that.

I mean, I can see at least 2 really big "traditional" mixers on these forums. The biggest one supposedly has a reserve of 3000 BTC. These guys can certainly pull it off, many people already trust them to mix "traditionally", I don't suppose they'd have a problem getting the same users to trust them to "CoinJoin" the whole thing and include their reserve in the process.

I have an idea, and guys, let me know if this is decent or crazy or whatever: or if this is already what is being done by JoinMarket, Shuffle, Whatever.

1. I make a website or a server for this purpose.2. It asks users to create their transactions, and a given time limit, say 30 minutes or 1 hour.3. Every 30 minutes, or every hour, it gets back to all the users with the giant CoinJoin transaction formed thus far and asks all the people to sign.4. The site itself takes a fee, and that's some how inserted into the process.5. Assuming the site is "trustable", then only outsiders are "attackers" and they're not going to learn much except "I see 100 inputs and 200 outputs, and I own 20 of them. I dunno who the other 80 are."6. Repeat every hour or every whenever. Or every 100 people. Or once a day.7. Java script or open source client side signing thingy that can sign for you if you're away from your computer so the site doesn't have to wait an hour when it reaches the minimum number of people.

The other idea I had, which I mentioned a long time ago, is like a traditional mixer, in that the mixer site itself has to be trusted, but it does everything internally, and you just send your coins. Instead of the traditional mixing of unrelated inputs and outputs, it's basically a CoinJoin mixer that gets all deposits and spits out the transactions just like a traditional mixer. The only downside is having to trust the site.

I have an idea, and guys, let me know if this is decent or crazy or whatever: or if this is already what is being done by JoinMarket, Shuffle, Whatever.

1. I make a website or a server for this purpose.2. It asks users to create their transactions, and a given time limit, say 30 minutes or 1 hour.3. Every 30 minutes, or every hour, it gets back to all the users with the giant CoinJoin transaction formed thus far and asks all the people to sign.4. The site itself takes a fee, and that's some how inserted into the process.5. Assuming the site is "trustable", then only outsiders are "attackers" and they're not going to learn much except "I see 100 inputs and 200 outputs, and I own 20 of them. I dunno who the other 80 are."6. Repeat every hour or every whenever. Or every 100 people. Or once a day.7. Java script or open source client side signing thingy that can sign for you if you're away from your computer so the site doesn't have to wait an hour when it reaches the minimum number of people.

I don't know if you're aware, but joinmarket exists (has done for a year on mainnet now), it's doing maybe 50-100 transactions per day (hard to get numbers without running the blockchain analysis mentioned above; and false positives there will confuse it). You can see the orderbook at https://joinmarket.me/ob

As for the description above, it's fine (it's the first, simplest design mentioned by gmaxwell in the OP) but having the server know all the linkages is a bit much. Joinmarket has one participant act as the coordinator for each transaction, and pay for the privilege of knowing the linkages for that transaction (I'm repeating myself now, I said this a few posts back). Instead of one server with a global history. To go further, you add Coinshuffle or blind signing so that no-one needs to know the linkages (assuming no Sybil case, i.e. other participants are really distinct).

The economic incentive, while small, helps create more participants. Most joinmarket coinjoins involve 3-6 participants although 10+ is not unheard of (I myself had a couple of 9,10 party joins recently, e.g. e701bc57fa663eaef4d57a9ea20b3212a90a8be71a32bd3bcb84062e864bdab0).

I have an idea, and guys, let me know if this is decent or crazy or whatever: or if this is already what is being done by JoinMarket, Shuffle, Whatever.

1. I make a website or a server for this purpose.2. It asks users to create their transactions, and a given time limit, say 30 minutes or 1 hour.3. Every 30 minutes, or every hour, it gets back to all the users with the giant CoinJoin transaction formed thus far and asks all the people to sign.4. The site itself takes a fee, and that's some how inserted into the process.5. Assuming the site is "trustable", then only outsiders are "attackers" and they're not going to learn much except "I see 100 inputs and 200 outputs, and I own 20 of them. I dunno who the other 80 are."6. Repeat every hour or every whenever. Or every 100 people. Or once a day.7. Java script or open source client side signing thingy that can sign for you if you're away from your computer so the site doesn't have to wait an hour when it reaches the minimum number of people.

The other idea I had, which I mentioned a long time ago, is like a traditional mixer, in that the mixer site itself has to be trusted, but it does everything internally, and you just send your coins. Instead of the traditional mixing of unrelated inputs and outputs, it's basically a CoinJoin mixer that gets all deposits and spits out the transactions just like a traditional mixer. The only downside is having to trust the site.

I think it's at least a decent idea, although implementation might be tricky. One limitation with JoinMarket is the ability to easily facilitate a transaction with a very large number of parties. As of right now, there are only about 50 "makers" on the orderbook (https://joinmarket.me/ob/), and likely many of those are actually the same people, running multiple yield generator bots. The largest coinjoin done using JoinMarket that I am aware of had 17 parties. (that might not even be the most interesting thing about that transaction... (https://btc.blockr.io/tx/info/3e1572ca351d743d7bf627bc844da8f3bdc84eab4a9d27934a8dba30a2e05fe1))

???

I think something like this would be possible to build within JoinMarket, such that "takers" are given an option to delay and group their transaction with other takers (and makers, maybe), but again, I'm sure the coding would be substantial. A better solution for JoinMarket will likely be simple growth. The GUI is probably helping to bring in more users. An Electrum plugin could also be potentially huge for JoinMarket, bringing fungibility (is that a word?) to many more users. I think some privacy conscious websites may also benefit from implementing JoinMarket transactions into their wallet structure (online casinos, darknet markets, etc.) which will also help the current limitations.

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.

If JoinMarket did not qualify, and CoinShuffle (or ShuffleCoin?) did not also qualify, what would do it? Does it have to be completely decentralized? Can it be something that relies on a "super-node" or even a third party website, bot or api? (Someone collects possible transactions and makes everyone sign it once a day or once an hour or something.)

How do you define "practical reality for Bitcoin users"?

Did I miss any other attempts at implementing this aside from CoinShuffle and JoinMarket?

Would be interested to know as well.Six months ago I sent a PM to theymos, Pieter Wuille, gmaxwell asking for (some of) the bounty.

I think something like this would be possible to build within JoinMarket, such that "takers" are given an option to delay and group their transaction with other takers (and makers, maybe), but again, I'm sure the coding would be substantial. A better solution for JoinMarket will likely be simple growth. The GUI is probably helping to bring in more users. An Electrum plugin could also be potentially huge for JoinMarket, bringing fungibility (is that a word?) to many more users. I think some privacy conscious websites may also benefit from implementing JoinMarket transactions into their wallet structure (online casinos, darknet markets, etc.) which will also help the current limitations.

This could be done with a script called patientsendpayment.py, https://github.com/JoinMarket-Org/joinmarket/wiki/Sending-payments-with-CoinJoin#patient-send-paymentAlthough because the current protocol is flawed and needs updating, you can only send to addresses for which you know the private key.

Using JoinMarket for bitcoin websites could be done today, I've written a brief explanation on how here https://github.com/JoinMarket-Org/joinmarket/issues/293

People appear to have been sending very large numbers of addresses dust as a way to break anonymity. Granted, they also may have been doing it as a way to get signatures from scriptPubKeys due to the 'R' re-use issue, but the script would use bitcoind to spend the dust which is known to not be vulnerable.

Also there's lots of pretty much unspendable dust out there from Satoshidice and others, and again such a script can help.

People appear to have been sending very large numbers of addresses dust as a way to break anonymity. Granted, they also may have been doing it as a way to get signatures from scriptPubKeys due to the 'R' re-use issue, but the script would use bitcoind to spend the dust which is known to not be vulnerable.

Also there's lots of pretty much unspendable dust out there from Satoshidice and others, and again such a script can help.

Check with Peter Todd before using (not sure if up to date exactly because was last updated November 2015) but, this could be useful if you are trying to deal with some dust issue (Core)

https://github.com/petertodd/dust-b-gone

I also happen to think that dust isn't as big a deal as people think it is. It is a gift, not a curse, and it should be treated as such, people just haven't been innovative enough yet to address it well or meaningfully. See project referred to in my signature.

Bitcoin gambling sites are entirely functional as (probabilistic) mixers, if you trust the gambling sites.

Wanna mix 10BTC? Just make a hundred 0.1BTC bets at even odds. 50 of them pay out double (minus the house cut) and 50 disappear. So you get your 10BTC back, minus the house cut, and the house cut in that case is just a mixing fee.

Are there any easy, straightforward instructions to use joinmarket? Blockchain's shared coin was easy.

Actually, yes, there are -

Joinmarket has a reddit: https://www.reddit.com/r/joinmarket May not be a bad place to have questions answered, but you may want to do tor and create a disposable account for it. I won't use reddit anymore because of this - they are getting NSLs all the time, read in depth into comments... https://www.reddit.com/r/announcements/comments/4cqyia/for_your_reading_pleasure_our_2015_transparency/

However, if you don't want to deal with that, you could just view / lurk in the reddit discussions without having to log in and find out some of what you need, or just check out the right-hand side of the screen (under 'How do I get Started') which has the links you need.

There's also a very handy set of instructions right on github, for the GUI version of it, here:

Bitcoin gambling sites are entirely functional as (probabilistic) mixers, if you trust the gambling sites.

Wanna mix 10BTC? Just make a hundred 0.1BTC bets at even odds. 50 of them pay out double (minus the house cut) and 50 disappear. So you get your 10BTC back, minus the house cut, and the house cut in that case is just a mixing fee.

But that's not really what coinjoin is supposed to accomplish.

Most gambling sites do off-chain transactions. If you want to mix 10 BTC, you simply deposit. Wait a few days. And then Withdraw. No need to actually gamble or play.

The problem is if you need to exchange the mixed coins, they are tagged as "gambling" coins by such exchanges as coinbase. So you need to bounce them around a few times among your own wallets.

Bitcoin gambling sites are entirely functional as (probabilistic) mixers, if you trust the gambling sites.

Wanna mix 10BTC? Just make a hundred 0.1BTC bets at even odds. 50 of them pay out double (minus the house cut) and 50 disappear. So you get your 10BTC back, minus the house cut, and the house cut in that case is just a mixing fee.

But that's not really what coinjoin is supposed to accomplish.

In this case I would be just too scared to loose 75 or more of my bets.That would be a relatively high mixing fee. Personally I would not take that risk.

Basically, you join payments together to 'anonymize' coins, while trading coins for other coins to make proving someones ownership of a specific coin harder.

Using Joinmarket as an example;There are makers and takers in the Joinmarket network. Makers run a script that offers their coin for coinjoin transactions in exchange for a small fee. They sit around on the network, looking for a taker who needs coins mixed.

Takers, on the other hand, pay the makers to trade coins with them. Takers will come into Joinmarket announcing that they want to mix a certain amount of coins. Eventually a maker will accept his offer, and the maker and taker (and possibly more parties) all make one big Bitcoin transaction with lots of outputs to different addresses.

Joinmarket is just one of many ways a coinjoin can happen, but this should give you the general idea.

The whole taker-maker process aims to mix the coins for the takers and the makers, making it harder to tell who owns which coins after the coinjoin-transaction. It will be hard to tell who now owns each output, if someone owns several outputs etc., which is the end goal of the transaction.

Users can run this process as many times as they like, the assumption being that more coinjoin transactions = better privacy.

Basically, you join payments together to 'anonymize' coins, while trading coins for other coins to make proving someones ownership of a specific coin harder.

Using Joinmarket as an example;There are makers and takers in the Joinmarket network. Makers run a script that offers their coin for coinjoin transactions in exchange for a small fee. They sit around on the network, looking for a taker who needs coins mixed.

Takers, on the other hand, pay the makers to trade coins with them. Takers will come into Joinmarket announcing that they want to mix a certain amount of coins. Eventually a maker will accept his offer, and the maker and taker (and possibly more parties) all make one big Bitcoin transaction with lots of outputs to different addresses.

Joinmarket is just one of many ways a coinjoin can happen, but this should give you the general idea.

The whole taker-maker process aims to mix the coins for the takers and the makers, making it harder to tell who owns which coins after the coinjoin-transaction. It will be hard to tell who now owns each output, if someone owns several outputs etc., which is the end goal of the transaction.

Users can run this process as many times as they like, the assumption being that more coinjoin transactions = better privacy.

Great post man, thanks! Makes me appreciate more what a cool idea this is.

Couldn't you just use poloniex to get monero bought with BTC, then send it to yourself with a mixin of 5 or 100 or whatever you choose, then convert it with XMR.to back to BTC?

That's centralized and you lose control of your coins even if temporarily. Coin Join allows for mixing without ever giving out your coins or control of them.

Any exchange or gambling site or online wallet will do what you suggest. You just have to trust them to be online long enough for you to withdraw, and/or not get hacked, shutdown, or whatever.

I've actually seen a few people deposit to my site, wait a few days (when I "join" all deposits to the cold wallet), then withdraw, without ever playing. Works the same way. But now their coins are "tainted", so don't go try going to coinbase directly from any gambling site. Our wallets are all tagged.

Great post man, thanks! Makes me appreciate more what a cool idea this is.

If you like the idea and concept, I encourage you to download the blockchain and get your own Joinmarket-maker script running. Estimates are that the avg. maker gets about a 1% annual increase in their coin. All you need is a computer that can run the script and bitcoind.

You can get the private keys for your addresses, so you are actually in control of your coins the entire time, unlike all other similar services I've seen.

In addition, you'll get that good feeling of supporting both the bitcoin network and Joinmarket!

There were 3 people involved in the transaction. There are 6 outputs, 2 per person. 3 of the outputs (coloured yellow) are for the exact same amount. It's impossible to know which of these three yellow outputs belongs to which of the 3 people just from looking at this transaction. The other 3 outputs are change amounts. We can easily tie the change outputs to the inputs, which I did by using the coloured arrows.

The guy who spent 82 BTC got back a yellow 70 BTC and 12 BTC of change - indicated by the blue arrow.The guy who spent 171 BTC got back a yellow 70 BTC and 101 BTC of change - indicated by the orange arrow.All the other inputs came from the 3rd guy, and he got back a yellow 70 BTC and 41 BTC of change - indicated by all the red lines.

Hopefully that makes it clearer. It's the yellow outputs that have been anonymised by this transaction, not the inputs or the change outputs.

Hopefully that makes it clearer. It's the yellow outputs that have been anonymised by this transaction, not the inputs or the change outputs.

In that particular example, wouldn't it be more anonymous to just have 6 outputs of 61.04976087 BTC? (That's the total amount less tx fees divided by 6, or 3 yellows and 3 change outputs of all exactly the same amount).

That way, even the "change" outputs can no longer be tied to the three people.

Hopefully that makes it clearer. It's the yellow outputs that have been anonymised by this transaction, not the inputs or the change outputs.

In that particular example, wouldn't it be more anonymous to just have 6 outputs of 61.04976087 BTC? (That's the total amount less tx fees divided by 6, or 3 yellows and 3 change outputs of all exactly the same amount).

That way, even the "change" outputs can no longer be tied to the three people.

Sure, it's possible. With a lot of coinjoin services, you can split the amount over several addresses. This is encouraged by some of them, and it should theoretically be better for privacy.

In that particular example, wouldn't it be more anonymous to just have 6 outputs of 61.04976087 BTC? (That's the total amount less tx fees divided by 6, or 3 yellows and 3 change outputs of all exactly the same amount).

That way, even the "change" outputs can no longer be tied to the three people.

The three people contributed different amounts to the transaction, so they get different amounts of change.

The person paying for the transaction (the 'taker' in JoinMarket terminology) decides the amount of the yellow outputs, and the other two people (the 'makers') go along with that. It's only the yellow amount which is to be considered 'joined'.

Note that we could figure out which of the three people was the taker by summing the inputs and outputs of each colour. We'll find that two of the thee made a small profit on this transaction (the makers) and one took a loss (the taker).

If the maker had wanted to mix his whole wallet in this transaction he could done so. He must have only needed 70 BTC mixed at this time, for whatever reason.

Also, try following the yellow outputs - you'll see that all three of them went on to further coinjoin transactions for different amounts.

Are there any easy, straightforward instructions to use joinmarket? Blockchain's shared coin was easy.

Check their thread (https://bitcointalk.org/index.php?topic=919116.msg15148759#msg15148759). There's an electrum plugin under development that, although needs a bit of care at install time, it seems to work (read "worked for me") with a couple of mouse clicks.

Getting different amounts of change though doesn't have to mean that one is traceable.

Picture the same set of inputs, but a set of outputs all denominated in 30BTC, 10BTC, 3BTC, 0.1BTC, O.03BTC, etc. Up to whatever set of denominations you can make at least ten each of and down to whatever denomination people are willing to give up as a mixer fee to enhance their anonymity.

Now some participants get more of one denomination, some participants get more of a different denomination, but with ten of each denomination there will always be a way to split up whatever amounts among three participants, and there's no way for an eavesdropper or block chain snoop to know which is whose. They can't even use the number of each denomination issued as a guide to what particular amounts were paid out.

Change can be linked if later on the blockchain, change outputs are re-combined with inputs even if they use standard output sizes. That's why JoinMarket has so-called mixing depths which help stop that happening.

The downside of standard output sizes is that it may damage the divisibility of the currency, and also its bad for scalability because it greatly increases the number of outputs. I decided not to implement it in JoinMarket, but it's a tradeoff question so there's no obvious answer really.

A somewhat related idea is this one: https://github.com/JoinMarket-Org/joinmarket/issues/229

Couldn't you just use poloniex to get monero bought with BTC, then send it to yourself with a mixin of 5 or 100 or whatever you choose, then convert it with XMR.to back to BTC?

That's centralized and you lose control of your coins even if temporarily. Coin Join allows for mixing without ever giving out your coins or control of them.

Any exchange or gambling site or online wallet will do what you suggest. You just have to trust them to be online long enough for you to withdraw, and/or not get hacked, shutdown, or whatever.

I've actually seen a few people deposit to my site, wait a few days (when I "join" all deposits to the cold wallet), then withdraw, without ever playing. Works the same way. But now their coins are "tainted", so don't go try going to coinbase directly from any gambling site. Our wallets are all tagged.

I'm speaking in terms of privacy. What's to stop someone from being all the "other people" in coin join transaction?

Essentially being Sybil attacked in terms of traceability.

The topic was privacy Not security.

The issue you bring up comes back to, how did you acquire the bitcoins you want to "wash" in the first place if you didn't mine them?

Pretty sure there was a "not being in control" aspect to the acquisition of the Bitcoin you are trying to use in a coin join Transaction. Kind of goes against what you just said in terms of centralization and security of your coins.

Concerning your comment about your bitcoins being tagged.That cannot easily be done in monero due to its protocol based fungibility via ring signatures.

Why was Sharedcoin (I'm assuming it utilized CoinJoin?) removed from blockchain.info? Does CoinJoin exist anymore? (Not JoinMarket) It was super easy to use as it was built into the send of the online wallet on blockchain.info.

Uh, ShareCoin was a service or feature of blockchain. It wasn't exactly a CoinJoin implementation. JoinMarket does CoinJoin, but I understand why you'd want an easier method.

Which leads me to ask: What qualifies for the bounty? There's 42 BTC up for grabs on the bounty multi-sig address, but JoinMarket doesn't seem to qualify, or maybe it's not considered "practical" enough.

If I make a website that looks like, for example, shapeshift, and you see that you can send coins there, and every hour there is a CoinJoin transaction (even if internal to the site), does that count? Or any form of centralization doesn't count?

See, for CoinJoin to really work the way it was intended, everyone that participates in a CoinJoin transaction needs to be all online and they all need to sign. Perhaps what they're looking for is some Windows Bitcoin Core Qt wallet type that includes a tick box for [X] CoinJoin, then it would automatically look for others.

Uh, ShareCoin was a service or feature of blockchain. It wasn't exactly a CoinJoin implementation. JoinMarket does CoinJoin, but I understand why you'd want an easier method.

Which leads me to ask: What qualifies for the bounty? There's 42 BTC up for grabs on the bounty multi-sig address, but JoinMarket doesn't seem to qualify, or maybe it's not considered "practical" enough.

If I make a website that looks like, for example, shapeshift, and you see that you can send coins there, and every hour there is a CoinJoin transaction (even if internal to the site), does that count? Or any form of centralization doesn't count?

See, for CoinJoin to really work the way it was intended, everyone that participates in a CoinJoin transaction needs to be all online and they all need to sign. Perhaps what they're looking for is some Windows Bitcoin Core Qt wallet type that includes a tick box for [X] CoinJoin, then it would automatically look for others.

I'm curious as to WHY it was a service that is no longer? Who shut it down? Is the code still out there?

There were 3 people involved in the transaction. There are 6 outputs, 2 per person. 3 of the outputs (coloured yellow) are for the exact same amount. It's impossible to know which of these three yellow outputs belongs to which of the 3 people just from looking at this transaction. The other 3 outputs are change amounts. We can easily tie the change outputs to the inputs, which I did by using the coloured arrows.

The guy who spent 82 BTC got back a yellow 70 BTC and 12 BTC of change - indicated by the blue arrow.The guy who spent 171 BTC got back a yellow 70 BTC and 101 BTC of change - indicated by the orange arrow.All the other inputs came from the 3rd guy, and he got back a yellow 70 BTC and 41 BTC of change - indicated by all the red lines.

Hopefully that makes it clearer. It's the yellow outputs that have been anonymised by this transaction, not the inputs or the change outputs.

Cool, I first thought that inputs are sent to another bitcoin address and from there to the outputs. But, this seems not to be the case. Is CoinJoin a smart contract or a dAPP as with Ethereum?