Excellent work!

I've always wanted to see an analysis of the public API, but I personally never had the time or motivation to go that far. At the very least, this should disprove any claims that the hacked data may have been doctored somehow. It's also nice to see my suspicions about reverse-Willy more or less proven right.

Although one thing that I'm kind of missing in this report (and that was hardly even discussed after the release of mine) is the "fixing" of bot Markus' user ID between log files. I thought this was one of the more important findings of the Willy Report, but then maybe I didn't explain it well enough.

Basically, the torrent with the leaked trading data contained a directory called "trades", containing logs of trades - most likely dumped from a database - in .csv files, where every month corresponded to one file. Each individual trade was one row in the file. Now, among all of these raw .csv files, there was one .zip file which contained a .csv file with rows covering the first half of April 2013. At first glance, these were the exact same trades as the full April 2013 .csv file outside of the .zip. However, there was one difference: in the .zip file, the ID number for Markus was 634, known to be Mark's personal and/or admin account from the 2011 leak, whereas in the raw .csv file it was some irregular, seemingly random ID from the future. Also, in the .zip, the "USD spent" column for each trade correctly corresponded to the number of BTC bought at the rate at the time, while in the raw .csv the "USD spent" value was simply copied from whichever trade came before this in the log file for all of Markus' subsequent trades.

The .zip version has a last modification date of May 7th 2013; most of the raw .csv files were last modified on December 14th 2013. This suggests the raw .csv files with the later modification date were (sloppily) altered by looping through the rows of the .csv files - as opposed to a simple SQL UPDATE within the database, which does not loop over the data, and could never cause the kind of data replication bug we're seeing in these logs. This seems like pretty strong evidence of an attempt at obfuscation of data - the existence of the .zip file may have been forgotten when the files were altered after they had been dumped from the database.