As was recently announced in a previous blog (here), btcd is an alternative full-node implementation of the bitcoin wire protocol and block validation written in Go that is currently under active development.
We’d now like to announce a public preview of one of the core packages from btcd. The package is named btcwire and it implements the bitcoin wire protocol. The code can be reviewed on github here:
https://github.com/conformal/btcwire
Overall Package Design
At a high level, this package provides support for marshalling and unmarshalling supported bitcoin messages to and from the wire. This package does not deal with the specifics of message handling such as what to do when a message is received. This provides the caller with a high level of flexibility.
For the uninitiated, the bitcoin wire protocol consists of exchanging messages between peers. Each message is preceded by a header which identifies information about it such as which bitcoin network it is a part of, its type, how big it is, and a checksum to verify validity. All encoding and decoding of message headers is handled by this package.
To accomplish this, there is a generic interface for bitcoin messages named Message which allows messages of any type to be read, written, or passed around through channels, functions, etc. In addition, concrete implementations of most of the currently supported bitcoin messages are provided. For these supported messages, all of the details of marshalling and unmarshalling to and from the wire using bitcoin encoding are handled so the caller doesn’t have to concern themselves with the specifics.
Interoperability and Test Coverage
Here at Conformal, we are keenly aware of how important it is that any full-node implementations agree on the exact same set of rules for what blocks get included into the block chain as minor differences can lead to chain forks and double-spends. However, despite the challenges, we also believe that it is imperative for the evolution of the bitcoin ecosystem as a whole that multiple reference implementations come to bear. It will substantially improve the diversity and resilience of the bitcoin ecosystem and infrastructure in the same way web standards have improved the web.
Since btcd is financial software and errors could lead to someone losing money, we take test coverage particularly seriously. At the time of this writing, the btcwire package has 78.5% test coverage of all lines, however we will be increasing this to 100% over the coming days.
Edit: The package now has 100% test coverage as of 5/13/2013.
Staggered Release
Our goal is to continue releasing packages from btcd as we increase test coverage and bring them up to a professional level. The intent is that each piece can then be publicly reviewed for correctness as they become available while we continue work on the remaining packages.
The next package we plan to release is btcjson, which handles the marshalling and unmarshalling of JSON-RPC calls and supports the RPC calls outlined in the official bitcoin API calls list wiki here.
Bitcoin 2013 Conference
I’m scheduled to give a lightning talk at the bitcoin 2013 conference Saturday afternoon regarding btcd and the general importance of alternative full bitcoin node implementations to the bitcoin ecosystem.
Come out and see me!
This is actually great. Keep at it!
Thanks for the feedback. Stay tuned for btcjson which should be released early next week.
thanks
openbsd really needs a BTC wallet
I completely agree. On a positive note, I know several of us working on the project run OpenBSD/Bitrig as our primary OS, so once btcd is released and wallet support is added, it will definitely run on OpenBSD.
What about Plan9? They have a port of Go but I don ‘t know what kind of dependencies this program has.
The only dependency we are using that is not native Go is the sqlite3 binding for the block database. I know there is a sqlite3 port for Plan 9, so, while I don’t believe any of us have tried it on Plan 9, I don’t see any reason it won’t work there as well.
btcwire works fine on go/plan9. it has no dependencies outside of the go standard library.
currently plan9 go has CGO_ENABLED=’0′, meaning no c libraries can be used.. so if btcd depends on sqlite3 it’s out the door.. the best option would be to have pure go.
Great approach, especially around tests and portability. C++ has real advantages at the performance level if implemented in a modern revision like C++11, i.e. with a whole lot less Boost and STL horror littering the code base. I can see a Go implementation even being used for something distributed, peer-to-peer mining pools, potentially a big win given the recognized centralization problems with the current “big mining pools dominate” situation. Good stuff!