Monday, August 3, 2015

2015 Texas Bitcoin Conference Paper

In March I traveled to Austin to present a paper at the Texas Bitcoin Conference on Bitcoin Transaction Patterns that I discovered while working on my Numisight project.  It was a wonderful venue to present at standing on the stage where Austin City Limits is filmed.

TBC, however, has had some issues in getting the contents of their proceedings out.  So in the interim I am posting as a PDF the contents of my paper.  Enjoy.

Wednesday, May 13, 2015

Millions, Billions, or Trillions?

21 Inc. is the current highest raising Bitcoin startup in the market.  But they weren't always "21" because they started out as 21E6, an allusion to the theoretical maximum number of bitcoins from block rewards.  Why did they drop the geeky calculator reference to millions?  My theory is that it has to do with the fact they aren't slinging bitcoins, but instead millibits.  So 21E9 was briefly on the table.  But then the VCs caught the vision and realized that one day they would just be slinging bits. And since a bit is on thousandth of a millibit then the name would be a palandromesque 21E12, except I think that many people in bitcoin aren't that good with math and flip signs in strange places, resulting in one thousand bits being a millibit.  So I think at this point the marketing people stepped in and realized that some people interested in bitcoin like to gamble (I mean look at how many clones Satoshi Dice spawned!) so they just went with a gambling reference and went with 21.  However the motto of "Bitcoin, but with IoT and blackjack!" didn't make it past the nerd culture test because it didn't have the right hook.

CoinDesk Reveals Real Data on 21

While the previous paragraph was entirely satirical CoinDesk did get some real news on 21 via a video that was leaked to them.  I won't go over the details of that article and would reccomend you go there to read the news (if you haven't done so already).  But embedded in there was a gem:  three addresses used in demos posted by 21E6: 1M9ZeS...9x6z1hs2xK...Fryy, and 1MaQHC..sd1d.  With these three addresses we can ferret out a little bit more information from the blockchain.
Addresses from CoinDesk Article [numisgraph]
The addresses show two very important trails we can follow.  First, the privacy sin of a self-spending address is exposed from all three addresses.  Second, we see the first of several large sweeps, revealing control of other transaction chains.

Self Spending Wallet 1A8x13

Whenever I give a public talk I make it clear that re-using addresses is the first and greatest privacy sin.  If you want privacy don't reuse your addresses.  And if you send your change to the same address you are spending it from, you make analysis such as this absolute child's play.  I have no idea why they chose to us a self spending wallet, but this is a major privacy faux pas.

