Building Riecoin 0.9.1 on Ubuntu 14.04


I’ve been trying to host a forked version of the open-source Abe block explorer for Riecoin, but gave it up a while ago due to finals and other school stuff. Now I’m back at it again, but since the last time I built Riecoin from source, the developers have switched to using autotools instead of makefile. I had a little trouble with Berkeley DB version compatibility during the process, so I’ve decided to write out the steps I took for future reference. Keep in mind that this applies to building Bitcoin as well! Also note that BerkeleyDB.4.8 is only really necessary for wallet functionality, which you probably won’t need on a VPS.

First, you’ll want to install dependencies.

sudo apt-get update
sudo apt-get install -y git make g++ build-essential libminiupnpc-dev
sudo apt-get install -y libboost-all-dev libdb++-dev libgmp-dev libssl-dev automake libcurl4-openssl-dev

Then, grab the source and build it.

git clone
cd riecoin

Running “./configure” is the next step, but this error is the result:

configure: error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore)

If you don’t care about wallet functionality simply run “./configure”, with the following flag:

./configure --with-incompatible-bdb

If you do care about wallet functionality, we’ll have to compile BerkeleyDB 4.8 ourselves, as well as tell the system where to find it.

tar -xzvf db-4.8.30.NC.tar.gz
cd db-4.8.30.NC/build_unix
../dist/configure --enable-cxx
sudo make install
export BDB_INCLUDE_PATH="/usr/local/BerkeleyDB.4.8/include"
export BDB_LIB_PATH="/usr/local/BerkeleyDB.4.8/lib"
sudo ln -s /usr/local/BerkeleyDB.4.8/lib/ /usr/lib/
sudo ln -s /usr/local/BerkeleyDB.4.8/lib/ /usr/lib/

Now we can run configure with the following flags, and follow up by running make.

./configure CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include -O2" LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib"

If you run into “g++: internal compiler error: Killed (program cc1plus)” like I did on a 1GB RAM VPS, check out DigitalOcean’s guide on adding swap space. 2GB of swap did the trick for me.

Wait several minutes for the make process to finish.

Edit: The db4.8 process described above is probably unnecessary. If it works as is, great, but if it doesn’t, simply grab libdb4.8 with apt-get:

sudo apt-get install libdb4.8++

After make completes successfully, create the conf file.

mkdir ~/.riecoin
nano ~/.riecoin/riecoin.conf

An example config is shown below. Press Ctrl+X after pasting into nano to save.


Then run the Riecoin daemon by entering:

cd ~/riecoin/src

You will now be able to enter console commands in the following format (with mining info example):

./riecoind wallet_console_command
./riecoind getmininginfo

That’s it! If you found this tutorial helpful, please consider liking it, and be sure to leave a comment if you have any questions.

Must Watch Playlist for NI Massive Beginners

If you’re like me, and tired of using presets on Sylenth1, Massive or (insert preferred synth here), then this YouTube playlist by thesoundtutor is a must watch. It’s over 4 years old, but the quality of the concepts introduced are priceless. You will initially learn how to combine different oscillators, how to mess with wavetable positions, and how to adjust Attack-Delay-Sustain-Release envelopes, but it will go deeper than that as you start to see all the various knobs/filters/effects route through each other. The take-away is that you can apply this knowledge to most other synths. Treat it primarily as a course in sound design, but if you’re actually looking at creating your own phat Dubstep/Glitch/Neuro bass then this will be twice as sweet. Enjoy!

Writing Your Own Currency in Just a Few Lines of Code

Writing Your Own Currency in a Few Lines of Code

I’ve been following the development progress of Ethereum lately, which many have described as the “Cryptocurrency 2.0,” utilizing Bitcoin’s revolutionary decentralized consensus concepts while creating a whole new platform for building distributed applications. One of the most touted selling points of Ethereum is the ability for developers to create and manipulate Turing complete contracts on its blockchain. Ether, Ethereum’s internal currency, serves to power these contracts and the applications that arise from them. These contracts run in the Ethereum Virtual Machine (EVM), but one will be able to use several higher level in-house languages (Serpent, LLL, and Mutan) to write the contracts that compile to EVM code. The Ethereum client exposes an API that can be accessed through Javascript, supplying various useful methods for interacting with Ethereum contracts. Hidskes’ blog post goes on to teach you how to write a backend Ethereum contract which will then interface with a simple HTML/Javascript frontend. This essentially serves as a functional albeit simple currency, with send/balance features but a 100% premine. You won’t be able to get anyone other than yourself or a friend to use it, but the proof of concept is there and that’s all we need to get started. It’s very straightforward, illustrative, and eye opening to the possibilities of decentralized app development with Ethereum. Check it out!

Demystifying High Frequency Trading

Demystifying High Frequency Trading

I recently came upon this great article by Rishi Narang of Telesis Capital exploring the popular misconceptions about high frequency trading (HFT), which has frequently come under fire in the media as being a root cause of the 2008 crisis and 2010 market flash crash. Proper education, documentation, and public awareness of the diverse roles different types of high frequency traders serve will only help investors as the financial field becomes increasingly automated. Seeing HFTs for what they are, as weapons in an overall investment arsenal (akin to algorithmic trading) will foster a better understanding of the market as merely a function of the people involved. Narang says the following, before separating truth and myth from HFT’s criticisms:

Capitalism is fundamentally about this: if you are willing to take some risk, you have a shot at reaping some reward. What would be unfair is if some people were being prevented from taking such risks and having such opportunities. And that’s assuming that we’re talking about something that is of unlimited supply. If supplies of resources are limited, then simply being late to the game is a sufficiently good reason to be very fairly left out of an opportunity. I’m not saying that there exist no facets of HFT that are unfair (very good arguments can and have been made about flash trading and naked sponsored access), but to label the activity in general as unfair is plainly wrong.

Check the full article out and tell me what you think.


This blog will be subject to the whims of whatever new technology or hobby I pick up. Expect some musings on web development/programming, cryptocurrency, finance/trading, music production, quantum computing, and more!