What we changed compared to ccminer and the other VerusHash miners, which processors it runs on, how much faster it got and what's coming next.
Numbers from real devices and correctness tests, not marketing estimates. The gain on phones depends on the core — simpler processors gain more.
Bellga took the best of each project — ccminer's algorithm, XMRig's framework, the NEON idea from Oink's fork and VerusMiner's core catalog — and fixed what was wrong in each one.
The VerusHash 2.2 core came from monkins1010's ccminer (the leanest version, v2.2 only). Around it, everything mature XMRig already had: huge pages, thread affinity, TLS, automatic pool failover, HTTP API and JSON config. The Stratum client speaks VerusCoin's specific dialect.
ccminer decides it found a share by looking only at the top 32 bits of the hash. When the pool difficulty goes up, it starts sending shares that do not meet the target — by our math, rejects can approach half at high difficulty. Bellga compares 64 bits against the exact target the pool sent.
On ARM64 with the crypto extension, the heaviest part of the hash uses native instructions (PMULL, AESE, SQRDMULH) instead of translating PC instructions. The idea came from Oink70's ccminer fork — but it had two bugs: ~0.3% of hashes came out wrong (write order in the table) and a rare saturation case gave a different result. We rewrote it from the official algorithm, with both fixed, without losing speed.
The previous version checked, on every hash, whether the pool job had changed — a 1,472-byte comparison that cost ~14% of the time. Now the miner only recomputes when new work arrives.
VerusHash changes an 8.8 KB table on every hash and has to undo that before the next one. Instead of recording and undoing each change, Bellga keeps an intact copy of the table per thread and restores from it — and the loop was reorganized so the compiler doesn't re-read memory for nothing. This is what put Bellga ahead of Oink's fork.
On phones, the install script reads /proc/cpuinfo, finds out which core you have and compiles with the right tuning for it (-mcpu). We use the 53 profiles published by VerusMiner (pangz-lab) as a reference — see the full list.
Many cheap phones run a 32-bit system, with no hardware AES/PMULL. We fixed the 64-bit types in the hash code, the memory alignment that crashed the miner with Bus error on newer clang, and a bug in the NEON HTTP parser that cut off data sent to the site. Validated on a Moto E7 Power through UserLAnd.
Fixed dashboard in the terminal, optional benchmark submission, machines linked to your account (profile, ranking and the "My machines" app) and a donation that goes to our pool in the same coin you are mining.
The 53 ARM core profiles VerusMiner uses in its builds (version 6.0.0), where each one shows up and whether our script recognizes it on its own. A phone usually has two or three core types; the script picks the biggest.
termux-build.sh detects and applies it on its own manual has its own tuning, but you tell it the core generic no reliable tuning — uses the generic buildIn Termux or UserLAnd, this command shows the device's cores. The install script does the same reading and writes the chosen profile to the log (Detected CPU: … -> tier 'ca53').
If it guesses wrong, or if your core is listed as manual, tell it when compiling:
Next steps for the miner and the site. "Testing" already exists and is being validated; "planned" has not started yet.
ca53, ca55, ca78…), like VerusMiner does — no compiling on the phonealgo-perfsuporte@bellga.tech