C'est le problème avec bitcoin. Ca devient vite addictif. 

Je suis assez impressionné par le boulot que tu as abattu en si peu de temps en partant de zéro.
Bonne continuation !

Peter Todd has made an interesting statement in the comments of this coindesk's article.


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.

A mon sens, les aspects "positifs" de bitcoin pour cette activité sont:
  - la possibilité d'insérer dans le circuit des services localisés dans des pays coopérant peu avec le pays du fraudeur.
    L'investigation est toujours plus simple lorsque tous les acteurs (le fraudeur, le kebab, ...) sont dans une même juridiction.
  - la possibilité de transférer des fonds à l'international de manière très simple (ce n'est pas du blanchiment mais c'est un sacré ajout dans la boite à outils)
  - le fait de pouvoir se passer de certains intermédiaires financiers (banques, chambres de compensation, ...) qui font aujourd'hui partie de l'arsenal utilisé pour le blanchiment d'argent, les rétro-commissions, ...

A part ça je suis 100% d'accord.
Faire du blanchiment avec bitcoin aujourd'hui c'est vraiment vouloir s'em... pour pas grand chose (faible volume de tx, volatilité, traçabilité, ...) et parler de blanchiment à chaque article sur bitcoin c'est un peu comme si on parlait de blanchiment dans chaque article faisant référence à un commerce ou une banque. Mais ça n'empêche pas d'imaginer que bitcoin pourrait être utilisé pour ce type d'activité dans le futur.

Ce qui me plait dans l'idée du pool de minage associé à un "faux" commerce en bout de chaîne, c'est que ça s'inscrit de manière "naturelle" dans l'éco-système bitcoin. Il n'y a pas besoin d'utiliser des transactions "louches" (mixers, coinjoin) entre les coinbases et le bout de la chaîne. Pour rendre l'ensemble plus crédible on peut ajouter quelques transactions intermédiaires qui splittent/ recomposent les sommes afin de simuler un semblant d'activité par des utilisateurs normaux et ne pas donner l'impression que les coins vont directement du minage au faux commerce.

Si en tant qu'investigateur, je commence mon enquête par le bout de chaine (là ou l'argent est aggrégé) je vais effectivement pouvoir remonter aux coinbases mais sans jamais détecter quelque chose de vraiment louche en cours de route. D'autre part, avant de pouvoir contrôler le mineur il va me falloir accéder à son identité. Que se passe t'il si le pool est situé dans un pays comme la Russie ou la Chine ?

Bonne remarque. En l'état ce schéma ne m'aide pas à justifier de la source des revenus mais on peut le compléter facilement avec une version digitale du kebab décrit par glub0x. Ce serait par exemple un clone de satoshi dice ou un site e-commerce proposant l'achat d'oeuvres digitales toutes plus nulles les unes que les autres mais qui connaissent un incroyable succès. L'utilisation de mules n'est même pas forcément requise si j'automatise un maximum du processus avec des bots.

L'intérêt du passage par la case pools de minage est de remplacer l'argent "sale" initial par de l'argent "propre" (les bitcoins minés et les fees). Pour des trafiquants, l'intérêt est de disperser la trace de l'argent initial. Ca correspond plus ou moins aux phases de placement et d'empilement (voir ici)

Essayons ce scénario:
- J'ai 1M€ en liquide à blanchir
- Je découpe la somme en N parts que je confie à N "mules"
- Chaque mule est chargée d'investir sa part dans des parts de pools de minage (la mule paie directement en € ou transforme auparavant les € en bitcoins sur localbitcoin puis paie en bitcoins)
- Chaque mule récupère au bout d'un temps donné l'équivalent en bitcoins de sa part (bitcoins issus des coinbases ou de fees provenant de tx cleans)
- Chaque mule revend les bitcoins à des tiers contre des € (exchanges "exotiques", localbitcoin)
- Les mules me reversent les €. La valeur du bitcoin ayant augmenté depuis le début de l'opération, la plus value sert à payer les mules.

Pros:
- La somme a été blanchie
- Si la valeur du bitcoin a augmentée entre l'achat et la revente, les bénéfices servent à payer les mules et je peux espérer que le rendement de ma blanchisseuse se rapproche des 100%.
Cons:
- rendement dépendant de la volatilité du bitcoin
- faisabilité dépendante de la liquidité sur localbitcoin ou les exchanges un peu exotiques (pas trop regardant en matière de KYC)
- la liquidité de bitcoin est encore trop faible pour supporter de gros volumes à blanchir.

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.

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.

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

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

Moi je dirais que:
- Il faut être con pour faire du blanchiment d'argent avec Bitcoin quand il existe des outils bien plus efficaces pour ce genre d'activité.
- Bitcoin dans son état actuel est une bénédiction pour les organismes de surveillance
- Un con ça ose tout donc il y a surement eu (et il y aura encore) des tentatives de blanchiment d'argent avec bitcoin qui échoueront lamentablement, quelque soit le temps que ça prenne avant qu'ils se fassent prendre.

En conclusion: l'association du blanchiment d'argent avec Bitcoin par les médias (alors que des techniques bien plus efficaces existent depuis longtemps et à une toute autre échelle) est une escroquerie intellectuelle. 
 

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). 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 F
Hyp2) 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. agencies
They 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 corporations
They 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 world
We 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)

Disclosure : english is not my mother tongue

