Cyphertite was not vulnerable to the Heartbleed attack.
Disclaimer: These findings are true for the Cyphertite service ONLY. We are not making any statement about other people’s results and/or attack surface.
We did not receive an advance warning of the Heartbleed vulnerability. As soon as the news broke the Cyphertite team shut down all services and began investigating its exposure. We quickly established that the website was not at all vulnerable to Heartbleed (it uses OpenSSL 1.0.0f) but we used a vulnerable version of OpenSSL on the service itself (OpenSSL 1.0.1c). The service was patched and brought back online with 3 hours of the Heartbleed announcement, however, at that time, we did not know the extent of Cyphertite’s exposure.
As btcd nears completion we decided to have at least one round of deslugging because we were much slower then bitcoind during chain download. Let me clarify that term for the ones that don’t know what that means. Deslugging is the art of measuring (or profiling) run times of individual functions, determining which ones are slugs and which ones could be optimized. Armed with that data one attacks said functions to see if there are some less then optimal algorithms. Surprisingly enough, this is often the case. An industry truism is “measuring is knowing” and attacking functions based on gut feeling often does not yield satisfying results. As always with these exercises, some things work and some don’t. Throughout this blog I’d like to walk our readers through some optimizations that succeeded, and one, objectively, failed attempt.