This is the second post in a series introducing CoinLab’s Oden Technology and Patent. You should probably read Part 1 first.
Since publishing our first article, the largest number of questions we’ve gotten have revolved around CoinJoins – are they effective? How do they react to the kind of analysis Oden can do?
As always, CoinLab is available for consultation, analysis and licensing conversations: contact our CEO Peter Vessenes.
Some History About CoinJoins
Gregory Maxwell became worried about grouping-based attacks in late 2012, and proposed that grouping techniques could be defeated by combining up transactions in a custom send. You can read his bitcointalk post here and the original idea in a post called I taint rich!. The posts are from a time when the bitcointalk community was still largely functional; even so, the first link is a long read; 34 pages of forum posts as of Mid 2016. Since then, there have been multiple academic papers fixing up some privacy concerns, especially around the questions of how one finds participants to CoinJoin with safely. No literature we are aware of has dealt with the flow of coins in and out of these CoinJoins, so we’ll talk mostly about that.
Plus we want to see who CoinJoined with Mr. Maxwell! Who could turn down such a possibility?
This protocol, as imagined by Maxwell, works, but not very well. The fundamental idea is that users should share a transaction which spends coins from addresses, one owned by each party. Naive grouping techniques will ‘group’ 1Greg and 1A into a single wallet, and this will increase privacy on the Blockchain. Thus Mr. Maxwell’s pitch that he be “incorrectly assessed as impossibly rich by brain-dead automated analysis” in his introduction.
Later enhancements used some nice cryptographic techniques to make sure participants couldn’t steal money from each-other while they co-authored the transaction.
He found a taker for his transaction, and it looks like this:
You can see in the transaction that he kept his 1BTC, per the plan, and the other party paid the miner fee.
Mr. Maxwell struck it really virtually rich a few hours later, when someone with 40,000 or 50,000 coins CoinJoined with him:
Until then, these transactions had been quite small, and Mr. Maxwell’s implied wealth was not large.
Some Snooping, And Associated Risks Thereof
40,000 Bitcoins were worth about $500,000 January of 2013 – a lot of money, but not an eye watering amount. One year later, those 50,000 coins would be worth $50mm, and today about $35mm. That’s enough value to hold our attention! Where did those coins come from? Oden can help with that – check out a quick transactional graph.
CoinLab analysts at some point annotated a 50,000+ coin withdrawal from the Silk Road on September 19, 2012. These coins do a bunch of interesting things, but by September 30, 2012 are transferred into the source address used for the 40k CoinJoin. They don’t move at all until Jan 2013 in this CoinJoin.
This is pretty fascinating – coins once deposited at the Silk Road are the other half of the first CoinJoin!
Of course, we need to be careful – saying the coins are from the Silk Road is different than saying the owner of the coins is anyone directly related to the Silk Road - all we have is the coin movements to go on. We don’t know how many parties had possession, or what their relationships are. In this case, we know a bit about the owner of the coins from self-disclosure.
Mr. Maxwell pointed us to this post on bitcointalk.org where user “Loaded” works out the details of the CoinJoin, and makes clear that he/she is the owner of the address, but like many things in Bitcoin, we have no way of knowing what happened between September 19 and September 30.
Not only is this bit of history interesting, it’s a good reminder that technologists, presumably solely motivated by technical interest and increasing the privacy of the Bitcoin network, can easily become unwittingly involved in money movements that may take some explaining while messing around with CoinJoins and other techniques.
Despite this, they often seem to be willfully blind to these possibilities – here’s a twitter exchange I had in the last few weeks with Kristov Atlas, about whom, more in a bit.
NOTE The original version of this section contained speculation as to the owner of the 40k coins and a relationship with the Silk Road. This had no basis in observable fact and we’ve deleted it, per Mr. Maxwell’s request, updating with more details on the bitcointalk participant who did the CoinJoin.
About those transaction sizes
One clear flaw with these early CoinJoins – it’s obvious who is who, before and after. One party sent in 1BTC, The other 40,000. Later CoinJoin proposals attempt to close this loophole with one of two strategies: Fix the amounts to be the same, in and out so that the graph looks like this: Or, randomize the amounts in and out so that they look like this:
Randomized Amount CoinJoin Flaws
A problem with randomizing the CoinJoins is that they can typically be reconstructed: figuring out which inputs and outputs match up turns out to be relatively computationally easy (In fact, see if you can tell if our graph could be a CoinJoin or not, using that reasoning). Kristov Atlas originally published CoinJoin Sudoku, a paper and proof of concept that shows most CoinJoins that use the random input and output strategy can be pulled back together and associated up. This is obviously not ideal for users who desire privacy. Mr. Atlas has gone on to publish guides to using Bitcoin privately, and has appeared on the Glenn Beck show discussing his techniques.
From Oden’s point of view, this sort of analysis is useful when looking at a specific suspected CoinJoin. But in practice it is rarely necessary.
Fixed Amount CoinJoin Flaws
A further solution to the CoinJoin Sudoku approach is to use fixed Bitcoin sizes – if every party only adds 1 Bitcoin to the CoinJoin transaction, then Sudoku can’t be accomplished.
This has two specific flaws. First, users who wish to be joining more than the standard size will be splitting out their wallets into these sizes, and so they will be identifiable across transactions.
Second, finding the appropriate sizes and users who wish to participate can leak privacy – that is, the blockchain may not know who’s who, but there may be records online – in chat channels or forum posts. Various academic papers have tried to attack this problem from a cryptography perspective – blinding and revealing transaction sources and destinations – but there is no known secure and private way to initiate a transaction among mutually untrusted parties right now.
General CoinJoin Flaws
From Oden’s perspective, these two systems and their flaws don’t matter much – there is a fundamental flaw with CoinJoins: coins have history. Wallets have different characteristic patterns. Before the CoinJoin, two parties will have different trading partners, movement mechanics and volumes of transaction. After their coins go into a black box, and come out the other side, even if it is a perfect mixing black box, the parties do not typically change behaviors. If they were trading, they will go on trading. If they were dealing drugs on darknet markets, they will go on doing so.
This loophole is hard to close, long term. It means that a CoinJoin would be best utilized at the very end of a transactional pattern, or perhaps just before coins go into storage.
Even so, it’s not enough to change your own behavior – the other CoinJoiners must stop what they are doing as well, or your new wallet will be identifiable because it is the only one that doesn’t yet have a match.
Centralized Money Laundering
There are other money hiding strategies. A common one is to outsource money movement to a trusted party. BitcoinFog (A Tor/Darknet service currently located at this Tor address) is a classic example. BitcoinFog takes deposits in, and randomly over a period of days sends out a random percentage of coins to a set of addresses requested by the user. They even take a randomized fee to help hide the amounts being laundered.
In our next article, we’ll talk about BitcoinFog, centralized peels and how Oden does its analysis.
Questions? Get in touch with our CEO: [email protected]