There was a proposal on Ethereum that didn't succeed (progpow) since they were already in the late stage of transitionning to PoS. Ethereum did quite a good job at keeping asic advantage moderate (the speedup was 100% max - not orders of magnitude). RandomX is basically progpow that succeeded. You might be interested in Chia's Proof of Space and Time... and how it collapsed!

ProgPow was ridiculously simple and would never have accomplished its goal. I covered it briefly in my Monerokon talk as well.

I don't know if PoW based approaches make much sense in the modern environment, anyhow -even very clever ones that provide ASIC resistance. Ethereum has been doing real proof of stake (and not delegated proof of stake which is both easier and terrible from a system safety perspective) for quite a while and it's seemingly cheap, effective, and robust.

PoW is useful in far more situations than PoS. A derivative of RandomX is now used to protect TOR too (Equi-X). https://github.com/tevador/equix/blob/master/devlog.md

Yes I suppose it's difficult to stake something of value when the system you're securing is not stapled to a currency.

> You might be interested in Chia's Proof of Space and Time... and how it collapsed!

Because it was written by Bram Cohen, I'd be interested in reading two or three sentences about how it collapsed.

Because it's a blockchain-based cryptocurrency, feel free to stop writing after three or four sentences.

This was a super interesting read, and it highlights exactly the strength of cryptocurrencies. They turn game theory in their favor, so egoistic players (I don't mean this in an offensive tone) contribute to making it stronger and safer for everyone else.

Thank you for sharing!

They kinda do - I'll admit honestly that the final game I played in the cryptocurrency space I played solely to profit. (It was a minor, uh, **coin that didn't have a lot of redeeming value to start with). Though it turns out the incentives remained somewhat aligned: I ended up providing the developer with some security bug fixes to make sure someone couldn't mess with the cash cow. :)

