This week I embarked on the experiment of seeing how much Bitcoin client you can build on OpenBSD. I might as well use this space to consolidate the mental notes on the process I used. Some particular details have likely slipped my mind already, so consider this an abridged guide. The version I ended up building with this process was 0.7.2, it builds fine with or without upnp support and with or without QR code support. Going earlier in version to 0.5.3 or the 0.6 series should be fine too, you just might have to make some different changes in the source and flags.
Building any later version which uses leveldb for blockchain storage might not be possible on OpenBSD. The Bitcoin source tarball for later versions includes its own leveldb source and hammering that into a shape that will compile into something useful on OpenBSD is a challenge too far. Note that around the 0.8 release with the move to leveldb is when the effort on Bitcoin in the OpenBSD work in progress ports tree dropped precipitously.
- Your first order of business is acquiring a source tarball from somewhere. Ask a friend. Download it from Github. However you acquire it is your business.1
- To minimize headaches I installed the version of BDB this version of Bitcoin-qt expects:
curl -O http://download.oracle.com/berkeley-db/db-4.8.30.NC.zip
../dist/configure --prefix=/usr/local --disable-replication --enable-cxx --enable-shared=yes
Now that there's a base it's time to extract the tarball, fire up a text editor and start chopping at code. It's fire up the text editor and chop because reading is good, and understanding is good.2
- The first change is to wallet.cpp as described here. In OpenBSD world rand() is the shitty C standard compliant deterministic random and arc4random() is the good random. As the man page explains arc4random isn't based off of arc4 anymore so the mnemonic is now "A Replacement Call for Random" and the backend remains liable to change in the future. The need for this will likely be changing after OpenBSD 5.7, but until then this change is explicitly necessary.
- For the second change we consult the Bitcoin Foundation's patchset for bitcoind 0.5.3.1 particularly its BDB database configuration patch. Simply read the changes and make the changes. This protects against the great blockchain fork of March 2013's dilemma.
- For the third change we consult the foundation's Alert snipping patch. The patch cannot be used as is because the alert code's been move around since version 0.5.3 but it still informs of changes that can be made in 0.7.2 to remove the system. I futzed with the public key strings in Alert.cpp and deleted from main.cpp most of the alert invocation code. It is especially important though to remove the parts where your version would impose a denial of service penalty on nodes sending it bad alerts. Removing the Alert stuff is critical for making sure your node can function as is indefinitely into the future.
- Update: Originally I neglected that in protocol.cpp you need to add
- In the makefile change the invocation of -libboost-thread to -libboost-thread-mt and LIBS += -lrt when qmake gives you a makefile.
Address compiler errors as they come up. If everything worked out well the result should be a functioning version of Bitcoin-qt which will take advantage of multiple cores on your machine and as far as I can tell work. For initial sync you will want to do it from the network in the wild to make sure it is actually a Bitcoin implementation. Built against LibreSSL 2.0 it should make it past the first wedge block 168001 fine. Mine is still in the syncing process.
Expect it to die a few or a lot of times as it hits the 512 MB RAM limit during initial sync. You can avoid this by letting OpenBSD give it more memory, but the reason memory usuage is bloating so much are bastard fatherless blocks fed to you which fill your memory as you get fed more and more blocks you lack the precedent to verify. It is both kinder and faster to let malloc() kill the process when it hits them memory limit, and then just script restarting it.
When in doubt about something read. OpenBSD has wonderful manual pages. The depth and quality of documentation they contain is beautiful.
- There's multiple ways to do things. You are responsible for making your own decisions. I offer these notes without warranty and with the disclaimer that I am an amateur when it comes to building software assembled by other people. Building dependencies you choose from ports or doing pkg_add it's your call.Â If instead you just really want to gamble there are places for that. [↩]
- Also I can't emphasize this point enough, but I am an amateur to the point I haven't had occasion yet to learn the unix patch utility. Maybe if I had I'd submit this to the ports tree, but my actual self is the one putting this information together so... [↩]