The past couple days have been a roller coaster of events for the bitcoin world. First, MtGox suspended bitcoin withdrawals for a bitcoin “design issue that has been largely ignored”. Attackers took note of this and begin running malicious nodes to increase the frequency of the attack. To handle the network attacks, other big exchanges like Bitstamp temporarily suspended bitcoin withdrawals as well, while some businesses remain unaffected and continue operations as normal.
So, what have we learned?
Today Conformal is announcing alpha releases of btcwallet and btcgui, the wallet components of btcd, written in Go. We announced in a recent blog post that btcd, our full node Bitcoin implementation, was ready for public testing. We also announced that wallet functionality was being implemented separately and would be coming in the near future. Although our wallet daemon and GUI interface are not yet ready for production use, we feel they have progressed to the point where early adopters can begin testing their functionality on the Bitcoin Testnet network.
Our btcd blog post briefly discussed why wallet functionality is not a part of btcd. It highlighted various reasons why we believe separating wallet handling from blockchain handling improves on the integrated wallet design used by bitcoind and bitcoin-qt. This post will continue on that topic, further exploring the details of why a multiprocess wallet design was chosen, how such a design is beneficial to the Bitcoin community as a whole, and the implementation details this design.
Today marks the first release of gotk3, Conformal’s own GTK3 bindings for Go (available on Github here). These bindings were developed out of a frustration with other GTK bindings for Go either using ancient versions of GTK, not handling memory in a way a Go developer would expect, or simply not working at all on our developers’ OpenBSD and Bitrig machines. gotk3 is Conformal’s response to these issues and attempts to be the best solution for developing new GTK applications with Go.
One of the goals for developing gotk3 was to perform memory management in a very Go-like manner. Like many libraries which must handle memory management manually due to the language they are implemented with, GLib (and GTK which uses it) uses reference counting to determine when an object will never again be used and is ready to be freed, releasing the memory resources it required back to the operating system. However, GLib chooses not to use traditional reference counting, but instead uses a quirky variant called “floating references” to achieve this goal. The rest of this post will cover what floating references do, why they exist, and how gotk3 works around this design to handle memory the way a Go developer expects.
At Conformal, we keep up with the most secure cryptography technologies available and implement these technologies into our products and services whenever possible. However, we consider ourselves the minority in this practice, with most other sites only offering the bare minimum in terms of security. Amid the recent PRISM leaks, more and more attention has been drawn towards mass acceptance of one such technology, known as Perfect Forward Secrecy (hereforth referred to as PFS). This blog post will cover how HTTPS without PFS fails to protect today’s communication against tomorrow’s attacks, how PFS is able to prevent against these attacks, and the current state of PFS on the web and Conformal’s servers.