Hiding Money: CoinJoins

Fri, Jul 8, 2016

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]

Bitcoin and Anonymity: Not So Much

Wed, Jun 29, 2016

CoinLab’s Patent for methods for deanonymizing Bitcoin wallets and transactions was released March 28. We have held off on describing methodologies and impacts until the patent was published, but it seems past time to talk about what we can see using this technology, and possible impacts on Bitcoin businesses.

As always, CoinLab’s technology is available for license, and our analysts are available on contract basis to help with concerns related to Bitcoin transactions: contact us via e-mail.

The Motivation

It’s pretty simple – we sued Mt. Gox in 2013, claiming they breached contract – most particularly, that they failed to put all US and Canada Mt. Gox customer funds into safe hands (ours). This was not a popular decision, to put it lightly. We felt we had no alternative at the time, knew we were betting the business, and went ahead. We made some coded public comments that we were worried about the auditability and amount of funds Mt. Gox actually had, but left it at that.

Since then, Mark Karpeles has gone to jail, Mt. Gox has announced it ‘misplaced’ 500,000 Bitcoins, and we’ve all moved on while our funds are locked into a Japanese bankruptcy proceeding. I’ve learned there’s no karma benefit for being the first to sue a popular figure, even if he later turns out to be a complete asshat.

We were convinced Mark had hidden some coins for himself, and sat down to look for how and where he’d hid them. This (admittedly venal), but intense focus on digging through the Bitcoin blockchain for ‘bad’ money movements ended up yielding a large amount of know-how, much of which is encoded into our patent, and all of which is coded into our tool, Oden.

Oden has taught us a number of surprising things about Bitcoin: in particular, gambling and the Darknet have been the major drivers of transaction volume since 2011.

Tepid Industry Response

For whatever reason, demonstrations of CoinLab’s technology have received tepid response from the industry players who probably stand the most to lose from bad transactions – BSA compliant exchanges.

We assumed, naively, that exchanges would demand information of the quality Oden can provide about undesirable customers. In fact, it seems so far that industry participants prefer just barely enough information to fulfill their compliance checkboxes.

I believe this is because, at different times in the exchange lifecycle, the vast majority of trading funds come from Darknet markets. Over the next few blog posts, we’ll demonstrate this, and also look at what happens economically to exchanges that start closing off avenues for darknet participants to engage.

The Basic Method

Bitcoin wallets leak information through their unspent outputs (UTXOs). Over time, wallets combine these UTXOs up and respend them, providing a view into the likely owner of a set of addresses. In the default Bitcoin core client usage, addresses are used twice, once to receive and once to spend on, creating what was intended to be a vast directed graph of plausible deniability in terms of ownership.

Satoshi’s Plan For Payment Graphs

This plan failed. Human behavior is at fault – people tend to like to keep addresses published for more than one use. For example, in the early days of Bitcointalk.org, it became a common pattern for users to put a ‘tip’ address in their signature. This remains a common thing to do around the internet – for instance, this screenshot of The Pirate Bay’s homepage shows a “tip” address at the bottom.

As a teaser, here are the primary sources of funds for The Pirate Bay since 2015. You can see that they are not getting rich off their tips, and also that someone called “u:coinbase.com” is a top donor. More about this in another post.

Other reasons for repeated use addresses

Additionally, early and popular wallets like blockchain.info used a single address for simplicity sake. These wallets do not succesfully create this broadly distributed graph. So, product and technology dynamics pushed people away from single-use addresses to reusable addresses. They became so common that Bitcoin users often created ‘vanity’ addresses for dissemination. Arguably the most famous is Satoshidice; it used addresses starting with ‘1dice’, and for years was by far the most high volume transaction consumer on the Bitcoin blockchain.

Satoshi Dice Address 1dice6D.. Balance over the course of 352,000 Transactions

Addresses and Hot Wallets

Exchanges typically offer a single address to each user, the idea being that a user can ‘bookmark’ the deposit address and reuse it. For early exchanges, the number of users stressed existing bitcoin implementations as well; the Mt. Gox hot wallet had hundreds of thousands of addresses to track. The early Bitcoin Core client was not equal to the different tasks needed for management.

A payment flow for most exchanges works like the following graph: deposits go in to the hot wallet, some are recirculated out as withdrawals, and some are sent to cold storage.

What Can We Learn?

Crucially, in that payment graph, we learned that the same company or person controls Deposit 0, 1 and 2 addresses. We call this technique grouping; the industry also terms it clustering. An interesting question is “which payment patterns group up well?” It varies, but in general exchanges group very tightly; because of this, they are at the core of any grouping based analysis.

Next Up

We’ll look at some typical exchange patterns, and talk about Gregory Maxwell and CoinJoining.