If folks are interested in the old Monero PoW function (and, uh, the reason they changed it), I wrote up a thing about it a long time ago:
https://da-data.blogspot.com/2014/08/minting-money-with-mone...
The history of people trying to design GPU or ASIC-resistant proof-of-work functions is long and mostly unsuccessful. I haven't looked into RandomX; it's possible they've succeeded here (or possible that with the alt-coin market mining profitability tanking after Ethereum moved to proof-of-stake, it just wasn't worth it).
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.
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.
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.
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.
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.
> 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.
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.
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.)
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
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.