Peeling Chain of 18Ax13 wallet [numisgraph]
This wallet was seeded twice from CoinBase (not 21's mining pool).  Those are the orange transactions.  The peeling chain formed by the wallet feeds into one of four sweeping transactions where we can, via input clustering, presume the contents of other participant peeling chains in the demos.  Those are the purple transactions.  The yellow transactions are the peeling transactions and the one lone green transaction represents some unspent bitcoins that survived the many VC pitches.

4 large sweeps, one unswept chain

From the other related links, I have identified 5 large peeling chains that fed into this cluster of demos. You can download the fully expanded graph [png][numisgraph] or the graph with the sweeping transactions removed [png][numisgrpah].  These images are too large for me to link into this blogpost with a straight face.

From this we can see that there were about 5 wallets used to perform the various demos, as well as payments directly from CoinBase in some of the demos.  Three of the wallets were funded from CoinBase and two of the wallets were funded from two of the sweeps transactions that were previously identified.  One of the peeling chains has not been swept, so it is only presumed it was used either in a demo or as part of a QA process right before everyone took the week off for thanksgiving.

These sweep transactions do not, in my opinion, represent multiple wallets on the back end.  There are shared addresses between the first and second sweep transaction, and since some of the chains were feed off of these two sweeps it leads me to believe they were recycling bitcoins to be used for the demos, and the third and fourth wallet sweep are from the same wallet.  One of the final sweeps actually returned bitcoins to CoinBase as well.

The transactions also tended to clump together in time.  However I am hesitant to draw any conclusions about how many VC pitches they did from this demo.  Having been in that game before I know that the demo is practiced many times before the first meeting.  The video was also showing a canned demonstration of sorts, so the early October clusters were likely the result of multiple practice sessions.  And then, when you consider that live demos for pitch meetings can go way off the rails and spawn multiple due diligence meetings then this presumptive analysis without other data (like an executive's travel itinerary) quickly becomes worthless.  That being said if I had to go to two or more hands to count the number of VCs they demoed to (not total number of demos, total entities pitched to) then I would be surprised.

Good and Bad OpSec

These transactions show some good and bad OpSec practices on the part 21 Inc.  The only real groaner was the re-use of the same address on one of their peel chains.  This raised the confidence level that all those sweeps that linked in the other chains really were related to the same set of demos.  I also read in the article that each chip was going to come with a hard coded address.  I hope they reconsider that and go to an address seed or it's referring to some other internal identifier used by 21 Inc. instead of a literal bitcoin address that will show up on the blockchain.  Otherwise we will get side channel attacks opening up by looking at address usage to determine when people are on vacation or other such shenanigans.

OpSec that was neither good nor bad was the peeling chains and sweeping transactions.  At this level and with that much transaction volumes there really aren't many good options to conceal these movements.  These small TXs would still stick out in a coin tumble and allow for some (by hand) input correlation.  And by then the TX fees of a more "professional" service would wipe out the value (we are talking about less than $100 USD here), and similarly the structuring of the TXs would wipe out value in the TX fees.  But really what's going to help is more volume and diversity in the services.  You won't see that in a demo at a VC pitch, so this is truly unavoidable.  Posting the TXIDs in a video (no matter how private) is really what caused this leakage to happen.

But the best OpSec goes to the sourcing of their bitcoins for the demo.  I was hoping that they would be using bitcoins they mined themselves, and hence I could send some confirmation data to Neighborhood Pool Watch.  But instead they used a very predictable source of coins: CoinBase.  For all we know they are selling all of their mined coins through CoinBase.  If your source of funds is legal they are one of the best venues to tumble bitcoins strictly based on their volume and legal recognition.



If you have any investigations of your own on the blockchain that you would like help with on a paid confidential basis, or would like to learn more about the software I use to help generate these blog posts, or would just like to learn more about bitcoin blockchain forensics please feel free to mail me at danno@numisight.com or at sales@numisight.com

Thursday, April 23, 2015

Zombie Coin Movements - The Calbuco Cluster

Over the past two weeks the movement of some "Zombie Coins" has raised some interest in twitter.


A low rumbling source of old bitcoins is erupting causing panic in some traders minds.  Kind of like a once dormant volcano suddenly erupting.  I dub these coins the "Calbuco Cluster."

Want to play along at home?  Download the Numisight Bitcoin Explorer and load the files linked in the captions of the images of this analysis.

Movements of April 2015

Starting on April 15th over 26K BTC moved from a 16 month old address into several new addresses.  Over 15K of that value was stored in a single address 1MzG9Gx5G3ZTXtEQT4FJg23Cb3gS6UF982 while the balance was stored in multiple single addresses.  About a week later on April 21st the other addresses were moved again in a transaction resulting in one coin of 5K BTC exactly, another one of 5,373 BTC (and one hundred bits) and a leftover address holding only 443 mBTC and change.

None of the addresses used in these movements has been seen before on the blockchain, so no input clustering analysis can be performed.

April 2015 Movements of the Calbuco Cluster [numisgraph]
Mass Movements of Dec 2013

The six transactions that all of these coins originate from are part of a much larger movement of coins that occurred in December of 2013.  Spread across 25 transactions all part of the same block (#276158) a total of 103,092.998 BTC shifted from one set of unique addresses to another set of unique addresses.  For the most part these were relay transactions (single input and output).  The only exceptions were a few addresses that consolidated a little bit of dust spam of 100 bits a piece that had gathered there before the coins moved.  I'de post a graph, but that spoils the next section.

What is interesting to note, however, was the market dynamics at the time this movement occurred.  The market had just come off of it's record highs a few weeks earlier. Had these coins moved then they would have been worth in excess of USD$100MM, but at the time of the movement they were worth USD$66,615,602.50.

Based on market volume, it is unlikely that this represents a large single trade.  At best it represents a position gained over a while and then cashed out in BTC, and that is if they don't represent individual or institutional holdings.  However a couple of days before the trade (18 Dec 2013) a large drop in price occurred and there were at least two exchanges (BTC-e and BitStamp) that reported volume that could have accounted for the movements in a single day.  But I would have expected the movement to precede the volume given the downside price pressure.

Peel Chain of March 2011

All of these coins that moved in December all originate from a peel chain that occurred in March 2011.  Keep scrolling, because it's a long one.

March 2011 Calbuco Cluster Peel Chain [numisgraph]
This peel chain, mostly of 150K BTC and possibly from 400BTC, is the origin of all of the coins that moved last week.  And this gives us a clue as to how much BTC is left to ooze out.

This chain has origins to a Jan 2011 sweep transaction of 181 smaller coins (not pictured).  Values ranged from 40K BTC to 10 mBTC, with most below 1000BTC and clumping at 50BTC.  Coins were then relayed and peeled into a 150K BTC and 250K BTC coins.  The 250K BTC branch entered a more complex series of transactions and will not be considered part of the cluster.

The 150K BTC branch in early March then proceeded to form a peel chain of 33 peels.  25 of the peels survived until December of 2013 when they were all relayed to new addresses.  The other 8 peel coins were spent prior to this event and were not evaluated as part of this analysis.

What Lies Beneath

Of the 25 coin relays in December 2013 only 17 remain unspent, representing 71,714.9987 BTC in the "magma chamber."  Note that this weeks and last weeks "eruption" only consisted of 6 of the relay coins.  There were also single coin eruptions in September and October of 2014, but since they were smaller and younger coins the "coin days destroyed" graphs didn't register as dramatically.

I honestly have no idea who controls these coins, or how many times they changed hands.  The December movement could have been a shuffle to move the keys from a USB key kept underneath someones mattress to bank grade key storage, and it could have easily been someone who had to cover their sales at an exchange days after the trade.  The recent movements could have corresponded to an American behind on their taxes paying the piper so to speak, since it did occur on a major US Tax Deadline.  But the one thing I am very confident of is that these are not the Mt. Gox coins you've been looking for *Obi-Wan*Jedi*wave*.

Tuesday, March 31, 2015

Prosecution Futures - The Blockchain Evidence Against Force and Bridges

I once heard a joke calling bitcoin transactions "prosecution futures," the premise being that any illegal activity you conduct on the blockchain will be sitting there ready for prosecuting agencies to find.  The oldest reference to "prosecution futures" I could find in three pages of search results was from the naked capatalist blog.  The author imagined that the futures were for money laundering and tax evasion.  I don't think it ever crossed their mind that what would ultimately transpire was sworn federal agents violating their oath.

Enter the latest and most surreal twist in the Silk Road saga to date.  Yesterday the DOJ released a criminal complaint against former DEA agent Carl Mark Force IV and former Secret Service Agent Shaun Bridges.  The surreal part is not the core allegation, where it is alleged that Force and Bridges were skimming the profits from undercover drug sales.  But where they had managed to embed themselves so deeply they were engaging in some of the more salacious stories emerging at the trial.  The January 2013 theft?  That was the undercover agents.  One of the murder for hire allegations?  Yep, complete with faked pictures.  Causing the collapse of Mt. Gox? Well, no.  I'm not convinced about it yet but it is at least in the realm of reasonable theories. Even Hollywood couldn't make this up.  But remember, these are all allegations until proven in a court of law at trial.

I am not a Lawyer

I would like to point out that I am not a lawyer.  I did not do any correspondence courses to the University of American Samoa and it didn't take me three tries to pass the State of New Mexico Bar Exam (I've never tried).  So if you are reading this blog realize this is for entertainment purposes and is not legal advice.  I feel the need to say this since I'm going to be re-creating some of the exhibits and pointing out a few minor clerical errors.

However what I do find significant in this complaint is that three of the exhibits showed a significant amount of blockchain analysis. This is something we didn't see in the Ross Ulbricht trial, the only connections entered into evidence were direct transactions between the Iceland server and Ross's laptop.  But to be honest, that was really all they needed since the evidence was so overwhelming.  This case is significant because they are entering in as evidence bitcoin traces involving multiple transactions.  (And they even had a footnote on page 9 discussing the proper capitalization of bitcoin.)

Exhibit B

Exhibit B is the most complex graph in the complaint.  It outlines a 525 BTC payment to Force received from DPR, where Force pretending to be a corrupt government official offering his knowledge and expertise (except allegedly he wasn't pretending).  I was able to recreate this graph by entering only one of the addresses and waling up and down the transaction graph, so despite my nits the exhibit is generally correct.

Exhibit B [numisgraph]
The transactions where Force was paid by DPR begin at the top four orange transactions.  What follows is a series of relays, peels, and sweeps that wind up with one large sweep at the 02d7b4b8 transaction and then a final sweep at f7dcec4f  before a relay into CampBX.  There are two transactions in the middle of the shuffle representing nearly 34 BTC which was replaced from a transaction in the second sweep that (according to the exhibit graph) match back up to Silk Road.  This appears to be what passed for coin shuffling at Silk Road, but to be fair CoinJoin had just been announced during the events in this exhibit.  But what made this game of three card Monte pointless was when the whole value was combined in the end just before the deposit into CampBX.

Compared to the Exhibit B graph (on page 55 of the PDF) there is one major stylistic difference is that I focus the vertices of the graphs in this blog on the transactions and the edges represent the transaction outputs that are attached to particular bitcoin addresses.  The exhibit graph has the vertices as the transaction outputs.  In fact, some vertices represent multiple transactions that are self spending peeling transactions.  The flaw I see in this is that there is no room for the transaction IDs and some details about the creation and spending of transaction outputs can be lost.

There are also a few clerical errors in the exhibit in the complaint, and some elided details that exist in the transactions that are lacking in an address focused graph.  This is likely the result of copy paste errors as it appears that a tool such as PowerPoint or Analyst's Notebook was used to generate the exhibit. The left two branches from DPR have the second and third addresses swapped.  There are some coins that exit the system just to the lower right of the center of the exhibit.  Those coins do exit but there are several intervening addresses left out of the exhibit.  And the major sweep at the bottom of the graph is actually two sweeps from two different addresses, all winding up in the 136jvwh address eventually.

There are advantages of a hand made graph.  The lines and arrangement of the graph are much more aesthetically pleasing.  Right now I am using JGraph for my graphing layout but I am exploring a more expensive option, but based on my professional experience yFiles is the best library in the business for graph layouts.  You also pay for the quality of the work.

All these nits aside the core narrative of the exhibit is correct: DPR danced 525 bitcoins to Force in a complex series of transactions.  The clerical errors and stylistic nits do nothing to diminish this message.

Exhibit E

Exhibit E represents the payment of 770 BTC from DPR to Force (under the pseudonym frenchmaid) in connection with the alleged murder for hire that Force lied about carrying out.
Exhibit E [numisgraph]
This graph shows a series of five payments relayed to Force that were in the end deposited into one of several CampBX deposit addresses.  There were no clerical errors in this page (there were also less addresses).  The edge on the left also didn't show the structure of the peeling chain that was formed by breaking off the four payments.  Creating four separate amounts did nothing to hide the shared origin of the amounts.

Exhibit F

This exhibit is even less interesting than Exhibit E was compared to Exhibit B.  It represents the skimming done by Bridges into Mt. Gox, and then to his Fidelity account.
Exhibit F [numisgraph]
All of the transactions were peeing transactions, self peeling transactions at that.  The single address used at Mt. Gox then received the proceeds which he then cashed out into his Fidelity account.  Seriously, his Fidelity account, a large brokerage that was likely more than happy to hand over customer information when served with a legal and correct search warrant.

Conclusion

This will be an interesting case to watch as it winds its way to trial.  Whereas the Ross Ulbricht case relied on simple single transactions this case depends on a more complex series of blockchain transactions to prove the allegations against Carl Mark Force IV.  When it comes to entering information in as evidence this is likely a case that will be sited in much of the case law that will develop.

You also may have noticed the "numisgraph" links in the captions.  If you want to play along at home you can download the public alpha of the Numisight Bitcoin Explorer and load the attached files and explore the related transactions yourself.

Friday, March 27, 2015

Numisight Bitcoin Explorer Public Alpha Release

Today I am releasing a version of the tool I've been using to create the graphics you see on this website.  The Numisight Bitcoin Explorer can be downloaded from the Numisight website.

This version of the software provides the core visualization engine used in the full "Studio" version of the software.  The reporting and profile creation tools are not present a they are still under development.  You can save and load graphs as well as export as a PNG (with a watermark) any graphs you generate.  When loading an old graph please note that coins that were once unspent may now be included in a transaction.  The layout may also mutate from the saved graph because of this as the topology may change.

Using the search box you can copy in any address or transaction ID and the resulting transactions will be shown on the main canvas.  To expand a transaction you can double click the box, and to expand just the inputs and outputs you can use the context (right click) menu.  This menu also allows you to remove unwanted transactions.  Be careful however, currently I take no effort to restrict the amount of data that is shown on the canvas.  Pay attention to the number of inputs and outputs for each transaction to be sure the graph won't be overwhelming to look at.  There is a performance penalty for viewing large numbers of transactions, but usually you will encounter the usability issues of attempting to make sense of a thousand transactions before the performance penalty becomes troublesome.

For data I provide access to two public data sources (there were three, but one of them got out of the Bitcoin API game).  Bitpay Insight is the primary data provider, and BlockCypher is available on the configuration tab of the data screen.  If you use BlockCypher I recommend you provide your own API Key rather than sharing the bundled key.  Currently I only make use of the basic BlockCyper APIs, not any of the unique data sources like their library of double spend data.

The license for this version is of an evaluation license, and this version is licensed until block 400,000 is mined.  Currently this is not enforced in the software but that is something I am looking into.  If you want a more permissive license feel free to email us and we can work something out.

If you have any questions or problems, please email support.  Right now we have a Mac and Windows 64-bit version.  I'm working on getting a Linux (Ubuntu) version ready and that should be out within a week.  If these don't work for you email support and let us know what versions you may need.

For the next batch of blog posts I will be doing, I intend to release the .numisgraph files so that you can explore the transactions graphs yourself.  I may also be providing graph files that are not shown in the blog posts that are used to back up my analytic conclusions but don't add to the primary narrative.


Wednesday, March 11, 2015

FBI Silk Road Auction of March 2015

In March 2015 the US Marshals Service (USMS) held their third auction of bitcoins connected with the FBI case against Ross Ulbricht and the first Silk Road market.  Bids were submitted blindly on the 4th of March and the USMS moved the bitcoins on the 9th and 10th of March.

According to the auction announcement the funds were required to begin transfer by 2pm EST in Washington DC (which wound up being 1pm since daylight savings time began the day before).  Bids were to be "transferred to winning bidders in the order that each winning bid was received."  It appears that the winners had all their financial ducks in a row because the transfer of the bitcoins began promptly after the deadline passed.

Winner #1 - itBit

According to CoinDesk the winner of the first lot paid out, to the sum of 3,000BTC, was itBit.  Headquartered in New York itBit is a bitcoin exchange that also has a significant office in Singapore.
Transactions to the first winner of the auction.
Starting right after their lunch break the USMS sent a test transaction to the winning address of 50 mBTC.  This is a pattern we saw in the second auction and looks to be one they are going to be using going forward.    A half hour later the remaining bitcoins were transferred to the winning address.  No fees were paid for either of these transactions.

Based on who won these bitcoins and the immediate transactions that occurred it is my theory that the deposit went straight into the itBit operational wallet.  The two unspent transactions in this graph would represent a customer withdrawal and a "change address" ready for more use by the operational wallet.

Winner #2 - Unknown

It is currently unknown who won the 20K lot of bitcoins, which represents all of the series A blocks of bitcoin available. 
Transactions to the second winner of the auction.
The USMS initiated the second winner's transaction about a half an hour after completing the first one.  Again they began with a test transaction of 50mBTC and then two hours later completed the rest of the transaction.  It is unclear why there was more time for this transaction, representing 14 blocks between transactions rather than the single block for the first winner.  They also paid no fees to receive their bitcoin.

There is not much that can be said about this winner, other than they have exercised some excellent "privacy hygiene" when it comes to the transaction information.  The address is one that has not been seen on the blockchain prior to the auction, and the only action seen with the purchased amounts is a single sweeping transaction into a new address.  


Winner #3 - Unannounced

The third winner of the auction exhibits some connection to the Cumberland Mining & Materials LLC  of which very little is shown on their website.  They have not announced their participation but it is believed by many individuals that watch the blockchain that they were the initial recipients.

Transactions to the third winner of the auction.
The USMS initiated the transfer of the test 50 mBTC to the third winner about an hour after the last transaction, and then the USMS went home for the night.  This left the bitcoin community in suspense overnight over how much the third winner would receive and wondering if there would be a fourth winner.  But to their credit they were in the office super early the next morning to complete the transaction and sent the remaining balance to the third winner and thus wrapped up the auction before the markets opened on Tuesday.  The third winner paid a transaction fee of 100 bits for both the test transaction as well as the final transaction, the only transaction fees paid in the third auction.

The reason why any information is known about this winner is because they used an address that had been used before on the blockchain and this address was also mentioned on twitter.  Via some other internet detective work we can conclude that they have some connection to some other recognized names in the the exchange portion of the bitcoin ecosystem.  But those details are outside the scope of this blog.

However it does not appear that Cumberland kept all of the bitcoin for themselves, it appeared they were acting as a syndicate for their bid.
Detail of three transactions from the third auction winner.
Within three blocks transactions for 2K BTC, 14K BTC, and 5K BTC were peeled off of the awarded amount.  The remaining sum of nearly 6K BTC was short the test transaction amount and the fees paid to receive the initial sum.  Because of this I feel the 6K distribution remained with the administrator of the syndicate.

Nothing has been publicly stated about who the third winners were, nor who the members of the syndicate are.  There is also the possibility that these are cold storage amounts for the same entity.  However if it was cold storage I would have expected less movement of funds and more consistency in the size of the distributions.  This is why I feel four entities joined into this syndicate.

PSA - Don't Reuses Bitcoin Addresses

I'de like to finish with a public service announcement: don't reuse your wallet addresses.  Even the original paper on Bitcoin recognized the dangers of reusing addresses:
As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.  
 [Section 10: Privacy, Bitcoin: A Peer-to-Peer Electronic Cash System]
Note that for the second winner we have never seen any of their addresses before.  And the only reason we know anything about the third winner, their syndicate, and what they are doing with their transactions is because of a re-used address and a tweet associating that address to an identity.  

I cannot stress enough how keeping addresses as single use entities is the simplest and most effort effective means there is to increase your bitcoin privacy.

Friday, February 20, 2015

Following the Inside Man

Last night (19 Feb 2015) Morgan Spurlock's show "Inside Man" premiered their episode about Bitcoin on CNN.  Sure enough there were scenes of him paying for and receiving bitcoin. And since the transactions occured on the blockchain, they are available for proof.

The first bitcoins on his show is a small $0.25 gift for his brand new install of an Aegis Bitcoin Wallet he used for the whole show.
His next task was to buy a whole bitcoin at an exchange. After being inspired by Andreas Antonopoulos, he bought an entire bitcoin for $630 (this was filmed on 7 Jul 2014, so the price was good then).
Next he goes to upstate New York, but because of the magic of television editing we see him spending some of that hard bought bitcoin.  First, he buys a pizza, or two.  Thanks to the nice steady and straight on shot of the barcode we have a high level of confidence this is indeed the transaction where he bought pizza.
The blue transaction is when the pizza parlor cashes out their bitcoin (at a loss).  Next he buys some groceries.  And apparently they manage their bitcoins on the same address, because they also get cleared out in the same transaction.
Then after all that hard shopping and eating he gets a massage.  Would you believe the massage place works off of the same vendor?
Actually, I'm not terribly sure about this one.  Because in the video the transaction is stated as $20, and I cannot make out any QR codes nor is an exact BTC amount stated.  But this is the closest one I can see. (Come on CNN, what's it going to take to get Inside Man filmed in 4K?) But it makes sense if they filed on one day and had only one vendor that needed to fill out a release.  I'm sure they got a release just in case some snoopy person posts the transactions on some blog somewhere.

Next in the show we see a scene where Morgan "buys" airfare and hotel to the bitcoin mine he is about to visit.  This is a bit of editing magic to provide a nice segue to the next segment.  But the dates on the travel drop down start after the next transaction we will see.  Furthermore, the two bitcoin addresses show zero transaction (which I won't link to as I don't want to encourage dust and tags to go there).  But the point of the segment is that yes, you can book travel and hotels with bitcoin.

Now we go back in time to his visit where he worked briefly at a Bitcoin mine.  He gets paid 0.3 BTC for his labors and gets to see a snazzy animation of his transaction showing up at blockchain.info.

Next he works with the (former) FBI agent who helped bring down the original Silk Road.  Yea, we won't see him on the stand but he will do a CNN interview.  (Makes you think the prosecution had a better strategy in mind than the defense.)  Morgan then buys a "Fauxlex" from Silk Road 2.  Except I doubt he used his Aegis wallet.  You see, Morgan's wallet address seems to be 12qp1Ksm8NDxaermZpf4wbpdC2FSyupFx5, and all the outbound transactions I see coming from that address are either (a) too small or (b) go through Coinbase.  I'de like to think that the Silk Road 2.0 operators aren't so dumb as to process transactions through Coinbase, but I've been wrong before.

Now after that late night on the deep web Morgan wakes up and is a little groggy, so he needs to get some coffee.  He stumbles upon one vendor who will sell him coffee... for a $25 minimum charge.  His complaint is that he loses money on the volatility if he goes too low.  But this is really an educational opportunity because there are service providers (such as BitPay who had a banner at the Bitcoin center scene) who will immediately cash out your bitcoin to fiat at the time of your transaction.  But Morgan has a large crew so buying 10 cups of coffee is actually a reasonable course of action.
Finally, he finishes the show at the Grumpy Cafe and recruits a new vendor to accept bitcoin.  Although I don't think he has fully drank the Kool-aid on this one (being a coffee shop and all) since the payment is still sitting in the Unspent Transaction Outputs pool.
But what is interesting is what wasn't shown.  By my reckoning Morgan also bought some bitcoin from Coinbase, and there were lots of vendors who used Coinbase to clear their transactions. Most of those transactions occurred off screen, and some of them were duplicates (like me I doubt Morgan can keep from going to the grocery store every day or two).

All in all I thought it was a fairly balanced piece on Bitcoin.  It's not often you get a journalist to actually use bitcoin before reporting on it.






Sunday, February 1, 2015

Ross Ulbricht Trial Day 9 - Mr. Yum's Testimony

If you are currently a juror for the Ross Ulbricht "Silk Road" trial you should close this page now, because this is precisely the kind of stuff the judge doesn't want you reading: armchair analysis of a witness on the stand.  Specifically Ilhwan Yum, who testified on Thursday which was day 9 of the trial.  I was a little underwhelmed by the testimony, but I don't think it's Mr. Yum's fault since the rules of evidence would preclude some of the more entertaining findings.  Also, the prosecution needs to tailor his testimony to a group of people who don't read /r/Bitcoin multiple times a day.

FBI Addresses

After some preliminaries where Mr Yum establishes a chain of custody for the two hard drives that were recovered and necessary legal positioning regarding MD5 and SHA1 checksums of the hard drive he confirms what has been essentially public knowledge: the coins from Ross's Laptop were swept into 1FfmbH...paPH. What wasn't explicitly stated was that the coins from the Silk Road server were swept into 1F1tAa...4xqX.  It was also made clear that the addresses held coins from the two different servers. There was some brief mention the sum of the address was higher, but the defense addressed that later.

There was some operational information in the testimony about how they claimed the silk road coins.  Apparently the sweep occured while the site was live and operational, and they even went through some steps to insure that the balances wouldn't be updated until all of the bitcoins were seized.  And they even used the bitcoin services that were already on the server.  This was important because the initial sweep off of the server took about four ours, according to the blockchain.




But what is interesting is that there appear to be two larger bumps within the next month:

Every circle on this chart represents a transaction into the 1F1tAa address.  Most of the dots on the flat part probably represent "dusters" and "taggers" as I call them, but I don't know if the big jumps are coins recovered from other servers or coins that were improperly swept up.  There's a lot of them so it's hard to tell.

Since this is a legal proceeding I think I should also be a bit more precise.  The coins were not actually on the Iceland server, what was found was the private keys to bitcoin addresses, lots of them.  Over 2 million on the Iceland server and over 11 thousand on Ross's laptop.  Clearly there weren't that many addresses holding a balance, so the sweeps only gathered those coins with balances.  These addresses were entered in as CDs and are exhibits 650 and 651, which an individual well known in bitcoin circles has said he will be obtaining.

Connecting the dots

This is the part of the testimony I found most astonishing.  The analysis was simply of one-to-one transactions.  That's not the astonishing part, the rules of evidence basically would only allow transactions to be admitted to evidence where the party conducting the transaction is known and proven.  In this case they only took effort to prove the transactions on behalf of keys held by the Iceland server to addresses whose private keys were on Ross's Laptop.  One to one, not passing go or going through a tumbler or even through any kind of a relay.  Direct from Iceland to Ross's laptop.  That was the surprising part, not the astonishing part.

The astonishing part was how many bitcoins went into Ross's Laptop.  There were 700,254 BTC worth of these one-to-one exchanges that occurred, and only 89,000 BTC received didn't come directly from silk road, 88.7% of the coins had a direct connection.  Rather than detail every transaction in excruciating detail the defense showed only one: b3561f...4984

I'm not sure why this transaction (the one in yelllow) was shown of all of the possible transactions to show.  But judging on the way legal processes can go they were likely putting something into play that may need to be referenced later.

But wait... there's more!

You didn't think they would spend all that time and effort just to get a victimless crime prosecuted?  Although they prosecution hasn't come out and made the final accusation in testimony (it's supposed to be coming Monday 2 Feb) they did have Mr. Yum enter in evidence relating to a transaction that wasn't one of the one-to-one transactions, but instead came from Ross's laptop.  Mr Yum stuck to the boring details of the transaction itself in his testimony.



He read in two transactions, and over the course of several pages makes it clear that the coins from the top three transactions were from private keys on Ross's laptop, the orange transaction came from Ross's laptop, and the coins in blue (later spent in the transactions in blue) received the coins he sent.  Something more than $489,000 USD by Coinbase's estimates (where I get my transaction rate information).  The next witness was getting to the good parts before the judge sent everyone home for the weekend.

Defense Cross Examination

The defense didn't spend nearly as much time cross examining the witness as the prosecution did directly examining him.  And there was no redirect.  But what he did do was place some seeds where a reasonable doubt could form.  Like he worked with a partner, he wrote his analysis programs in Python (actually it was Mr. Edmond who did the hands on typing, coders get left out of the spotlight again), but they chose that because Pie Wallet (which was written in Python) was already on Ross's laptop.  Those were all conversational.

The real doubt seeds come int he questions that are relating to the fact that the FBI is new to bitcoin seizures.  They initially didn't have a protocol in place to seize coins, which Mr. Yum helped establish.  Wallets can move from computer to computer, (but some other forensic data established their last access date). The government had access to the Iceland server for months before the shutdown.  And hey, maybe Silk Road was just a hot-wallet service? Some of the more blockchain related questions (and the more sensible ones) were when the defense also discussed the practice I call "dusting" and "tagging" with the witness, not grounds for reasonable doubt in my book.

He also tested Mr. Yum's knowledge of the large transactions on the blockchian.  The defense asked Mr. Yum about a large transaction on 22 Nov 2013 that summed 195,000 BTC.  He then showed him some paperwork (but the transcript doesn't have references to the evidence numbers) and claims it has three outputs.  I'de love to see what Mr. Yum was shown because I believe it was these two transactions (1746d7...8ca9 and 1c1244...d204), but the lack of precision annoys me.  It was described as
a transaction of 195,000 bitcoin that that was then quickly broken up into three smaller transactions [source]
There are two transactions close to that sum, both on the same date (22 Nov), and both are nearly 195 (194.993, with over half a BTC in the earlier one).  Also both had two outputs.  While there was three between them I think the defense was being sloppy in their questioning.  Here's the graphs (minus the 47 inbound transactions for the first tx).



And what bothers me more is that the notion of on the spot "blockchain trivia" somehow makes an expert qualified or not.  There are over 58 million transactions and you expect a witness in a trial to be able to answer about a random transaction without their proper tools and due diligence?  If I had to guess I would have gone with a Bitstamp audit (and I would have gotten lucky).  Perhaps he felt he could ask because it was from a government exhibit, but I can't tell from the transcript.

Presumption of Innocence Still Stands

Don't forget, as of this post the trial isn't over, and Ross still has the presumption of innocence.  While you may be reading the transcript and be ready to convict someone (Ross or the government) realize that the prosecution hasn't rested and the defense hasn't had a chance to present their case.  If the case seems damning, that is only because the prosecution is competent in what they do, because if they didn't get to this point in pre-trial the judge would have kept it off her docket.

But the real question is how will the defense will address their side of the case.  Spoliation of evidence?  The keys were planted?  Ross was a patsy for the real DPR (that's been teased in opening statements)?  Ross never created those transactions he just held the keys as a backup for the real DPR?  It was actually Mr. McMillan the school custodian who would have gotten away with it if it wasn't for those meddling teenagers and that talking dog?  Who knows, it's their case to make.

So please, keep the pitchforks and torches down until the jury comes back with a decision.  Then we can see which side will be mobbing and for what reason.

Wednesday, January 28, 2015

796 Theft of 27 Jan

Bitcoin thefts come in all shapes and sizes.  Recently 796, a Chinese bitcoin exchange, has one thousand bitcoins stolen from them via a series of social and technical attacks.  This isn't a very large theft, only representing less than CN¥ 1,500,000,000, which translates to US$250,000 or the cost of a double wide trailer in silicon valley.  But the real question to be asked in this blog is this: does the evidence on the blockchain match the narrative presented in the official explanations?

The Narrative

CoinTelegraph was able to talk with 796, and in combination with a post on weibo (hope you can read Chinese) the following narrative emerged.  Being a bitcoin exchange they are always a target for theft and abuse, and three months ago they migrated their servers to a cloud host.  However somehow a hacker was able to replace one users address with another similar address.  At this point the hacker needed to simply wait for a transaction to be posted.  And they got lucky with a large 1000BTC transaction.

This is the point of the story where one of the ugly truths of cyber defense becomes manifest.  You have to be 100% in all of your defenses and secondary systems, but the hacker only has to get lucky once or twice.  This hacker had already had some luck getting the data updated on the server.  They had another stroke of luck getting the bitcoins out.  First, the weibo post indicated there was another level of approvals needed to permit the transaction because the transaction looked suspicious because of the use of different IPs.  But the transaction met the standards of approval so the transaction was processed.

About five hours later the customer who initiated the withdraw is in contact with 796 over the phone and they indicate the bitcoin had not shown up in the customer's destination address.  At this point a full scale investigation is launched, and it is revealed that the coins went to an address that was similar to the address that was intended.  This is where the hacker got lucky: by using a similar address it passed both 796 manual review and the customers manual review of the information.  Because when it comes down to it 35 characters of randomness does get tiring on the eyes after a while and if you have to commit it to memory, you probably only memorize five characters or so.

After the details are sorted out and the investigation is concluded 796 owed up to the theft, and took the losses out of company profits.  For 796.com client losses have a senior claim to shareholder losses, so there was no vote or consultation with the investors.

The Blockchain Evidence

On the 8btc.com forum (8btc is a Chinese language bitcoin forum) one post identified the theft address as 1CvGkU...2wrU.  There was one large transaction at 15:50 GMT on 27 Jul.  The whole of China is on the +8:00 time zone, so the timing of the transaction would be 23:50, consistent with the weibo post.  It was then committed to block 340748 a nearly a minute later.  So did a suspect transaction go out?  The evidence does match the narrative. 

But there is also the second half of the narrative.  796 also said that they would take responsibility for the theft.  About 13 hours later another withdraw of 999BTC is sent to the address 1CvGkM...vJwU.    Not that the first four characters of this address matches the first five characters of the theft address. It also matches up with the claim of the insertion of a similar address.  Note however, that this is 1 BTC short of making the customer whole.  If we look at the other transactions to the 1CvGkM address we see another transaction an hour earlier.

Ignore the dates on the transactions.  These are self-reported by the miners and the protocol allows for something on the order of two hours of skew. In the block prior to the 999BTC transaction a 1 BTC transaction is sent to the correct address.  I presume that this was done to test the waters of their system to make sure that the reported address can be trusted.  The next block is when the 999BTC is sent, and three blocks after that the customer then gathers the coins and spends it in two separate transactions.

These two transactions made the customer whole and the timeframe seems reasonable enough, being the next business day during business hours in China.

Technial Details

You have probably noticed that I elide the transaction identifiers and addresses in my images and in my text.  There is one principal reason for that, and it's not to protect privacy or redact data.  The reason is that 64 hex digits in a row and 35 alphanumerics in a row are hard on the eyes.  I take the six leading characters and the four trailing characters because one sixth to one third of the data is enough to reproduce my findings.  There are many occasions where a single address or a single transaction when elided will look like another address or transaction id.  However, when you assemble the network and take the elided addresses and transaction ids in context, the elided data provides enough information to reproduce the data displayed in my images.

The cognitive fatigue of looking at all of that data played a part in this hack, so it is my hope that by slashing the amount of data shown that the user might be able to process all of what is shown, rather than a part of the whole that varies between users.  I am fairly certain that it is good enough for analysis.

In fact, if anyone can show me a transaction on the blockchain where one address combined with the input and output transactions cannot be distinguished from a similar transaction based on the elided values, I'll send you a box of girl scout cookies. Of course I'll only pay up when girl scout cookies are on sale.  If you can show me one below block 340950 then I'll even let you pick the (in-stock) flavor of cookies.  This offer is good only for the first taker however, and only in jurisdictions where they are legal (they are addictive after all).

Monday, January 19, 2015

BitStamp Theft - Two Weeks Later

Before I get into the analysis I'de like to thank all of you who have found me in the past two weeks. What used to be a sleepy and infrequent technical blog resulted in a story on CoinDesk (where they took my analysis and re-told it in a form even an e-mail administrator can understand), an interview on The Bitcoin Game podcast over at Let's Talk Bitcoin, and I even got a name-drop on GigaOm.  As always your interest and feedback is appreciated.

BitStamp Theft From Old Wallet Addresses is Still Ongoing

Now that it's been over two weeks since the hack you would think that people have received the memo to not use their old BitStamp deposit addresses or at least to not put large sums of bitcoin in them.  You would be wrong.

Last Friday there was a 700 BTC deposit that was caught up in the heist.  Check out the block numbers and transaction time.  It was stolen in the block after it was confirmed in and it was also stolen in 3 minutes flat from the confirmation of the previous transaction.  Also, this wasn't an account that has been stolen from before, this the first transaction to the theft wallet for this address.

One obvious question is "was this a customer?"  I consider them a Bitstamp customer because they have shared transactions with other affected accounts before.  One such transaction is 311f9f which shared inputs with 18dsZT and 1BPezx, both of which were "doners" to the 1J2Ls theft address.



They have been at this address with Bitstamp for over a year now and have made several sizable deposits before.

This transaction is actually relevant for reasons other than its loss.  On my podcast I said if I had to make a Vegas bet about what I thought happened I would have gone for some form of server modification in the transaction signing program.  I think I would lose money if I ever make that bet since this seems to be conclusive evidence that private keys were lost in the hack, or keys that run a deterministic wallet were leaked and the thief knows what to do with them (which would explain the change address quirk with cold storage).  I was hedging my bets because I didn't think such a leakage was necessary for this theft, but now I really see little alternative to that conclusion.  Since this transaction occurred over a week since the hack occurred it is unimaginable that the old servers were still running and processing transactions, and the speed of the movement combined with the high fee indicates this isn't a normal transaction.  This will likely lead to some very uncomfortable discussions between the customer, Bitstamp, and whoever the customer is accountable to.

Stolen Coins Continue to be Spent

The last time I looked at the outputs I saw only three locations where you could confirm they were being mixed with other coins.  Now, the spending is going in earnest all over the place.  I considered doing a comprehensive analysis of the particular places they were mixed, but that would take way too many words to write about.

As of block number 339205, which cleared on or about Friday 16 Jan 2015 at 5:33 GMT, a rounded total of 19,940 BTC has been deposited in the 1L2Js theft address.  About 95% of those stolen coins have been spent out of that address.  For the most part the 5% of the coins remaining represent new balances arriving after the theft went public.  For transactions and outputs that are one step away from the theft address a rounded total of 19,274 BTC is either sitting in unspent transaction outputs (60%, or about 11,495) or has been spent in a transaction (40%, or about 7,752).  The sum on the first step is greater than the original because some of these transactions involve coins that were not involved in the theft.  The second step shows a similar unspent/spent ratio (54%/46%) but a significantly higher rate of mixing with coins outside the theft.

One interesting outbound transaction from the theft involves 1 BTC that has been sent to the Sarutobi iOS game. This is a game that rewarded players with 100 bit donations (just over 2 cents when I was writing this post) if they played the game well.  It took a long and winding road, but after 21 transactions Sarutori starts splitting it up into it's hot wallet address 3MXxfN.


All of the transactions not on the top line are 100% derived from the stolen coins, all the way to the very bottom row.  And it gets even more insane when you go down some of those chains I didn't expand after Saurtobi split it up into quarters. For these four peel chains, until it hits the users wallet for those transactions, the bitcoins have a 100% taint from the theft address.  And those peel chains down the 3MXxfN paths are insanely long, some of the longest peel chains on the blockchain.  And those have all been formed in the last three weeks.

Conclusion

Unless something else interesting happens with the Bitstamp theft coins, I don't see myself returning to report on their propagation across the blockchain.  There is just too many threads forming from the coins that have been spent and they are for the most part unconnected to each other.  I find it unlikely at this point that any of the coins will be returned "intact" to Bitstamp (sorry).  The thief has proven that he can unload 40% of them inside of two weeks, so the other 60% may just be bag holders who may or may not be aware of the true origin of their balance.

If you know of any interesting transactions on the blockchain that may benefit from a visual analysis, feel free to drop me a line at danno.ferrin@gmail.com or tweet me at @Numisight and I'll take a look at it.  I cannot guarantee blog coverage if I don't find any entertaining findings.  I am also open to paid investigations or paid consulting relating to blockchain analysis, and I can be as public or confidential as you desire.  For these inquiries please send email to danno@numisight.com.

Thursday, January 8, 2015

BitStamp Theft Bitcoins Being Spent

The BitStamp Theft coins are more than on the move, they are being spent or being prepared for spending. The controller of the 1L2Js address has a problem, since the vast majority of the bitcoins that were stolen have been placed into a single address. Anyone who looks at addresses would clearly be able to see that those coins were stolen. And any regulated exchange is supposed to engage in these pattern matching practices, so if they want Dollars or Euros then they need to do some gymnastics.

Up until block number 338060 the presumed theft address 1L2JsXHPMYuAa9ugvHGLwkdstCPUDemNCf has kept it's output coins in a closed system. By closed system I mean that if you trace all input coins repeatedly every coin would pass through a 1L2Js address eventually.  The first address to break the pattern is 15wsXq5uSe2aT5BssLvQehUAQVn525RH25.  First we need to be careful of false positives, to make sure we are not just reporting someone tagging an involved address with 666 bits.  So here is the "heratige" of the 15wsX coins:

The very top transaction, 8328a2 contains 13 inputs from the 1L2Js address associated with the theft.  The gathered amounts are then peeled off until we have two 1BTC amounts in the 15wsX address.

Quick sidebar: note that even though the entire source of the BTC can be traced back to the hack, we cannot presume the controller of 15wsX is the same as the controller of the theft coins.  It is very easy for each of those peel chain steps to be the deposit to another party willing to buy hot bitcoins. There were 5 places in this chain where it could have happened, so it is a possibility that cannot be dismissed.

This part of the chain is where the external linkage happens.  For clarity I will only show the 930ae0 transaction, but the b52316 is functionally identical.
This transaction is either a simple coinjoin or it is a transaction deliberately structured to look like a coinjoin.  On the left we have one BTC in and one BTC out.  On the right we have some loose change in and 100 bits less out.  If you look at the transaction (here it is on blocktrail) you will see that 100 bits was the transaction fee paid.  Both sides of these transactions could very easily be their own transaction, so we cannot presume that the transaction is a single party transaction. This little bit of loose change washing continues to wash other amounts for quite some time (all the yellow transactions follow this pattern).
The exact same pattern is seen for the other transaction as well.  My conclusion is that the loose change address is intended to "wash" the bitcoins by spreading the taint of their source around.  However since the wash amount is less than the output amount then at least some of the BTC in the 1HRv8 address had to have come from the previous address, removing the plausible deniability.  This isn't the best washing job I've seen.

This may be a transaction only designed to test the waters for identification, but I think it is safe to say the thief intends to sell or spend the proceeds of the theft, if they haven't done so already.

Wednesday, January 7, 2015

Bitstamp Theft Change Addresses and Late Transactions

The coins in the stolen address are on the move, but at the moment (block 337938) they are in a closed system with no outside coins.  But there are some other interesting transactions to examine first.

When looking at the fact that BitStamp was hacked it is natural to immediately has how were they hacked.  With the information available I don't think we can give a definitive answer, and the evidence is a little unclear at the moment.  Assuming this was an outside actor there are two simple explanations: the private keys were stolen/leaked/compromised or the outside actor was inducing the BitStamp systems to pay him out.  However there are transactions that bring those two simple conclusions into doubt.

First, if this was simple key theft then why was the 1L2Js address generating change addresses that BitStamp was able to sweep into 1Jokt (that is presumed to be BitStamp cold storage).  Here's one address:

The b68738 transaction sent over 32 BTC to the theft address and created a change address 1BtGH with over 641 mBTC.  Less than an our later at transaction d1d835 a transaction placed exactly 10 BTC into the current BitStamp cold storage address.  The change address also peeled off into more cold storage transactions.  It is unlikely the thief was being nice and putting the coins back in the vault.  This happened two more times:
Transactions 2378aa and a8c199 both created separate change addresses and sent to the same theft address (which has since been swept up into another address).  However both of the change addresses were sept into BitStamp cold storage (and those change addresses also peeled into more cold storage).  Bit that's not the strangest part.  The 19C5D and 1BtGH addresses were not single use addresses.
The 19c5D address was an input to a theft transaction and there are still just over 10 mBTC sitting in an unspent output to 1BtGH.  The 1KPeo address is at the moment a single use address.  

Why on earth would the thief create change addresses that BitStamp could use to sweep the change into cold storage?  This is evidence in favor of someone inducing the BitStamp systems to pay out to a theft address.  But you would think that BitStamp would shut their old system down after a couple of days, and we wouldn't see any more large movements into the wallet except taggers and dusters. Except nearly 4BTC is not a dusting and tagging amount:
Over $1,000USD is a bit high for an address tag, and a bit high for misdirection. This coin was also generated after the thefts occurred, so it can't be a stray transaction that got lost in the network.  My best guess is that this was a deposit account for someone that didn't get the memo to stop depositing.  If this was a deposit address their last deposit was before the hack:
Then their deposit was used to tumble out some payment to another account prior to the attack as well. (BitStamp is reported to have it's own mixer/tumbler available for customer use.  I haven't used BitStamp and obviously can't open an account to verify at the moment.)

Better evidence of it being a long standing deposit can be seen with BlockTrail's summary of the address.  It is very spiky and goes to zero a lot, so it's not a long term holding address but a transactional one.

So the simple explanations are out the window.  The two leading explanations in my mind are that the theft stole the keys and the software and stood up their own instance of the hot wallet to do the theft, or that the compromised services at BitStamp are still up and running.  Either one of these could have been done by an inside agent or an outside agent.  Odds are BitStamp won't say much until the relevant law enforcement agencies has had their turn to examine the evidence.

Tuesday, January 6, 2015

Bitstamp Hot Wallet Theft - 2 to 5 Jan 2015

From 4 Jan to 6 Jan 2015 Bitstamp experienced a loss of nearly 19,000 Bitcoins from it's operational hot wallet (CoinDesk has a nice writeup about the issue).  A reddit thread identified what it believed to be the destination address for the stolen coins: 1L2JsXHPMYuAa9ugvHGLwkdstCPUDemNCf.  Evidence on the blockchain is consistent with this allegation.

First, this address was not seen prior to 4 Jan 2015, and within 24 hours it had amassed nearly a 18,000 BTC balance.



A graph of the transactions that involve the alleged address shows a lot of interaction between other addresses.



Older transactions tend to be to the right of this graph, and they form peel chains that in some cases are combined multiple times into one transaction.  It is interesting to note that some of the transactions form exact sums of the collected coins.  To the left of the graph we start to see some of the "dusters" putting dust amounts into the 1L2J wallet.

One of the concerns on the reddit thread was that the cold storage may be leaking.  If the address found in another comment is to be believed, then their cold storage is not leaking.


If anything coins are being moved into cold storage based on the uptick on 4 Jan 2015, so there is no evidence of a cold storage leak.

So how could this happen?  (Warning, baseless speculation follows).  There are two ways this could be done, first the private keys of the input addresses could have been leaked.  This would be consistent with their request to stop deposits.  The other possibility is that the attackers somehow are inducing their software to send all the bitcoins to an address of their choosing.

What would indicate private key compromise is continued activity and continued theft.  While we see continued activity on 6 January 2015 it appears to be of the "dust tagging" variety.  Consider this peel chain:
100 bits are peeled off four times from the same source address.  This is not consistent with the earlier transactions where the change addresses were single use interior addresses.

Second, there is evidence of deposit addresses not being cleared out after the bulk of the movements occured. Consider the address 18unRBGev1pkTo35zqCtCscSWUg4r9RNrh that looks to be a P2Pool payout address.


There were five deposits that were stolen durring the hack, but 2 addresses appear to be untouched on the 6th of January.  If the hacker had the private keys (along with bitstamp) then there would be a race to cash in those deposits.  If bitstamp was worried about a private key theft surely they would aggressively sweep it within the hour, instead of waiting nearly 8.

So why didn't BitStamp simply pull the plug the moment they were sure they were hacked?  Maybe they did and this was just the remaining transactions propagating through the system.  Or perhaps they were attempting to sweep what they could to their cold storage.  There was over 6,000 BTC of movement into cold storage near the tail end of the hack, representing $1.5 Million of value saved.



It could have been worse.

This analysis was performed when the blockchain was at height 337832, so any transactions after that block are not reflected in this post.