A 2012 Raspberry Pi Learns to Mine Verus

A single core at 700 MHz, 512 MB of RAM, and not an AES-NI or NEON instruction anywhere on the die. This is the story of pushing a modern cryptocurrency miner onto the oldest computer in the house, and of everything that had to be relearned by hand along the way.

The subject of this article is a Raspberry Pi 1 Model B Rev 2 from 2012, a BloxMiner fork rewritten in plain C, and a month spent finding out exactly what 5 kilohashes per second is worth. The real subject, though, is what happens when the hardware refuses every shortcut: the work stops being about speed and becomes about understanding the algorithm, the compiler, and the gap between a benchmark and a machine that has to run unattended for weeks.

1. The Machine Nobody Mines On

The Pi 1 Model B Rev 2 is a small piece of history sitting on a shelf. Its BCM2835 chip carries a single ARM1176JZF-S core clocked at 700 MHz, placing it in the armv6l family, three instruction set generations behind anything a modern miner assumes it has. It carries 512 MB of RAM, a 100 Mbit ethernet port, USB 2.0, and a total power draw under load of about 5 W, less than a graphics card spends idling.

What makes it interesting is precisely that nothing about it is interesting. Every miner guide assumes AES-NI on x86 or NEON on ARMv7 and above, the hardware paths that accelerate the hash functions Verus depends on. The Pi 1 has neither. It has a floating point unit, a small cache, and nothing else. Either the hash core could be rewritten in portable C and still produce identical output, or the whole idea was dead on arrival; there was no compiler flag that was going to save it.

2. Why Verus, and Why It Does Not Forgive Weak Hardware

Verus is a proof of work coin built around VerusHash 2.2, which combines Haraka, a fast short input hash, with CLHash, a carry-less multiply construction. On modern hardware both halves lean on dedicated instructions, which is exactly why the chain runs fast on current chips and locks out anything older.

That dependence means a miner cannot simply be recompiled for weaker silicon. The acceleration is not a layer sitting on top of the algorithm, it is stitched into how the code computes the hash. Take away AES-NI and the AES rounds inside Haraka have to be written out as table lookups and byte arithmetic. Take away NEON and the carry-less multiplication has to be expressed without vector instructions at all. None of it is glamorous, and none of it is fast; a single misread bit position produces output that looks entirely plausible and is entirely wrong.

3. Forking BloxMiner and the Pointer That Broke the Build

The starting point was BloxMiner, an open source Verus miner released under the MIT licence and marked beta by its author: small enough to read closely, structured well enough to patch. I forked it locally and tried building it unmodified first, which is where the first surprise was waiting.

A clean clone did not compile. The build failed on a pointer named g_miner that the source referenced but never declared, which suggests the published tree had been building against something that never made it into the commit. It is a common enough accident in a beta project, and the fix was a one line declaration, but it set the tone for everything after: a repository that will not build from scratch has never really been verified by anyone but its author, so from here on nothing was trusted just because it compiled. Everything got checked against a known good implementation instead.

4. Porting the Hash Core to Plain C

The portable work lives in four files, about 2,400 lines in total. Haraka became plain C using byte level operations in place of the AES instructions it was designed around. CLHash was rewritten without vector intrinsics, which is the hardest part of the job, since carry-less multiplication is precisely the operation vector hardware exists to do. A small shim header stands in for the SIMD types the original code expects, so nothing above the hash core had to change.

That boundary was deliberate: the rest of the miner does not know or care how the hash gets computed, and keeping it that way kept the patch small. Verification, by contrast, was not allowed to be small. The portable implementation ran against the original SIMD version on 67 test vectors, and every output had to match bit for bit, not approximately, not within tolerance. A hash function has no grey area, and any mismatch meant returning to the byte arithmetic to find the wrong shift.

5. Two Bugs Found by Reading, Not by Guessing

Two real bugs turned up in the portable CLHash code, and both are worth naming because they are exactly the kind a test suite tends to wave through. The first was a local variable named rc that shadowed the round constant table Haraka relies on. The name was reasonable on its own, which is precisely why it survived review while quietly replacing a table lookup with something else entirely.

The second was the missing sv2_2_full variant in the nonce path: the original code specialised the hash depending on how the input was assembled, and that specialisation got lost somewhere in the rewrite. It only surfaced on specific nonce lengths, correct almost everywhere and wrong at the edges, which is the worst kind of bug to chase. Both were caught by reading the portable code against the reference implementation line by line, not by throwing more test inputs at it. On hardware too slow to run a million experiments, careful reading beats brute force every time.

6. Building on ARMv6: Optimisation, Atomics, and Patience

Building on the Pi itself is where the constraints stop being theoretical. The first rule is -O1, not -O2 or -O3: on a board with 512 MB of RAM, an aggressive optimiser run in parallel exhausts memory and gets killed mid compilation. A slow build that finishes beats a fast one that does not.

The second rule concerns atomics. ARMv6 has no 64 bit atomic instructions in hardware, so the linker needs libatomic, and the detail that costs an afternoon is ordering: libatomic has to appear after the object files on the link line, or the result is undefined references to compiler builtins that look like a missing library when the real problem is sequence. A third rule, worth knowing even off this hardware, applies on x86: machines without AVX-512 need an explicit flag to disable those code paths, or the binary compiles cleanly, starts, and dies on the first hash with an illegal instruction. A successful compile, it turns out, proves almost nothing.

7. Running It as a Service, and What the Numbers Look Like

The miner runs as a systemd unit with automatic restart, so the Pi resumes mining on its own after a power cut, with one pool, one worker, one thread, and the local HTTP API turned off since nothing needs it open. It runs under a low CPU scheduling policy, because a single core board is no place to be greedy with itself. The measured output settles at about 5.2 kilohashes per second at roughly 50 degrees Celsius, drawing a bit under 5 W. A single core of a modern desktop CPU manages around 1.1 megahashes per second by comparison, which puts the Pi at about 200 times slower than one core of a laptop doing the same job.

The pool supplies its own arithmetic on top of that. The minimum share difficulty on the standard endpoint is 0.015625, which at this hashrate works out to roughly one share every three and a half hours, and the pool disconnects any client that has not submitted a share within twenty minutes; the reconnect was observed happening at twenty minutes and one second, a small but satisfying confirmation that the protocol behaves exactly as documented. One share landed at 07:26:37, and the pool dropped the connection 57 milliseconds later while it was still in flight. That timestamp is the whole story of small scale mining in miniature: the work happened, the credit mostly did not, and the machine kept going anyway.

8. Take It and Run It

The archive holds the patched source tree, a prebuilt ARMv6 binary, a build script, and a systemd unit file, and it has been checked for secrets, of which there are none: no password, no API key, no wallet private key. A mining wallet only ever needs a public address, and the sample commands use a placeholder rather than a real one.

Download: verus-miner-rpi-armv6.zip (371 KB, 45 files, sha256 48b85cfa...1582ae7)

The honest conclusion is that this earns next to nothing. A 2012 single core board will not pay for its own electricity against a network measured in hundreds of gigahashes, and anyone here for profit should stop reading now. What it does have is a different kind of value: a machine nobody expected anything from, doing something nobody designed it to do, running a hash core understood down to the byte because there was no other option. I am Peter, this runs on my own hardware in my own house, and I will say plainly that Claude Code and DeepSeek were both part of the work, not decoration; one wrote and refactored large stretches of the portable code and the build plumbing, the other handled research, verification, and documentation, and I set the direction, picked the hardware, and made the calls on what got verified and what got shipped. The old Pi in the corner is the proof that the combination goes further than either half would alone.

Tags

#technology #engineering