A few months ago we announced our public minining pool for TurtleCoin that runs on OrangePi One Plus.
As this project was not enough, we stepped up to the challenge and recently set up a new pool for another privacy coin project in which we are involved – DeroGold.
Doing a pool for DeroGold is a bigger challenge. Why? One of the main reasons for that is DeroGold at the time of writing has 20 seconds block time. Keeping up your nodes synced with blockchain could be a challenge, and on a lower spec hardware you need to understand what you’re doing, as well as be able to do some basic performance troubleshooting & tuning.
It took us a few weeks to come up with a concept of building a really sturdy and reliable cluster of nodes to serve our DeroGold mining pool fast and reliable. We use haproxy loadbalancer to actively load balance between DeroGold nodes, and monit to monitor and recycle stuck or crashed daemons.
Unlike the architecture for the TurtleCoin pool where we put all components (nodejs pool, payment gateway and the TurtleCoin node itself) onto a single board deliberately, we decided to split components across multiple board for DeroGold.
As we mentioned earlier, reason we went for a distributed configuration was mainly because DeroGold has 10 seconds faster blocks when compared with TurtleCoin (30 seconds), as well as the number of transactions on the DeroGold network seems to be fairly heavy (8.3m transactions since the network went live in December 2018, compared with 4.2m transactions in the TurtleCoin network since its go live in December 2017). Additionally, DeroGold’s blockchain size at the time of writing reached 136 GB (compared with TurtleCoin’s 75 GB).
We run the pool components on the OrangePi 3 with 2GB RAM, 8GB emmc storage for the OS (Ubuntu Server) and a 512 GB SSD drive connected via USB3-to-SATA3 interface. The pool web front-end is pointed to another SBC board (frontend) that NGINX reverse proxy with SSL; and served via another SBC board in the backend that runs Apache and serves the actual pool static html website. The pool API backend is hooked to the NGINX SSL reverse proxy as well.
The three nodes that serve the pool are as follows – one on the OrangePi One Plus, one on a self-hosted Intel i3 Fujitsu server, and one in a remote location (UK datacenter) VPS server.
How does the pool run? Very well in our view. You can give it a go yourself by pointing your favorite miner (has to support cryptonight-turtle algo) to:
You can access the front-end of the Cuvée DeroGold pool in the following website:
There is no attack in a decentralized privacy network. It’s just either regular transactions or fusion transactions.
Of course, there could be elements and individuals who would deliberately perform such activities that would cause some degree of a trouble for a young distributed, decentralized network that consists mostly from unmanaged low powerfull nodes.
And that was exactly what happened to DeroGold a few months ago. One day we woke up in the night looking at network & node monitor. Hash rate down, pools mostly not operating, alternate chains on the network, only about a 4-5 nodes respoding and keeping up.
If you face a situation like this, the human factor hits in. There would be splitting into more or less two dominant groups – the first group who would claim the only way from a bad scenario as the above is more control, centralization; and there would say let’s cope with this.
The author of this post is biased believer in decentralization, geo-distribution and lowest amount of hand-holding and controlling. So we said well, let’s take this as a free stress test. What if our network grows so much over the next few years that we will have to cope with 60k+ transactions on a daily basis?
We had investigate. Why is the software part, largely sitting and waiting on the powerful hardware (we run xeon and i7 servers with 32+ GB of RAM on SSDs to support a few networks / nodes)?
The answer was in how the daemon uses the database. Historically, as DeroGold is a fork of TurtleCoin, and TurtleCoin historically a fork of Bytecoin, there seems to have never been done any optimization on the use of read / write buffers to Rocksdb (which is a high-performance scalable database developed by Facebook) which both DeroGold and TurtleCoin use.
At some point during the events, we discussed with @sniperviperman#2620 whose nodes were keeping up that he increases the buffers significantly. That sounded like a part of the key to optimization. The defaults in the original code were set to size of tens & low hundreds of megabytes for read/write buffers respectively, and the number of db threads to 4. That could work for a network with here and there a few transactions per minute.
For a DeroGold network, with 20 seconds block time, and at the time of events a range of 400 – 500 transations per block, this cannot be enough. Symptoms? The node stops responding to RPC calls first, then fails to keep up with the chain (high I/O), CPU largely sitting idle.
We tested various settings and for our 32GB server we set both DB read and write buffers to 8092 MB. We tried different settings for number of DB threads, and finally found one that worked well – 10 DB threads.
With this, it was also necessary to lift the Linux limits on the number of open files.
Those settings unclogged the daemon to be able to start processing transactions and resynchronize with the chain.
Subsequently after these events, we added the increased DB buffers & threads to our default config file, and also submitted Pull Request to both DeroGold and TurtleCoin code that changed the default settings to values that are more corresponding to nowadays hardware and match the requirements of operating a 24x7x365 privacy coin.
Bottom line: The new defaults may not work for small home node / unmanaged node operators. Some of them did not actually like the change, seeing the requirements as too high. It is fine. Everyone can scale back those default settings. However, we have to set the default vauleus to the minimum requirements of each of the network to ensure stable and continuous 24×7 operations. When a peak hits the network it will be the strongest nodes that will have to keep up and ensure availability of the network.
Donate 100 TRTL, powered by TurtlePay and TurtleButton:
In the earlier post, I promised to share with you how we tried to bring the OrangePI One Plus board down with lots of TurtleCoin Pool hash rate.
This test was triggered by two factors.
The first factor was my own curiosity. I had a conservative guess on how much hash rate a single board computer could potentially sustain. I wanted to test my theory.
The second factor was a few remarks in our lovely TurtleCoin community. “Ahh, so you will be the new kind of pool operators. Look, my seventh miner connected, we reached 7kh/s hash rate, pool is crashing”. If you know the potential of ARM-based single-board computers nowadays, you want to show to the world how wrong such view is 🙂
It was a lovely early evening mid-of April when I announced on the TurtleCoin Discord, okey, bring the pool down. I pay out everyone 10K TRTL who participates in the mining tonight and floods us with some serious hash rate.
As you can see in the screenshot below, our community was up for this challenge and soon we reached 1.9 MH/s on the cryptonight-turtle algo.
You read well, it is not a typo. We reached 1.9 MH/s. The board was still performing well. One of our fellow miners and friend who provided 99% of this hash rate kept us flooded for almost 14 hours.
As you can see in the pool frontend (as well as in the following screenshot), that day (16th April) the pool mined at the 1.8 – 1.9 MH/s hash rate 13 blocks in 14 hours, almost 1 block per hour.
More importantly, not a single block orphaned. This result exceeded all of our expectations. Why?
In order to make it very hard for the SBC to cope with this much hash rate, we decided to install and run all components on one board: the TurtleCoin node itself, the pool software consisting of payment, api, pool and stats workers, and the Redis DB.
The only component we hosted on a separate hardware was the actual HTML site for the pool front-end (however, the statistics were still provided by the API provided by the SBC).
The CPU cores oscilated on average between 30-40%. The main load was caused by the TurtleCoin daemon itself, not by the hashing load sent by the miners to the pool.
You can see stats from the HTOP in the screenshot above. Please note the Load Average in the top right shows wrong values, the bars indicators and CPU / MEM percentages in the left pane are correct. This was a known bug in the OrangePI Ubuntu build at the time we performed this test and was fixed in the later builds.
How did the board do in our view compared to our expectations?
First, we did not expect the board to be able to cope with almost 2 MH/s hash rate. We have estimated the tipping point around 1 – 1.1 MH/s. This was a guess, and it was a pretty bad one.
Second, despite the board coping so well with this much hash rate, we expected it to crash after a few minutes up to an hour. This has not happened. In fact, the board never crashed during the test, no blocks orphaned, and the uptime of the pool as of today is:
21:00:54 up 111 days
As @thinkpol summarized it in the Discord chat: “You achieved everything with this test, except for one thing – you did not manage to bring the board down.”
This kind of summarizes for us the potential, the stability and sturdiness of ARM-based single board computers. These do have a proven place in blockchain, crypto and mining applications and our test proved exactly that.
We want to hear from you! Did you took an SBC even further in torturing it in the crypto world? We are curious, let us know please!
Donate 100 TRTL, powered by TurtlePay and TurtleButton:
This post was originally published on DeroGold Medium. It caught our attention, as the announcement is crypto related, concerns ARM devices (most of mobile devices run a flavour of ARM chip) and it pushes the boundaries!
Mine2Gether came up with an Android miner for cryptonight-turtle algo, which allows you to mine number of coins, such as DeroGold, TurtleCoin or WRKZ (not a comprehensive list) on Android
We are aware that there are many of you here running an Androind on your SBCs. If you consider mining on your SBC, now you have a native mining app. Up until now the only solution was to run miners such as xmrig in Termux on Android. This solution was far from ideal.
Over the past months, we did set up miners and nodes on ARM-based SBCs, namely on OragnePIs and Rock64s.
All these piecese were leading to one thing – it was time to get shit done. Beginning of March, we decided to take the plastic-card size OrangePI One Plus on a trip no one ever took it before.
We decided to set up a public mining pool for TurtleCoin on an Orange PI.
In this post, we will keep it factual and will share with you what you need to get this experiment done.
Please note that in order to make this work and succeed, you need to have a good knowledge on how SBCs work, how Linux works, advanced literacy in using command line, in-depth knowledge on how TurtleCoin (or in general how cryptonight-based privacy coins work), what is a node, what is a miner, how to configure a miner and what is a mining pool and how to configure one. If you are a beginner, this may not be the best entry point for you to try. This is why we don’t cover any detailed steps in this post.
What hardware ingrediences you need for this?
OrangePI One Plus (obviously)
microSD card to boot & run the system from
128+GB SSD drive for blockchain data
Power supply (5V 2-3A) with a microUSB connector for the boards USB OTG
Heatsink for the board’s H6 chip
A fan blowing at the board exchanging air
We wanted to do this as an experiment for potentially bringing the board down. So we made the following design choices (flaws):
We will put all the software components to just one board
The TurtleCoin node + blockchain
The TurtleCoin Pool Software, with all its components
The exceptions is the pool front-end website, which will be hosted separately
For installation and configuration, first you install you favourite version of the the available Linux OS. Once up and running and on the network, you follow the guidelines to install the the TurtleCoin node (daemon) and fully synchronize it (or use a local backup copy if you have another synced node available). Then install nodejs/npm. NodeSource have the latest builds for aarch64 platform available.
In the next post, we will share how we performed the stress test on our PI-based pool, we will reveal if we managed to get the hardware crashing burning and share some statistitcs on how the pool is doing so far.
On the feature image, the actual one that runs the pool is the top one right.
Donate 100 TRTL, powered by TurtlePay and TurtleButton:
Today, you can read how to set up your own at home.
First, you need a suitable single-board ARM computer. Yes, you can use 64 Raspberry PI 3b(+), and we know these are quite popular among you folks. However, it is not the most suitable hardware.
We run DeroGold and TurtleCoin public nodes on a Rock64 4GB and on an OrangePI 3 boards respectively.
Apart from a suitable board, you will need a good-quality, fast and reliable USB FlashDrive, such as SanDisk Ultra Fit USB 3.1 Flash Drive. We use the 128 GB version that gives us enough breathing room for the coin blockchain to grow.
For both boards, grab the Linux OS of your choice. We recommend to either use Armbian, or in case of OrangePI you can grab the legacy-kernel Ubuntu Server 16.04 supplied by the manufacturer of these boards.
Once you have your OS flashed to a microSD card or emmc (both boards come optionally with EMMC storage, which we recommed you to use for long-term, production use) and your board booted up and networking set up, start with updating the system:
sudo apt update
sudo apt upgrade
Create a partition and file system on your 128GB USB Flash Drive. Find out the device name /dev/sdX, use fdisk to create a new partition and create a new file system.
In our case the device name is /dev/sda, we will create a /dev/sda1 primary partition on it.
Now we will create the file system.
mke2fs -t ext4 -O ^has_journal /dev/sda1
We will add the new file system to /etc/fstab to mount at each boot of your node. First we will find out the UUID of the /dev/sda1 device.
Our partition has the UUID 57f8f4bc-abf4-655f-bf67-946fc0f9f25b. We will use it to mount in the /etc/fstab
Mount the file system before using of course.
mount /dev/sda1 /root/.TurtleCoin
Now that we have the storage ready for TurtleCoin blockchain, we will download the latest release of the TurtleCoin daemon for aarch64 platform. You can download the latest release from TurtleCoin Github. To download the file directly to your directory, use wget.
Run the daemon for the first time, load checkpoints for faster blockchain sync. This step could take very long when done from scratch, at the time of writing, TurtleCoin blockchain height (block number) is 1447359. Depending on your internet connection, this could take 1-3 days.
Please note in the command below, we set the TurtleCoin log file location from the default TurtleCoin working directory to the directory where we store blockchain on the USB FlashDrive. It is not necessary to do this if you use EMMC storage to run your operating system, however, if you use microSD card, this is highly adviseable to prevent wearing out your microSD card over the next months you will run your node.
Alternatively, if you don’t want to wait for the blockchain sync from scratch, and in case you already run your node on your laptop or a computer, just copy the .TurtleCoin directory with the blockchain to the Flash Drive USB drive.
Once you have a fully synced blockchain, stop the TurtleCoin daemon by typing exit and wait for it to stop fully.
If you want to run you TurtleCoin node as a public node for serving other user’s wallets (and earning some extra TRTL in transaction fees), open the port 11898 on your firewall and start the TurtleCoin daemon with the following parameters. If you are on your home broadband and need to connect externally, you need to find out your external IP address. How to do this is out of scope of this article, and surely Google will help you.
In the example below, change the <your TRTL address> with your actual TurtleCoin wallet address to recieve TRTL and specify your desired transaction fee. In our example, we charge 19 TRTL fee (must be specified in TRTL atomic units, which is 2 decimal places, therefore 1900 shells = 19 TRTL)
When we started experimenting with the ARM-based SBCs, such as Pine/Rok64, OrangePI, BananaPI, Odroid boxes and many other boards, we had an ultimate dream.
How good it would be to run a TurtleCoin node on a small, energy-efficient harware. How cool it would be to expand this to literally any other cryptonight-based coin?
The inspiration came to us from CASA, who do RaspberryPI-based node for Bitcoin.
However, at the time of our first experiments around June 2018, TurtleCoin and any other cryptonight-based privacy coins would segfault on a aarch64 ARM platform. According to our tests on OrangePI One Plus and Rock64 boards, this was including Monero, however, Monero guys at the time of experimenting and debugging in January 2019 would deny it.
The problem, in short, was in slow-hash part of the code and the scartchpad size. The scrachpad size is bigger in most cryptonight variants compared to the size of L1/L2 cache. The scratchpad would not fit to the cache and hence segfault. The trick was to add FORCE_USE_HEAP to the preprocessor, so that the slow-hash routines would run properly on ARM architecture.
This post is a short follow up to our previous article on mining cryptonight-turtle algo coins with SBCs (OrangePI One Plus).
The good news is yes, if you have got a Raspberry 3B(+), you can mine TurtleCoin (or other coins based on the cryptonight-turtle algo, as well as other cryptonight variants) on your Raspberry 3B (or 3B+).
Note however, that just because you can do this, it may not be the most efficient thing to do. Additionally, we are famously known for not doing anything with Raspberries. There are better boards, fully Open Sourced. We discussed this in our other post. If you still want to do it, just follow our tips here.
Firstly, you will need a full 64-bit system. Many folks contacted me on Discord quite a few times asking me why xmrig binaries from your github repo fork do not work.
It is most likely your system is not full 64-bit – it has loaded a 64bit kernel, but uses 32bit user space. How to find out that this is the problem you have? On your command prompt do
If it returns anything similar to the following, stop right here.
/bin/bash: ELF 32-bit LSB executable, ARM, EABI5 version 1
Head over the to get a full 64bit system for your Raspberry. There are number of options, at the time of writing we knew at least about the following:
We have heard this question quite frequently on TurtleCoin Discord chat. This is our initial guide to give you a head start on sustainable, best performing SBC mining, focused on OrangePI One Plus board. This board is at the time of writing this post most likely the most efficient hardware to mine on.
Overview and background
A bit of a background on where and when we started at Cuvée with this project. We have first explored the topic of mining on an SBC around December 2017. TurtleCoin was very new back then, so we tried mining Bytecoin and Monero first. It worked. However, with these coins focus and philosophy, this undertaking was only good for a thought experiment.
Over the course of time, we have evaluated many SBC Boards for mining (and other purposes), including (not a comprehensive list):
OrangePI PC (H3)
Orange PI Zero Plus (H5)
Orange PI One Plus (H6)
Orange PI 3 (H6)
We have heard from other community memebers on TurtleCoin Discord to test Raspberry PI 3b+ and Nvidia Jetson Nano (both tested and xmrig mining software adapted by @thinkpol). We believe the Nvidia Jetson Nano could be a hidden gem, we will cover this in a separate blog post.
Out of all the tests with mining throughout TurtleCoin (and other coins) algorithms, the Orange PI One Plus stands out (at the time of writing) as a clear winner. We recommend you start your journey with this board.
Why? At the current TurtleCoin algo (crytponight-turtle), you can achiveve around 600 – 700 hashes per second (h/s). Some community members took it to the extreme and achieve consistently 750 h/s. Simple maths. If you buy 10 boards, these will give you anything between 6 – 7.5 kh/s at a power consumption of about 50 watts.
Preparing your set up
There are number of things you will need if you take mining with OrangePI One Plus seriously. In order to be effective with it, you will need more than one board. We will losely describe our first set up we did with 10 boards.
For you to get started, you will need the following:
Orange PI One plus in the required quatity (ideally to start with 10x)
16-port (at least) Ethernet Gigabit Switch
Power cables for Orange PI One Plus (either USB to microUSB, or USB to barrel plug of the required specification)
USB Power Adapters or Charging USB Hub (2x 5-port with output of 2A per 5V port at least)
microSD cards (8GB or 16GB whichever you can get cheaper, no need to go for more storage for mining)
Heat sinks for the H6 chip on the OrangePI
Spacers to mount the OrangePI Boards together (2×5 tower set up)
80 – 100mm 12V fans (2x) with USB plugs to ensure airflow between the boards
Internet connection / home broadband router to connect the Gigabit Switch for your boards
That’s it for the list of hardware. At the bottom of this blog post, we show you examples and links for the components we use.
Mostly, we order from AliExpress. Over the 3 years of sourcing in China, we developed a network of trusted producers, suppliers and resellers that we never encountered any problem with. Going forward, we will open our own e-shop with all the required components to server UK, EU (and possibly US/Canada) customers. We keep you updated on this.
Once you have all ready, just do the following steps:
Put heatsinks to the H6 chip on your OrangePI One Plus boards
Mount them together to 2×5 towers using spacers
Connect your gigabit ethernet switch to your home broadband switch
Connect all the OrangePI One Plus boards with the gigabit ethernet switch
Plug all the microUSB or barrel plug power cables to the boards
Mount (glue) your fans to the side of each tower
Plug your Charging USB hubs to the power
Do not power up the boards yet
Setting it all up – getting the board running
Now that you have your components in place, it is time for us to start the real work.
Take out your microSD cards. Get your favourite OS for the OrangePI One Plus board. At the time of writing, there are two images available:
While the Armbian will be a great choice when Mainline kernel support for the Allwinner H6 chip is ready, for the purpose of mining, the official OrangePI Ubuntu 16.04 BETA with legacy kernel does a good job as well.
Download the image and write it to the microSD card using your favourite tool. For the UNIX hard liners, there is no better tool than DD, for everyone else, tools such as Etcher will do just fine.
Once you have the OS image ready, insert the microSD to your Orange PI One Plus boards and power them up.
Shortly, these should be up and running. If your home / work environment allows for DHCP, all the boards should have obtained a DHCP address.
Please note the OrangePI One Plus boards come all with same MAC address from the factory. You need to assign each board a different MAC address. In produtions versions, Armbian does this for you at the boot time. All other systems, either modify the boot enviroment (outside of scope of this article), or fire these boards one by one and edit the /etc/network/interfaces.d/eth0 file and add:
hwaddress ether 00:01:04:1b:2C:1F
The MAC address above is only an example. Pick your own. Different one for each board.
If you need to set up static addresses, there are lots of examples on how to do this for a Ubuntu/Debian-like systems, just google it.
With the MAC addresses and networking sorted, you should be in the position to connect to your boards via ssh now.
For Armbian, the default login is root / 1234, for OrangePI Ubuntu, the default login is root / orangepi.
We cannot stress more the importance to change those default passwords at the first login.
Installing & running the xmrig miner
With you now possibly logged in to the system, we will now install and configure your miner from scratch.
First, update your system.
sudo apt update
sudo apt upgrade
Second, prepare your system to compile xmrig using GCC-8 / g++-8 and install other build pre-requisites.
This should compile your xmrig binary in the xmrig/build directory.
In most cases, there is no need to add any extra flags for CMAKE. At least we did not need to do this for our 50+ OrangePI boards we set up at the time of writing. Some community members will swear use this or that and you gain extra few hashes. We leave up to you to experiment.
In our experience, all the SBCs we tested (see the list above in Overview section of this post), this generic step by step guide works all boards we tested. This is however, not true for Raspberry PIs. Look elsewhere for Raspberry PI guides – main caviat being you need a true 64bit system for a Raspbperry board – some of the systems have 64bit kernel, but not the user space. In our view, as much we admire these boards for education purpose, we do not use them for our own or customer projects. And we definitely do not recommend any Raspberry for mining.
Now, we will run your miner for the first time. Go the the $HOME/xmrig/build directory and run the following command:
Well back in 2015, we started experimenting with Single Board Computers based on the ARM architecture. We were evaluating multiple use case scenarios: TV iPlayers, Video streaming, Distributed Storage clusters, IoT Sensors applications, managing production lines and many more.
It wasn’t until about end of 2017 when an idea of exploring the possibilities of those boards in the Crypto World. Over the past 1.5 years, we tortured these boards as miners, TurtleCoin (and a few other coins) public and private nodes and recently even a TurtleCoin mining pool.
We have gained plenty of experience from these Proof of Concepts, many resulted in very positive and surprising results.
We took these boards in the crypto world probably as far as no-one other did until now. Here in this place, we will share with you our knowledge: what we did, what we used, what worked, what did not.
How far we take this new site remains to be seen. There are a few ideas around providing SBCs as a service (the new fancy word for hosting) for your projects, whatever these might be. We will definitely try to push SBC boards as far in the crypto use cases as we can, predominantly based on TurtleCoin, which we consider our friendly home 🙂
We believe the future of the computing is small computing units, distributed. Forget big datacenters, hyperconverged and all that nonsense.