De mon côté je suis à la recherche de devs (mais cela dit tout le monde est le bienvenu !).

L'idée est d'implémenter BIP 70 (payment protocol) dans sa version orientalisée aka "The Bazaar Protocol" (je sais, je ne me suis pas cassé pour le nom...).

L'objectif est de permettre une négociation de prix en 1to1:
- sécurisée
- prouvable (ex: l'acheteur peut prouver que le vendeur lui a certifié/promis quelque chose durant la négociation)
- qui minimise la confiance requise entre les 2 acteurs (ex: assurer au vendeur que l'acheteur dispose bien de la somme qu'il propose et qu'il n'est pas en train de négocier dans le vide)

L'idée pour le hackathon est d'arriver à implémenter une version basique du protocole et une application qui permettre de montrer son utilisation. Les principes du protocole sont assez clairs dans ma tête. Pour l'application de démo, c'est totalement ouvert et ça dépendra principalement du nombre de devs mais j'ai déjà une idée d'appli a minima au cas ou.

A priori, je pars plutôt sur un dev en python avec la librairie pybitcointools mais s'il y a des devs intéressés sur d'autres langages, je m'adapterai (je ferai le café et découperai les pizzas).

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.

Sorry for this "philosophical" off-topic (barely checked with google translate - a "free" product provided by Google Inc. -)

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. 

@gmaxwell : Thanks !

Follow-up of discussion from this 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.

Thanks ! I get it. BTW, I've posted a comment in coinjoin thread (to avoid pollution of this thread).

Sorry for the dumb question but what do you call "careless joins" ?

Et encore ce n'est rien. On peut imaginer un futur rempli d'objets connectés capables de se payer entre eux automatiquement (pour l'obtention d'un service, de données, ...). Auquel cas, la consommation d'adresse se ferait à une toute autre échelle. Mais en soit ce n'est pas très grave. Si un jour cela devait arriver, on appliquera une solution très simple identique à ce qui se produit avec les adresses IP : on étendra la plage des valeurs possibles.

C'est exactement là que ce site permet de se faire des noeuds au cerveau. Comme tu le dis, la probabilité de collision n'est pas nulle. Cependant, elle est tellement faible que si les clés privées sont tirées au hasard "convenablement" le système en devient très sur.

Mais ça permet aussi de comprendre 2 ou 3 trucs utiles comme :
- pourquoi les brainwallets (adresse générée à partir d'une passphrase) ne sont pas vraiment une bonne idée (cf cet excellent post en français)
- le fait que les ordinateurs ne sont pas très doués à la base pour générer du hasard. Du coup, ça explique pourquoi à l'initialisation de certains wallets il est demandé à l'utilisateur de bouger sa souris ou secouer son smartphone pendant quelques secondes.
- le fait qu'une source d'entropie défaillante peut s'avérer catastrophique pour la sécurité d'un système.
  Exemples:
    - Bug dans les wallets android en 2013 (pb de clé privée retrouvable à partir des transactions signées avec un générateur de nombres aléatoires pas si aléatoires que ça)
    - Hack de la PS3 en 2011 (pb similaire au précédent sauf que là Sony avait carrément remplacé ce qui était censé être un nombre aléatoire par une constante...  )

De mémoire jamais.
Bon sinon, pour ceux que ça intéresse, il y a aussi la liste de tous les codes PIN des cartes de crédits qui a été hackée il y a quelques années    http://pastebin.com/2qbRKh3R

En fait je crois que ce site est une espèce de bizutage qui a généralement pour effet de faire des noeuds au cerveau et/ou de mettre en mode panique la personne qui le consulte  

Le bon côté:
- tu n'es pas le seul a en avoir fait l'expérience  
- si tu est tombé dessus, c'est que tu est curieux de comprendre comment ça fonctionne et ça c'est plutôt bon signe
- c'est le meilleur moyen de vraiment toucher du doigt sur quoi repose la sécurité de bitcoin

Chaque adresse bitcoin (et la clé publiqué associée) est calculée à partir d'une clé privée (les formules de calcul sont consultables sur le wiki).
Une clé privée n'est rien d'autre qu'un nombre tiré au hasard parmi une grande quantité de nombres possibles (voir post de Gobitcoin).
La sécurité de Bitcoin repose donc en partie sur le fait que tirer au hasard un nombre (clé privée) correspondant à une adresse déjà utilisée et contenant des coins est très très grandement improbable. Toucher la super cagnotte du loto plusieurs fois d'affilée serait à côté une méthode plus sure de devenir riche. Ca peut sembler très étonnant au premier abord mais c'est un des principes qui assure la sécurité de bitcoin et en fait un système très sur.

Pour se rassurer définitivement la consultation de ce thread est recommandée (même si ça n'envisage que le cas d'une attaque par la force brute).

@gmaxwell
Thanks for the details ! Very informative.

What was the rationale for disabling ddos protections against Tor hidden services ? I was specifically designed as a solution to attacks like the one described in this paper or is there another reason ?

WRT topology, it seems you've made a wise decision. You can't prevent people to try an attack, but this kind of topology significantly raises the cost of an effective attack.
I guess the main "threat" would be an alternative client with different networking rules (non random selection of peers) combined with an incentive to connect to specific nodes (higher bandwith, ...) which would lead to a more "centralized" topology. But that seems very hypothetical for now and I'm sure that network resilience is a very good incentive to prevent this kind of evolution.