When it was first created in 2009, the original bitcoin program had two variants. They are totally compatible, take the same command line arguments, and essentially perform the same functions. The main difference lies in how the user interacts with them - one, commonly known as ‘Bitcoin Core’, formerly known as ‘Bitcoin-QT’, has a graphical user interface (GUI), while the other, ‘bitcoind’, is headless and lacks a GUI.
A Bit of Background
bitcoind is an abbreviation of bitcoin daemon (a program that runs in the background rather than being under the direct control of an interactive user). bitcoind was created to be compatible across various operating systems, and runs on Windows, Mac, and Linux. It’s written in C++ and is a multithreaded program, meaning that it can run multiple threads to handle concurrent operations without needing to run several copies of the program simultaneously.
As the original bitcoin client, bitcoind’s core function is to connect to the bitcoin network and assist with generating and storing private keys, sending payments using those keys, and providing information about transactions, private keys under management, network status, etc -- essentially all the core functionality of the bitcoin protocol.
- Initialization and Startup: Upon startup, the client performs various initialization routines including starting multiple threads to handle concurrent operations.
- Node Discovery: The client uses various techniques to find out about other Bitcoin nodes that are currently connected to the network.
- Node Connectivity: The client initiates and maintains connections to other nodes.
- Sockets and Messages: The client processes messages from other nodes and sends messages to other nodes using socket connections.
- Block Exchange: Nodes advertise their inventory of blocks to each other and exchange blocks to build block chains.
- Transaction Exchange: Nodes exchange and relay transactions with each other. The client associates transactions with bitcoin addresses in the local wallet.
- Wallet Services: The client can create transactions using the local wallet. The client associates transactions with bitcoin addresses in the local wallet. The client provides a service for managing the local wallet.
- RPC Interface: The client offers an JSON-RPC interface over HTTP over sockets to perform various operational functions and to manage the local wallet.
It seems like everyone in the industry just can’t get enough of talking about multi-sig, but the sad state of affairs tells a different story. At the time of this writing, less than 8% of coins are stored in multi-sig addresses, which is an astoundingly low number given the obvious security benefits. Given these stats, it’s not very surprising that exchanges continue to be hacked - just last week BTER lost over $5M and Cavirtex shut down due to a suspected hack.
By eliminating a single point of failure, multi-sig offers a substantial upgrade in terms of security over the original single-key address model. Bitcoind allows users to construct multi-sig transactions but doesn’t include a cosigner, making it weaker from a security standpoint. At this point, running bitcoind without multi-sig is clearly not an ideal solution, but the cost of switching to a multi-key model can be fairly high. If you’re running an exchange or other type of service built on bitcoind, you have an understandable aversion to reconstructing your entire system to include multi-sig wallet functionality. The good news is that as of this week, you don’t have to.
BitGoD: a More Secure Alternative
BitGoD is a drop in replacement for bitcoind which offers access to BitGo’s platform API, and uses bitcoind for all its functionality with the exception of wallet capabilities. The main benefit is that it can substantially reduce the cost of switching to multi-sig by speeding up integration time and allowing the client to operate a multi-sig wallet as if it were dealing with a standard bitcoind instance.
Bitstamp, one of the largest bitcoin exchanges in the world, was able to implement BitGoD and switch over to multi-sig by replacing a single line of code. You can find a full recap of how that happened here. Since that integration took place in early January, BitGoD’s scope has expanded to include a test suite, coverage for additional bitcoind JSON-RPC calls, and the ability to validate transaction data against the local bitcoind.
I may be biased because I work at BitGo, but feel free to have a look at the code yourself. You’re obviously encouraged to implement BitGoD, or if you’re building from scratch, you may want to check out BitGoJS SDK,BitGo Express or integrate directly using our REST API. Whether or not you decide to decide to use BitGo, however, I encourage you to move over to multi-sig as soon as you possibly can. I can’t emphasize enough how important good security practices will be if we ever hope to grow the bitcoin network to its full potential -- and now that you can add multi-sig functionality without rebuilding much at all, there really are no more excuses.