(To be clear: We were just optimizing mining; in the process of looking for ways to mine it faster, I found some security bugs and fixed them. We weren't exploiting the bugs, that crosses a line for me.)

RandomX is designed so that if you design a RandomX ASIC then you've designed a CPU. It writes and then executes random programs. To minimize the possible efficiency gains from matching the instruction set architecture, the same program is executed several thousand times, reducing the relative overhead of translating it to a different ISA.

I partially heat my home by running the default Monero client on old Xeons (heat ejects near my desktoes). As I only mine when it's cold outside (otherwise using resistive heating), there is no actual net electricity cost. IMHO it's not "worth it" for an individual to buy equipment specifically to mine crypto... but if you already have an old machine AND you heat without a heatpump, it's a free hobby/heater.

----

To anybody else that is syncing a fresh monero blockchain copy (i.e. installing the official client), I recommend using the custom node flag ` --db-sync-mode safe ` — which is slower but corruption-avoiding — before node's initial bootup. Without safemode, any halt of the client will [most likely] corrupt the local blockchain (losing days of DL/verification).

Also, if you use an SSD for storing any blockchain (as recommended by monero team... but not by me), know that its lifespan will be greatly reduced from the constant IO/access. Personally, I recommend safemode (see above) on a 7200RPM spinner (HDDs effectively don't wear during IO/access).

----

What are your thoughts on running xmrig vs. the default getmonero.org client? Would you in general agree that monero remains ASIC-resistant?

A heat pump would arguably be more efficient for society (can provide 4x heat for 1x energy), but if you make enough money on the mined monero I guess it might be rational.

Would be curious if the marginal savings from a heat pump would allow you to buy more monero than you mine with this energy.

The only heatpumps in my house are airconditioner[†] and waterheater (mild winter climate doesn't justify replacing HVAC — but if/when it dies, I'll put in a modern minisplit) [ƒ].

[†] It's an older model, without reversing valve (circa early-2000s).

[ƒ] ...and refrigerator (thanks /u/twic)

----

>if the marginal savings from a heat pump would allow you to buy more monero than you mine with this energy.

In a colder climate, DEFINITELY (to a point: see /u/nerdsniper's great point, below).

----

I replaced a 300W "toe heater" with this rig; by directing heat to only wear its needed (i.e. muh'toes), I can heat the entire house less (whether resistive or heatpump).

> In a colder climate, DEFINITELY.

Actually, I suspect heating-by-monero-mining is more likely to economically beat heat pumps only in the very coldest climates. Heat pump efficiency goes down when the temperature delta between inside and outside is very large. Below 0F or so, it's quite difficult to find heat pumps that will work sufficiently well, and generally they transition to resistive heating.

Caveat: I'm only talking about marginal advantage, ignoring the capital costs of the Xeon servers or the heat pump itself.

For hobbyists such as myself, the capital cost of already-owned (and obsolete) Xeons are infinitely less than replacing an otherwise-functional (albeit cooling-only) AC in a sub-tropical rainforest climate (like mine), which only has a few weeks of annual frost (snow "sticks" once every decade).

As far as placement of the machine: underneath your computer desk is ideal, as this directed heating allows you to keep the house's thermostat a few degrees cooler.

----

If anybody were to ask me "what would you BUY to mine monero@home," I would definitely tell them to [instead] buy a heatpump-heater, -watertank, -&c (presuming they don't have each, already).

You don't have a refrigerator or freezer?

Wearing a woollen jersey would be even more efficient for society.

Just use a Linux laptop with a working battery so you never have to worry about power outages or other system crashes. In that case, you don't need safe sync mode, and you don't have to kill your SSD.

Working battery ≠= avoiding system crashes | my local node has a UPS, and still Monero's client is dicey (Mac & Linux distros).

Particularly on its initial sync, Monero's daemon is flakeyAF.

If you (e.g.) don't allow `sync in background` (why is this not the default behavior?!), the official Monero client is notorious for locking up on wakeup. Once you kill the process, your local blockchain is [most likely] unusable.

Another reason to use safe-sync is (e.g.) if your system (Linux or whatnot) decides to update/restart during the several days it takes to sync-initially.

----

Just out of curiosity, why do you abuse an SSD so (safe-mode, or not)?

For SSD-diehards, I'd recomment getting a very large size because this'll last longer, presuming the drive self-levels.

> Once you kill the process, your local blockchain is [most likely] unusable.

Totally false. LMDB is perfectly crash-proof in that scenario and killing the process never damages the DB. The only thing that's not guaranteed is turning off syncs, in the face of an OS crash/power outage.

If you don't sync, you're not abusing the SSD. If you run on Windows, the OS is too unstable to use without safe sync mode though.

>Totally false.

This is a well-documented failstate. Usually results in "unable to connect to 127.0.0.1:18081" errorlog, which is most-commonly due to a corrupt database/blockchain (from hardstop/kill).

In order of crashout likelihood: Windows >> MacOS > Linux

>If you don't sync, you're not abusing the SSD.

If you don't sync then you're not (cannot be) a fullnode / network verifyer / ringsigner.

----

>LMDB is perfectly crash-proof

It is my understanding that once your initial-sync has completed, the default monero node behavior is to then automatically enter the --safe flag (I described above).

This may be old behavior... I go way back (years beyond a decade). My only modern use in xmrworld is as a personal foot-heating ATM.

> If you don't sync then you're not (cannot be) a fullnode / network verifyer / ringsigner.

I was talking about database sync, not blockchain sync. You don't need to use safe sync mode if you don't have to worry about machine crashes. And just killing the process will never corrupt the blockchain DB.

> This may be old behavior... I go way back

On this particular point, I go way back further than you.

>On this particular point, I go way back further than you.

Definitely know who you are (LMDB programmer &c), and your contributions to world & crypto tech – thanks (few people can claim, like yourself, that their code exists on BILLIONS of machine). I've ALSO been in cryptospace longer than Monero's existance... you are hands down a better programmer than myself (I'm a bluecollar electrician), with much more name recognition.

----

BUT: You aren't listening to my "layperson user behavior report" about a common and known behavior of the default getmonero.org node. I would love to help you&team better stabilize/configure the default client behavior/options...

Please don't let hubris stand in our way of spreading the gospel of crypto. If you want me to sign some custome statement with a BTC hash (dating back to the earlytimes) just send me a postcard (I no longer use email). But you shouldn't need that to listen.

>just killing the process will never corrupt the blockchain DB

I would love to show you how easy this is to reproduce, even on fresh installs of Ubuntu and/or MacOS on otherwise-stable hardware (never tried Windows... easier?).

----

Loved your 2019 talk on "is XMR still ASIC-proof" – is it still, in 2026, in your opinion? Your line about ~"our goal is to make a hash algorythm so dynamic that if you designed an ASIC processor for it... it'd essentially just be a CPU"~ – classic quoteable.

>> just killing the process will never corrupt the blockchain DB

> I would love to show you how easy this is to reproduce, even on fresh installs of Ubuntu and/or MacOS on otherwise-stable hardware (never tried Windows... easier?).

If it's so easy to reproduce, you should be able to screen record a session with two terminal windows:

1 with monerod running and syncing the blockchain

2 send a `kill -9` to the monerod

1b restart monerod

And then we should see the error message you're referring to.

Awesome; let me rsyncd this bitch and then I'll try to help out. I'll do another with a brand new fresh install (do you have a Linux varient, otherwise it'll be Ubuntu v24).

Will also provide the perplexity.ai chatlogs that I used to both find other similar crashouts and resolve my issues. Again, I am not a programmer but have been accepting crypto (with client discount) since 2012.

Thanks again for your contributions to this community.

----

As you're capable, do you happen to know why the default configuration doesn't sync in background – this is just wild... anybody installing XMR-adjacent software isn't going to expect this behavior.

...the re-sync (after stopping due to timeout) is always where my issue appears.

The LMDB backend (I know it's you're baby) could possibly be having a freakout when Linux comes back online?! (from e.g. sleep) – I genuinely don't know – but am happy do demonstrate my frustrations (that I've had literally & reproducably on both Linus and MacOS distros (across YEARS).

Thanks for the approachability.

> Loved your 2019 talk on "is XMR still ASIC-proof" – is it still, in 2026, in your opinion?

Yep. Nothing about computing architecture has changed.

Great to hear. Of course, were I in your shoes/connections of course it'd be difficult to give an honest answer =P

----

>once your initial-sync has completed, the default monero node behavior is to then automatically enter the --safe flag

Is this still true, too?

I don't know what the current versions do, it's been a while since I touched that code.

I have no reason to lie, I'm not selling anything. Bitmain is selling mining hardware, take a look at their claims. They've had 7 years to try to crack it.

They had to design a specialized verification function, which I imagine would be the easy way to break it.

The brilliant part of Bitcoin is that it uses very widely known crypto primitives - verification is the same as getting the right seed (you just happen to be told what the right seed is, rather than having to pay for it to be discovered).

You must be on drugs. There is no separate specialized verification function. It's the same algorithm for verification as for mining.

Correct; both Bitcoin and Monero use Hashcash as PoW, only differing in the choice of hash function. Verification is only different from a solution attempt in asymmetric (i.e. non-Hashcash) PoW, such as Cuckoo Cycle or (the poorly named) Equihash.

lolwut. There is no specialised verification function.

Hmmm. That's not the reason we changed it. We just got tired of tweaking things to prevent ASICs.

I'll add that there was such a large influx of miners at the outset, that (statistically) it seems any crippling of the original algorithm was fairly futile - the edge was both short-lived and minimally impactful. We're over a decade later, and nobody mining in the first month (even with that unfair advantage) was able to gain any meaningful percentage of Monero's emission.

I'll add that RandomX has proven that it is indeed possible to create a GPU and ASIC-resistant PoW algorithm. I'd encourage you to dig in further - the closest to an "ASIC" is a multi-CPU miner (Bitmain X9) with a bunch of RISC-V CPUs in it.

Sorry, I was not quite saying my fun was the reason, but that the failure to create something GPU/ASIC resilient was the more general underlying cause.

But be careful about "proven" in that last sentence - the absence of a solution isn't exactly proof, it's more of a proof that _either_ it is possible to create an ASIC-resistant algo _or_ it has not been worthwhile to ASIC-ify it given the economics of mining XMR and the research & NRE required to do so. I haven't the foggiest which of those two it is, mind you, just that there are a few remaining valid explanations.

It's a proof that something is possible to show one example.

In this case the claim was ASIC-resistant PoW is possible, and the proof has been the historical behavior of miners after years of RandomX. Nobody said it would be eternally or entirely resistant to optimizations...

You are twisting words beyon any coherent meaning.

> It's a proof that something is possible to show one example.

Agreed.

> the proof has been the historical behavior of miners after years of RandomX.

> Nobody said it would be eternally or entirely resistant to optimizations...

These are contradictory statements. If historical behavior was a proof, then it would be eternally and entirely resistant.

The limit we set at the beginning was "no one can design a custom device for RandomX with more than a 2:1 efficiency advantage over general purpose CPUs". That is and will forever remain true.

In reality, no one has been able to build any device for RandomX that isn't actually a CPU. The closest thing to a "mining ASIC" is just a bunch of RISC-V cores.

I was intending to comment on poor wording or poor reasoning (I assume the former), not Monero.

I think what the evolving Monero team has done, for many years since inception, is wonderful to the point of inspiring. The thoughtful approaches it has consistently taken over many upgrades reflect a much greater level of competence, responsible goals, clever design, and a clearer consistent vision than all but a few alternative systems.

(Including better choices than Bitcoin, which seems to have completely elevated code stability over any problem resolution (user privacy/safety, transaction scalability, environmental damage, etc.). Stability over all non-critical features including ergonomics (i.e. transaction times) is a very strong, but legitimate choice. But not stability over basic failures/limitations relative to current function.)

Disclaimer/scope: I do not own Monero or any other cryptocurrency, but have in the past. My comments are purely about technology, with no financial/investment dimension.

Monerites - what’s the state of play for fpga mining? I did not see anything in the light documentation of RandomX that looked like it was tuned to be “awkward” for a good sized fpga.

FPGAs have no particular advantage. You could dedicate a chunk of their resources to implement a softcore CPU but it'd be several times slower than a real CPU.

The random programs change too quickly to just implement them directly on an FPGA. Reprogramming the entire chip like that takes too much time.

Monero has used Random X for 7 years

Why even mention that era? Your fascinating by that time was shorter than its post Random X lifecycle