[hyc_symas]

> 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.

[ProllyInfamous]

>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.

[hyc_symas]

> 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.

[ProllyInfamous]

>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.

[hyc_symas]

>> 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.

[ProllyInfamous]

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.

[hyc_symas]

> 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.

[ProllyInfamous]

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?

[hyc_symas]

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.