I Went Mining for Monacoin and Came Back a Space Heater
Hello, hello! Detective Bit-Taro Nyan here.
It has been hot ever since August started. And in the middle of that, I was trying to run a kilowatt-class heat source in my room, which made it hotter still 😇
Right, let’s get into it.
Monacoin. I saw the name again after a long while, and it turned out the chain was close to stopping.
The chain had stopped#
It started with a notice from bitFlyer. As of early afternoon on August 4th, they had confirmed that no blocks were being produced on the Monacoin network, so MONA deposits and withdrawals were suspended※1.
I looked into it, and here is what had happened.
For about two years, Monacoin’s hashrate had been almost entirely a single pool called M2pool. That pool stopped, dead, at noon on August 4th. The network’s computing power fell by two orders of magnitude※2.
The awkward part is the difficulty. Proof-of-work difficulty is adjusted every time a block is found, which means if no blocks come out, the difficulty doesn’t come down either. The hashrate vanished and the difficulty was left standing where it was. Blocks that should arrive every ninety seconds weren’t arriving for hours.
So the difficulty was pinned orders of magnitude above where it belonged.
Looking at that, what I thought was very simple. Maybe right now, even my single GPU can compete.
Like fishing in a pond the ASICs had all left. I genuinely believed that, more or less. Let’s give it a go.
Building an eight-year-old miner with today’s CUDA#
Monacoin’s algorithm is called Lyra2REv2, and for GPU mining the software is effectively ccminer and nothing else. The thing is, its README still recommends CUDA 6.5 — a 2014 release. My machine is, naturally, not running anything that old.
Sure enough, it didn’t build. It trips over two APIs that current CUDA has removed.
The first is the non-sync warp shuffle. It’s the instruction threads inside the GPU use to pass values to each other, and the old spelling of it is gone. There were a great many of them left across the code, including inside the kernels Monacoin actually uses.
The second is the legacy texture reference API. This one was used by a dozen-odd files. Fortunately every one of them belonged to other algorithms with nothing to do with Monacoin, so I escaped by wedging in stubs that compile but don’t work.
For both I wrote compatibility shims and force-injected them into every file. It was genuinely tiring, but the fourth build went through.
What worried me here is the scariest failure mode in this kind of port: it builds, and then quietly emits wrong hashes. Rewriting warp shuffles is especially good at causing that. It looks like it’s running while computing nothing but garbage.
I checked this three ways. ccminer itself can verify the GPU’s results on the CPU, so I used that, and then I connected to real pools and confirmed shares were accepted — on two different pools. Zero mismatches on the CPU check, and the only rejects were a handful right after startup. Good enough, I think.
I measured it, and nobody’s numbers were measured the same way#
It worked, so I measured it.
Then I went looking for something to compare against. There is something. A list with ASICs, FPGAs and GPUs side by side is published, and my GPU is on it※3.
Except it’s unusable. There’s one data point per model, and the power settings behind them are all over the place. One model at stock, the model next to it power-limited. Put those two side by side and say “this one is more efficient” and you can’t tell whether you’re seeing the hardware or the setting.
Sweep the power on one single GPU and that becomes obvious※4. Changing nothing but the setting moved efficiency by a factor of 1.5. The gap between settings is bigger than the gap between models.
So I went looking for a comparison that states its conditions, and arrived at a 2019 paper about an FPGA Lyra2REv2 miner※5.
One adjustment worked beautifully here. Cut the power limit. The hashrate mostly stays while power drops by nearly half. Energy efficiency improved a lot※4.
Measured in that state, I was more efficient than the paper’s GPU.
Which isn’t to say my GPU is anything special. Someone else is power-limiting a GPU one generation newer in the same way, and their number is nearly twice as efficient as mine※6. Better than any GPU on the list. One generation of difference does that.
The paper concludes that its proposed FPGA is overwhelmingly more efficient than a GPU, and measuring again on a current GPU, that gap had narrowed considerably. Hardware generations and compiler progress had aged the paper’s GPU baseline, not its FPGA.
I’m not trying to pick a fight with the paper — as of 2019 it is entirely correct. What I enjoyed is seeing the ordinary fact that seven years changes the premises, in numbers 🤔
Lyra2 wasn’t the main act#
By the way, I’ve been saying Lyra2REv2 this whole time. That name is a little false advertising.
Lyra2REv2 is seven hash functions strung together in a chain. I broke the cost of each one apart on the CPU and measured them, and CubeHash accounted for three quarters of the whole thing※7. Lyra2, the one in the name, is a little over a tenth.
And when you look at the hardware clock cycle counts in that FPGA paper, CubeHash takes about the same share there too. Two completely different platforms, CPU and FPGA, arriving at the same conclusion independently.
This matters more than it looks. The reason Lyra2REv2 was said to be “ASIC-resistant” is that the Lyra2 part is memory-hard — it uses a lot of memory, which makes it awkward to put in an ASIC. Except that Lyra2 is a small slice of the whole. The large remainder is CubeHash, which uses no memory at all and is a straight contest of arithmetic.
No wonder ASICs showed up.
Every optimization I thought of, lost#
Well then, just make that three quarters faster.
And the ccminer code for it was written in 2018, targeting the Maxwell generation. Surely there are eight years of headroom in there? You’d think so. I thought so.
I implemented everything I came up with, and measured everything I implemented. Fuse instructions to reduce their count. Merge kernels to remove the round trips of intermediate data. Put more threads on the GPU. Run several processes at once.
Lost every single one.※8
And the way I lost was clean each time, with a clear reason.
The instruction fusion was simply a case of the current GPU’s bit-rotation instruction being much faster than I imagined. I thought I was reducing instructions and I was adding them.
Kernel fusion is more interesting: the cost of the extra registers that fusion creates was higher than the round trip of writing intermediate data back to memory. The round trip was cheaper.
Which means the people who wrote ccminer knew what they were doing. Look closely and only the first two of the seven stages are fused. Those two have small state, so registers don’t swell. They had already sorted out where fusion helps and where it doesn’t.
My assumption — “old code, so there must be room” — was implemented five times and denied by measurement five times. Code from 2018 is still sitting at a local optimum on a current GPU.
I found that genuinely impressive, in its own way.
So who is mining?#
So who is actually mining right now?
I measured the computing power left on the network after M2pool disappeared※9, and divided it by the performance of the equipment. The answer is simple.
Eight Lyra2REv2 ASICs’ worth.
I didn’t count the units. The only ASIC in reasonable circulation for this algorithm is the FusionSilicon X1, so I assumed everything is that and divided※9.
Covering it with GPUs would take something like a thousand cards, and a thousand GPUs sitting on a coin whose 24-hour volume is a hundred thousand yen or so is hard to imagine. The pool only had a few dozen workers connected, and the computing power per worker was at a magnitude GPUs or CPUs can’t explain.
And right now, those ASICs are mining a few thousand yen worth of MONA per unit per day. The rewards are being split among very few people, so of course they are. At the same moment, my GPU was running at a loss.
Except this doesn’t turn into yen.
Since August 4th, when the chain stopped, the major exchanges have kept MONA deposits and withdrawals suspended※10. The order books are live, so MONA that was already on an exchange can be sold. But MONA mined outside can’t be brought in. It gets mined; the exit is closed.
And even after the exit opens, the place to sell isn’t large. Add up the 24-hour volume of four exchanges and it comes to 14,000 MONA — around ¥140,000※10. Meanwhile the network mines 6,000 MONA a day. Sell each day’s mining every day and that alone would be 40% of that day’s trading.
Those few thousand yen were the number you get when you walk straight past all of that.
Work out the energy efficiency you’d need to break even, and my GPU doesn’t come close. And that break-even point happens to sit at almost exactly the same level as the FPGA in that paper※11. Which means reproducing the paper’s FPGA perfectly would put you at exactly zero profit.
Except reproducing it is hard in the first place. The FPGA miners you can actually buy are nearly four times less efficient than the paper’s design※3. On paper they lose to a current GPU. The one in the paper was a lab design, not something on a shelf.
In the end the only thing that actually works is the ASIC. Between the top of the list and the best GPU there is still an order of magnitude※3.
I thought it was “a pond the ASICs had all left,” and there were eight units’ worth still in it, taking nearly all of it. There are a few dozen GPU-scale miners too, but all of them added together don’t reach one hundredth of the single largest one※9. I’m one of them.
Looking at the pool statistics published afterwards, I noticed one more thing. The single largest miner holds 70% of the network※9. I wrote at the top of this post that M2pool, one single pool, had almost all of it — the pool’s name changed, and the concentration itself hasn’t loosened at all.
I connected to the pool#
There was one more thing I wanted to check.
I’d seen it said somewhere that M2pool had ended support, but I couldn’t find any official announcement. If anything, M2pool’s site still lists Monacoin as a supported coin, and the connection instructions page is still alive※12.
So I connected to it.
It connected. Authentication passed, and work came down. And the work I was handed pointed at exactly the same tip of exactly the same chain another pool was handing out at the same moment. When a new block appeared it followed, and it even observed my computing power and adjusted the difficulty.
But so far all I’ve looked at is the side that hands out work. The body of a pool is what comes after that: receive shares, account for them, settle up. If there’s a reason large miners leave, it’s more likely on that side.
So I mined all night and looked at that too. I put a relay of my own making between the miner and the pool and recorded everything that actually crossed the wire. Miner logs only show what the miner believes, and from those alone you can’t tell “not submitted” from “not accepted”※13.
The result: every share I threw went through. Not one dropped, no delayed responses, stable until morning.
And then.
When morning came I opened the pool dashboard, and my miner wasn’t shown anywhere. Zero hashrate, zero earnings. It didn’t even appear in the list of miners by name. A whole night of submissions, every one answered with “accepted,” and nothing at all left on the account side.
A plausible explanation comes to mind here. This pool hasn’t found a single Monacoin block since that day. Given how rewards are distributed, no blocks means zero earnings, naturally. So maybe it just looks empty.
I checked. I mined a different coin on the same pool. Same pool, same miner, same GPU, same procedure. The only difference was the coin※14.
That one showed up immediately. Within tens of minutes, after a handful of accepted shares, the worker name, the hashrate and the last-submitted timestamp all lined up properly.
I checked from the other direction too, for good measure. I’d also mined all night on a different pool for Monacoin, so I went to look at that balance. The reward was there. A trivial amount, but as a number that exists※15.
So it isn’t the coin, and it isn’t my configuration. Only the combination “M2pool plus Monacoin” receives shares without recording them.
As a reason for large miners to leave, that is more than sufficient. Nobody runs a business mining on a pool that doesn’t record the shares you throw at it.
But I can’t state it as fact. There’s a problem of order left here. Before August 4th, that pool was gathering an enormous amount of computing power, finding blocks every few minutes, and calculating rewards accurately with fees included. It must have been working properly then. If it hadn’t been, that scale wouldn’t have stayed for two years.
Which leaves this. Did the accounting break and the large miners leave? Or did the large miners leave, and the accounting stop as a result of blocks not being found? The latter is perfectly possible. Statistics falling over on a pool nobody is mining is, if anything, a natural way to break.
From the outside, I couldn’t settle that order.
If anything, something even less steady turned up. I went to look at this pool’s announcements, and they had published an incident for a different coin in which “only the hashrate statistics and block statistics broke, with no effect on earnings”※16. Officially, in writing.
Which leaves open the possibility that the state I saw — shares accepted, nothing displayed — is a display problem only, with the accounting happening behind it. In which case it isn’t a reason large miners left at all.
That was my limit. I think I knocked on everything that can be knocked on from outside, but what is actually happening inside the pool, I still don’t know.
Afterword#
The chance did exist, I think. But the only ones who could take it were the ASICs that were already switched on.
If you’re procuring equipment now, it never reaches you. This is probably the blunt part of proof-of-work: when an opportunity arrives, the only people who can take it are the ones who have already placed their capital, and the people who noticed and started moving are structurally too late. Not much of a dream, I thought.
That said, this is less “because it’s PoW” and more a result of what Monacoin chose not to do. Lyra2REv2 was designed advertising ASIC resistance, ASICs appeared in 2018, and Vertcoin — which used the same algorithm — hard forked away to a different one at that point. Monacoin didn’t. Incidentally, the paper’s authors are fairly skeptical about this “ASIC resistance”: it could be maintained by raising the parameters, but at the current settings the memory matrix is very small and there is nothing to stop an ASIC or FPGA implementation. In other words, it could be maintained and isn’t. Less an unwinnable game than a game somebody walked away from.
Some coins are still fighting. Monero changes its algorithm every six months, and Vertcoin, from a moment ago, hard forked twice for ASIC resistance and still runs a GPU-oriented algorithm today. Running away is an option that genuinely exists.
I did find the one winning line, by the way. The electricity price that breaks even is well below a normal household rate※17. But mine in a room you’re already heating electrically in winter, and the heat is needed anyway, so the electricity can be counted as free. Self-consumed solar works out the same way.
So I’ve decided to let this one sit until winter. By then I imagine deposits will have reopened.
Come to think of it, why that hashrate vanished is still unknown. The pool kept handing out work. But the shares weren’t recorded. And even that observation, that they weren’t recorded, might be a display problem. The order, and the cause, weren’t visible from outside.
And I ran the same division on the side that vanished. It comes to more than 800 units. In power, about one small factory running※18.
That part is fine. The strange part was the income.
Monacoin today, adding up everything the entire network earns in a day, doesn’t come to much. Throw that whole amount at the electricity for 800-odd units and it isn’t enough. Estimate the electricity price down to a level you’d never find in Japan and it’s still not enough※18.
At last year’s prices it barely worked. Since the start of this year, it’s a loss however you compute it. And it kept running until summer anyway.
Someone was writing the same question two years ago: why was a hashrate so out of line with the price being maintained※19. There was a crash back then too. So this isn’t the first time.
Which means I may have been asking the wrong question. Not where did it go, but how was it able to exist at all. The economics don’t explain it. There’s no way to put it other than: somebody was running it without caring about the electricity bill.
Machines on that scale must be sitting somewhere. What are they doing now, I wonder. The moment they come back, the reign of those eight units and my winter arithmetic both end at once.
And now, a verse.
Call it a heater
and does it turn a profit?
a tropical night
And with that, I’ll take my leave.
※1 bitFlyer status (@bitFlyer_status), notice of August 4, 2026: “We have confirmed that no blocks have been generated on the Monacoin network since approximately 12:35 PM on Tuesday, August 4, 2026.”↩
※2 M2pool’s last block was 4,069,323 (August 4, 2026, 12:35:46 JST), matching bitFlyer’s “approximately 12:35 PM.” The next block, 4,069,324, came the following day at 08:20:33 — a gap of 19 hours 45 minutes. Difficulty at that point was 226,348 (consistent across three sources: on-chain, M2pool, and miningpoolstats). The network as a whole fell from the 10.5 TH/s range to the 100 GH/s range.↩
※3 minerstat’s Lyra2REv2 hardware list, 46 models of ASIC, FPGA and GPU (as of August 7, 2026). Sorted by energy efficiency: FusionSilicon X1 at 0.085 μJ/Hash, Dayun Zig Z1 Pro at 0.115, ASICs below that, and the best GPU being the RTX 3060 Ti at 1.270 (79 W setting). The same RTX 3070 Ti as mine is listed at 87.17 MH/s @ 279 W = 3.20 μJ/Hash, about 10% off my own measurement (93.3 MH/s @ 271 W = 2.90). Power settings differ per model (279 W for the 3070 Ti, 79 W for the 3060 Ti), so the list can’t be used for side-by-side comparison. Among commercial FPGAs, the Blackminer F1+ is 324 MH/s @ 1,000 W = 3.086 μJ/Hash and the F1 is 2.778 — nearly four times worse than the Zynq in ※5 (0.80). The gap between the top ASIC and the best GPU is about 15×. Whether each figure is measured or estimated isn’t stated.↩
※4 All figures are GPU-only power draw, excluding the host PC (the paper uses the same basis). Measured: RTX 3070 Ti (sm_86) / CUDA 12.0 / ccminer 2.3.2 (tpruvot linux branch with an sm_86 patch) at 93.3 MH/s @ 271 W = 2.90 μJ/Hash. At a 150 W power limit, 75.1 MH/s @ 148 W = 1.97 μJ/Hash (31% better efficiency). That is 1.73× the paper’s Titan Xp, and shrinks the paper’s “FPGA is 4.3× the GPU” to 2.46×. Hashrate is the median of a 60-second benchmark; power is the average of nvidia-smi samples under load.↩
※5 J.-F. Têtu, L.-C. Trudeau, M. Van Beirendonck, A. Balatsoukas-Stimming, P. Giard, “A Standalone FPGA-based Miner for Lyra2REv2 Cryptocurrencies,” arXiv:1905.08792. Table V gives NVIDIA Titan Xp = 63.09 MH/s / 215 W / 3.41 μJ/Hash and Xilinx Zynq UltraScale+ 9EG = 31.25 MH/s / 25 W / 0.80 μJ/Hash. Table III gives clock cycle counts per hash function. Related work from the same group: arXiv:1807.05764 (ISCAS 2019); the VHDL is published at mvanbeirendonck/lyra2-hw.↩
※6 From an RTX 4070 Ti operating log published by @Ln_Metal (August 6, 2026): 134.5 MH/s @ 145 W = 1.08 μJ/Hash. The same log also shows 35.22 MH/s elsewhere, but VIP Pool’s hashrate ranking observes that account at 112.7–130.6 MH/s, so I took the 134.5 figure. The same person mined block 4070070 with their name on it as the finder. The ※3 list has the RTX 4070 Ti at 143 MH/s @ 294 W = 2.06 μJ/Hash (stock), meaning power-limiting roughly doubles the efficiency.↩
※7 Measured shares per stage on the CPU: CubeHash (appears twice) 74.7%, Lyra2 11.4%, Keccak 5.4%, BLAKE 4.1%, Skein 2.3%, BMW 2.2%. In the FPGA clock cycle counts of Table III in ※5: CubeHash 78.5%, Lyra2 13.9%.↩
※8 Fusing rotation and XOR via the LOP3 instruction: 15% slower. Kernel fusion: 9.5% slower (registers 47→72, occupancy 83%→50%). Raising occupancy from 66.7% to 83.3%: only +1.7%. Running 2–3 processes at once: 3.5% slower. Only raising intensity came out marginally positive, at +0.5%.↩
※9 Network hashrate is measured by working backwards from block arrival times in the miner’s log and the difficulty. The value reported by the pool’s API was off by more than a factor of 20 below the measurement, so I didn’t use it. About 100 GH/s: 8.1 units of a FusionSilicon X1 (12.96 GH/s), or roughly 1,400 RTX 3070 Tis. “Eight” is a conversion, not a count of physical machines. Published pool statistics (August 6, 2026, 22:40) put the whole network at 111.6 GH/s, of which VIP Pool held 83.0 GH/s (74%) with 30 active workers. Inside that pool the top account had 82.81 GH/s (6.4 X1 equivalents, 74.2% of the entire network), second place 9.16 GH/s, and the other 18 accounts summed to 0.64 GH/s (0.6% of the total). Block finders are all published as “anonymous,” so who mined which block can’t be traced.↩
※10 Only deposits and withdrawals stopped; trading continued as normal at every exchange. bitFlyer from August 4th (※1). Coincheck stopped the same day, citing “the continuing situation in which the Monacoin (MONA) network is not operating,” and from 22:30 on August 5th also suspended brokerage purchases and recurring buys (@CoincheckStatus). bitbank stopped at 15:55 on August 4th, citing “instability of the network and nodes” (notice, which states that “all services other than deposits and withdrawals are operating as normal”). None of the three had resumed as of August 8th. bitbank prefixes notice headlines with 【再開済】(resumed) as a convention, and Litecoin (August 5th) and Cosmos (August 6th), suspended around the same time, have that marker — Monacoin alone does not. Coincheck also announced a resumption for that same Litecoin on August 5th. Volumes are 24-hour figures taken from each exchange’s public API at the same moment (August 8, 2026, 10:28 JST): Coincheck 6,875 MONA, bitFlyer 6,750 MONA, bitbank 600 MONA, Zaif 34 MONA — 14,259 MONA in total (about ¥143,000 at ¥10.05 per MONA). The network’s daily output of 6,000 MONA (※18) is 42% of that total.↩
※11 The break-even point is 0.80 μJ/Hash (at ¥31/kWh and the MONA price at the time). This machine is at 1.97 μJ/Hash, so it falls short by 2.5×. That is nearly identical to the 0.80 μJ/Hash of the Zynq UltraScale+ in ※5.↩
※12 M2pool has a public announcements page, and it does carry a closure notice for the grs pool (2026-01-27) and a removal notice for the enx pool (2025-08-25). So the habit and the place for announcing the end of a per-coin service both exist — and for Monacoin there is nothing. I couldn’t find anything in Japanese or English searches either. Mona is still listed on the site’s supported-coins tab.↩
※13 Done by placing a stratum relay proxy of my own between the miner and the pool (after first confirming on another pool that it captures both accepts and rejects). Over 7 hours 48 minutes of continuous operation, 136 shares submitted and 136 accepted, zero rejects, with response latency stable at around 84 milliseconds every time. Vardiff converged stepwise from an effective 256 down to 1.0. The work delivered matched the control pool exactly on prevhash, difficulty and ntime. Account validation at authentication works too — nonsense strings are rejected. Even so, the dashboard showed zero for uptime, 30-minute hashrate, 24-hour hashrate, earnings and balance, and the miner never appeared in the list.↩
※14 The control experiment used DigiByte (Skein) on M2pool. Same ccminer binary, same GPU, same procedure. At about 40 minutes and 2 accepted shares it showed whole 1 / on-line 1, with 30-minute hashrate, 24-hour hashrate and last submission time all displayed. It finished with 25 accepted, zero rejected. For that coin, incidentally, M2pool is finding blocks every 5 to 16 minutes, and rewards are calculated correctly, transaction fees included.↩
※15 On VIP Pool (a Monacoin-only pool, 0% fee), 263 of 266 shares were accepted and a confirmed balance of 0.170514 MONA was credited. That pool finds Monacoin blocks every few minutes.↩
※16 M2pool’s notice “Notice of RXD Mining Pool Computing Power Problem” (2026-06-17). It states that an upgrade of the RXD node caused a problem with “computing power statistics and block extraction statistics,” but that earnings were not expected to be affected. A precedent for statistics-only breakage exists on this pool as an official record.↩
※17 The electricity price that breaks even is ¥12.6/kWh.↩
※18 Just before the stop, the network was at difficulty 226,348, which from the 90-second block target gives 10.8 TH/s. In FusionSilicon X1 terms (12.96 GH/s, 1,110 W) that is 833 units and 925 kW. The current block reward is 6.25 MONA (measured from the coinbase in stratum: outputs totalling 6.25012350 MONA), so the whole network produces 6,000 MONA a day — ¥60,120 at ¥10.02 per MONA. The MONA price at which those 833 units break even is ¥11.10 at ¥3/kWh, or ¥18.50 at ¥5/kWh. MONA fell to ¥11.37 in February 2026 and ¥9.90 in April. At efficiency equivalent to the X1 (11.7 MH/J), even assuming extremely cheap electricity, this doesn’t work out for the first half of this year. Put the other way, making this scale work at this year’s prices needs about twice the X1’s efficiency (21.6 MH/J at ¥5/kWh).↩
※19 @you21979, September 11, 2024: “Why was Monacoin’s hashrate maintained at such a high level, out of line with the price? Now that the hashrate has crashed, maybe mining is profitable in Japan with an ASIC.”↩
