Comment by ProllyInfamous | Hacker News Reader

Comment by ProllyInfamous | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com