I discovered the flaw thanks to a small stash of stolen bitcoins.

It all started with a missed call from a friend at 00:30 on August 5, and a subsequent SMS telling me that he got 0.91 bitcoins stolen from his Android wallet. "Somebody hacked my Android phone" he would repeat. I did not believe this to be likely. He is the most security conscious person I know. Besides, he is a computer scientist and knows the Bitcoin protocol in and out. Android phones are known to be vulnerable, but it's very unlikely that a phone that only ran reputable apps from Google Play got hacked. I thought about Spock, who quoted Arthur Conan Doyle: "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth". The impossible was that his phone got hacked. The truth then should be that somebody found his private key through cryptanalysis on the Bitcoin blockchain (the public ledger were all transactions are kept).

A lookup on the address that the funds were sent to revealed a forum post https://bitcointalk.org/index.php?topic=251743, so I put on my detective hat and read the post. I also published a message to it stating what had happened to my friend. The common factor seemed to be Android, and I immediately thought about the possibility of a flaw in its pseudo-random number generator (PRNG).

I investigated online and found this paper http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness-in-Current-Java-Implementations#page=9, which I sent to Mike Hearn pointing him to page 9 in which the flaw in Apache Harmony's PRNG (the one used by Android) was described. I also pointed to him that his BitcoinJ code was using that PRNG in the regular non-seeded way, which triggered the flaw.

I originally suggested that private key collisions may have being found and exploited. Later on the weekend a reply to the Bitcoin forum post by johoe clarified that the issue with the PRNG was leading to collisions in the random number parameter k that the elliptic curve signature algorithm needs in order to be secure, making it trivial to extract the private key from two transactions that used the same k.