Discussion of the future of the PoW algorithm

[dEBRUYNE-1]

This ticket is meant as supplement to #315 as well as a place where ideas can be discussed in more detail and outside of the scheduled meeting(s). As far as I can see, we basically have these options:

1. Maintain the current tweaking schedule. I think we can all agree this strategy has not worked and is potentially dangerous and should thus be abandoned.

2. Expedite the current tweaking schedule (e.g. fork every 3-4 months). This would, in my opinion, be unsustainable and thus not feasible. Some services already deem our current 6 month schedule as aggressive. Expediting the schedule may even put us at risk of these services delisting us. We also have to keep in mind a future where the Monero ecosystem grows. The more the ecosystem grows, the more difficult forks will become to coordinate and execute.

3. Switch to an ASIC friendly algorithm in the next scheduled protocol upgrade. Some people are worried the ASIC (manufacturer) ecosystem has not sufficiently matured yet. Presumably, it will mature further once time passes. Whether waiting is worth the incurred trade-offs is the question though.

4. Perform one more tweak and switch to an ASIC friendly algorithm thereafter. This would allow the current miners to achieve some ROI, which can presumably subsequently be used to invest in ASICs.

5. Perform x more tweaks and switch to an ASIC friendly algorithm thereafter. This seems like an unwise strategy if we deem the tweaks as a failed strategy.

6. Implement RandomX in October or April (in case it is not ready yet, though it would presumably mean one more tweak). Do not precommit to anything thereafter. I think this strategy would be susceptible to a lot of future controversy to the extent that there will be a contentious debate about the future of the PoW algorithm if specialized devices show up for RandomX.

7. Implement RandomX in October or April (in case it is not ready yet, though it would presumably mean one more tweak). Precommit to an ASIC friendly algorithm after 1.5-2 years. This would enable ASIC manufacturers to already start designing devices. Furthermore, it would give us time to try to find a company that could publish an open-source design. Additionally, this removes future friction and allows us to focus on the protocol.

8. Explore a GPU centric algorithm.

9. Explore dual PoW: e.g. RandomX for CPUs, CryptonightR (with tweaks favoring GPUs) for GPUs. As far as I know Zcash investigated harmony mining and deemed it relatively unsafe insofar as that it would significant raise the attack surface and not add that much additional security.

10. Game Theoretical approach to ASIC resistance (proposed by MoneroCrusher).

11. Implement RandomX in October. Precommit to switching to an ASIC friendly algorithm (such as SHA3) in case of failure of RandomX. No further tweaks. // Currently preferred path, as can be seen from here.

I'd personally be in favor of option 3, 4, or 7. I have some reservations about RandomX though, which are as follows:

• Fairly new and untested. It thus has not succeeded the test of time.
• Has to be audited, which is going to be costly (and will have to be funded by the community). By contrast, a well-known ASIC friendly algorithm would not require such an audit.
• Increases verification time for nodes, especially for lower end devices. This is predominantly caused by 4GB memory requirement. That is, any device with less than 4GB RAM available will take a large verification performance hit. This, in my opinion, is paradoxical to our ethos where we want everyone to have access to Monero. It would, for instance, making running a node on a Raspberry Pi rather difficult if not completely unfeasible. Lowering the memory requirement significantly would resolve this issue as far as I can see. However, it would also make cryptojacking more attractive. This has been addressed in the new version. Verification time is now approximately similar to earlier versions of CryptoNight.
• ASIC resistance is basically a function of market cap. If Monero grows a lot, someone will inevitably create a specialized device for it that slowly drives out other miners. This would be significantly less of an issue, however, if we'd precommit to a switch to an ASIC friendly algorithm after say, 1.5-2 years. Hyc responded to this with:

This is only true up to a limit. Everyone has access to the same transistor technology. Unbundling components that CPUs contain that the ASIC doesn't need can only yield so much power savings. Our pessimistic estimate is that ASICs can be 2x more power efficient than CPUs; best case is only 1.2x. These numbers are based on physics, not market cap.

• These numbers are theoretical and I am not entirely convinced they will hold up in practice / the real world as well.
• May be met with a lot of opposition for the mining community, potentially causing a split. Same can be said for switching to ASICs I guess. Although, having one more tweak to allow current miners to achieve some ROI would somewhat mitigate this.

To reiterate, the concept of ASIC resistance, in my opinion, better than ASICs. However, if we cannot viable attain it, the subject should be revisited. Some community members also seem to be venturing into an "at all costs" strategy to preserve ASIC resistance, which is potentially dangerous and may be a net negative for Monero.

[dEBRUYNE-1]

opposed to just milk it.

So you'd argue the current GPU and CPU miners are "just milking it" as well?

[el00ruobuob]

I guess, it's not the miners who milk it, but the manufacturers. If one creates a CPU miner and sell this software, it's milking.

[antanst]

@antanst the fact that Bitcoin survived its early years when it wasn't even worth 1 cent proves that statement false.

Not quite. The primary reason Bitcoin didn't have any huge reorg incidents or other attacks at that period is that nobody knew it, or nobody that knew it deemed worthy to attack it precisely because it was almost worthless. The network itself was incredibly vulnerable back then when just a few people were mining with their CPUs.

[el00ruobuob]

@antanst I don't catch how it's linked to your statement who @hyc talked about, could you elaborate on it?

[antanst]

@el00ruobuob I'm arguing that we can't compare the current situation to the very early days of Bitcoin that @hyc mentions, where Bitcoin was obscure and worthless enough not to attract malicious actors, despite being much more vulnerable due to the very small number of people mining it.

[Gingeropolous]

So you'd argue the current GPU and CPU miners are "just milking it" as well?

Some do, some don't.

I don't see where your going though. An ASIC manufacturer is creating and building something. As @el00ruobuob just posted, its different.

I mean, the problem is that the development space for mining is mostly populated by profiteers. There has been so little development of anything related to block generation in any cryptocurrency that its actually concerning. Its perhaps the fundamental aspect of this entire thing, and from top to bottom people are throwing in the towel. I mean, pooled mining? Still? Without co-operative generation of the block templates?

No one talks about it. No one bats an eye that in most of these networks, there are 4-10 block producers. Everyone just says "well, if the pool operators starts publishing bad blocks, then the miners will move."

Except if the ASIC comes configured to only work on registered pools. But why would they do that? Well, why wouldn't they? They'd make more profit if they force their products to work on their pools, and greed is good, so... logic + logic = logic!

This problem is more than just the mining PoW, and no one cares. So, I guess I shouldn't either, right?

I think I want to sum up my distress with this. Creating an ASIC-dominated network feels like creating a backdoor. A weakness left in the code because it provides a benefit for something or other. Yeah, sure, it might not be a strict interpretation of backdoor but its something like that. And backdoors are bad, right? Yes, working on our own PoW may also create a backdoor. But that backdoor is still relatively under our control. Once the ASIC door is opened, I don't know how it can be closed.

[hyc]

@antanst to be clear

If cryptocurrencies relied on people's good will to burn electricity out of their pockets "for the good of the network", the whole thing would have died pretty soon, years ago.

Clearly this statement is false.

[JohnnyMnemonic22]

I see lots of discussion about the technical consequences of certain decisions, but little of the social consequences. @fluffypony, if you don’t want a Bitcoin SV scenario, it may be wise to not forget what brought us together in the first place. I 100% disagree that we should not mention the whitepaper. Monero is a community first, NOT a technology first. We have a fiduciary responsibility to maintain the principles that created this community, and the whitepaper is our indenture.

It cannot be understated that Monero has an IDENTITY, and that is way more interesting and special than whatever the latest research or technical breakthrough happens to be (not that those things aren’t important, but they’re a result of who we are). The network can completely fall apart, but we will still be here because of what we stand for. But if we abandon our principles, it won’t matter how perfect or secure the network is. We will have failed in our trusteeship, and the community will be a hollow shell of what it once was.

[scottAnselmo]

I agree with Gingeropolous. Hopefully I'm not oversimplifying, but it sounds like the options basically boil down to RandomX or ASIC friendly. My vote is with RandomX.

At the end of the day, the problem we're dealing with is general hardware vs specialized, and there's no realistic way for general hardware to win. If we go full ASIC friendly though we are arguably entirely reliant on the markets being competitive enough. While we can try to make it easy for startups, etc to manufacture there's no guarantee the markets will play out how we hope. The one positive is that we'd be using established crypto, but we as a community would be ceding a great deal of control over mining diversity security.

This snippet I think highlights the ongoing issues with ASIC's and why even when public sold, ASIC manufacturers still win big because they can buy 9 more for themselves every time someone buys one. It's the runaway leader problem on steroids:

Our investigation into the mining equipment strongly suggests to us that the total manufacturing cost of the equipment is less than $1,000, meaning that anyone who paid $10,000 for it was paying a massive profit premium to the manufacturer, giving them the ability to make 9 more units for themselves. Beyond this, the buyer has no idea how many were sold nor where the difficulty would be when the units shipped. The manufacturer does know whether or not the buyer is going to be able to make a return, but the buyer does not. The buyer is trusting the manufacturer entirely.

One of our goals is trying to make the Monero ecosystem as trustless as possible. Given all the bad behavior by BitMain and their continued dominance in the ASIC space, I don't see the prominent bad behavior in the ASIC space changing much, if at all and us trusting the markets is dangerous.

With RandomX while it does have a notable con of spinning our own crypto, we as a community are not ceding control to bad behavior markets. If the numbers are correct and ASIC's will have at most 2x, the runaway leader problem will still exist (manufacturers can still sell overpriced goods which we have no control over or otherwise not sell them, etc), but we still mitigate.

To me the cons of going ASIC friendly and having to trust the markets far outweigh the cons of RandomX and paying for peer reviewed math. When we activate RandomX is a debate that is arguably secondary to that of ASIC vs RandomX.

[fluffypony]

@JohnnyMnemonic22 Monero's identity is that it is a privacy-enhancing technology. People don't say: "oh yes, Monero, that ASIC resistant coin", they say "Monero, that privacy coin". The MRL's research has ENTIRELY been focused on privacy and scalability, and not on resisting ASICs.

Here's some of the negative things that resisting ASICs has accomplished:

• lots of criticism from highly technical people
• massive amounts of dev talent spent on PoW tweaks
• emergency, reactive hard forks
• terrible release engineering because we want to leave PoW tweaks until close to the fork
• a huge centralisation factor
• botnets
• the prevalence of Monero mining malware
• horrendous IBD & sync performance due to slow PoW validation

Let me be clear: it is not possible to avoid ASICs forever and retain our current properties. By pursuing that as a goal we are either going to end up being highly centralised, or we are going to open the door to ASIC manufacturers becoming significantly more sneaky than they have previously, or both.

I don't want to get too caught up in a back-and-forth on this. Suffice it to say that I will do whatever the community wants me to do and merge whatever PRs they want me to merge, but my strong preference is to commit to a hard date when we will switch to SHA3, even if it is 5 years out, and do whatever in-between: RandomX, ProgPoW, Cuckoo Cycle, whatever.

[JohnnyMnemonic22]

The people of this project have never been shy of adversity, which is essentially what all your negatives boil down to. Criticism? Botnets? Are you being serious?

Let me be clear: it is not possible to avoid ASICs forever and retain our current properties.

That's an assumption that gets repeated a lot.

We DO need to get caught up in a back-and-forth on this. Otherwise we skip to the "solutions" without properly defining the boundaries and what is really at stake.

[fluffypony]

@JohnnyMnemonic22

The people of this project have never been shy of adversity, which is essentially what all your negatives boil down to. Criticism? Botnets? Are you being serious?

You disagree that those are negatives? You think that Monero being identified as malware by antivirus companies due to the mining code is a good thing? You think that criticism from highly technical people should be ignored because we know better? Besides, you're cherry-picking two that you think aren't that bad - and I agree they're not - but that ignores the wood for the trees.

That's an assumption that gets repeated a lot.

It's not an assumption. ASIC manufacturers will get faster and smarter, and companies like NextSilicon and XTend Online will eventually be able to manufacturer their FPGA-like equipment at scale. We're fighting a losing battle. If there is evidence that we can achieve resistance to specialised hardware without hard forks every 3 months I have yet to see it.

We DO need to get caught up in a back-and-forth on this. Otherwise we skip to the "solutions" without properly defining the boundaries and what is really at stake.

Everyone else is welcome to have as many discussions about it as they need, nowhere in my comment did I imply otherwise? Not sure where you got that from.

[JustFranz]

I feel that no matter what, we are going to have to switch to RandomX in the meantime and that is the immediate priority. The urgency of any move to SHA3 will depend on the results of the RandomX audit from an ASIC manufacturing and CPU internals POV. The possibility of a switch will depend on the overall crypto ASIC or custom ASIC manufacturing landscape.

[fluffypony]

@JustFranz I totally agree - the only thing I'd add to that is that picking a date in the future for the switch will help existing miners figure out how and when to sunset their equipment, and will help ASIC manufacturers gear up. It doesn't have to be any time soon, it can even be 5 years out, but putting a peg in the ground would be useful.

[JohnnyMnemonic22]

You think that criticism from highly technical people should be ignored because we know better?

Not at all. You listed it as a negative consequence, as if our goal should be to avoid criticism. And your mention of malware and botnets struck me similarly, like you think we need to suddenly start caring what everyone else in the world thinks about us. That was never what we were about.

ASIC manufacturers will get faster and smarter, and companies like NextSilicon and XTend Online will eventually be able to manufacturer their FPGA-like equipment at scale. We're fighting a losing battle.

ASIC manufacturers are people. It's people vs. people. There's no winning or losing, but sometimes one side has an advantage.

You're probably correct in your assertions, and an ASIC-friendly PoW is probably the best technical solution. I'm suggesting it might not be the best solution FOR US. I'm only saying we need to consider who we are and the values we stand for before jumping into timelines.

[iamsmooth]

@fluffypony

Monero's identity is that it is a privacy-enhancing technology. People don't say: "oh yes, Monero, that ASIC resistant coin", they say "Monero, that privacy coin".

Can't agree entirely. A lot of the exposure (in the sense of "no such thing as bad publicity" perhaps) has indeed been from mining malware. In fact I might venture to guess that there could be more mainstream news mentions of Monero in that context vs. the privacy coverage, which seems more sporadic.

Within the crypto community, Monero is certainly known for privacy but also known for its mining properties, particularly once the population of large coins practically mineable without ASICs narrowed a lot (effectively to one). I've had people from other crypto projects entirely, bring up to me the idea of using (user-controllable; non-malware) Monero in-browser mining to pay for their web services, even though they have other use for Monero. This aspect of Monero is very well known.

The MRL's research has ENTIRELY been focused on privacy and scalability, and not on resisting ASICs.

One could probably explain that to some extent as: the mining aspect fine as intended for the first three years and the privacy and scalability worked terribly.

[JohnnyMnemonic22]

Monero also has an underground, anti-establishment culture to it that I know you're aware of, @fluffypony, because you actively contributed to it. You may not see it as clearly now that the community has grown, but it's still there and, I'd argue, is the nucleus of what drives the project.

[bitlamas]

[...] picking a date in the future for the switch will help existing miners figure out how and when to sunset their equipment, and will help ASIC manufacturers gear up. It doesn't have to be any time soon, it can even be 5 years out, but putting a peg in the ground would be useful.

Instead of setting a definitive expire date to RandomX and officially accepting that Monero will change one of its core features that is arguably part of the social contract -- going 180° in something that has been defended by the vast majority since day 1 -- shouldn't we consider a middle ground? Like try to come up with parameters that would define either the success or the failure of the RandomX and then, in Z years as proposed, we can reevaluate using those parameters and then take a decision.

Precommitting to something that is clearly contentious so far ahead without really knowing what the future holds sounds dangerous.

[iamsmooth]

@fluffypony

but it occurs to me that we'd already have seen this happen with Bitcoin ASICs in Venezuela and other parts of the world if this was a concern

I'm not sure why you think we haven't. I've seen many stories about mining gear getting confiscated there, and a few specifically about how people there use can GPUs and mine Ethereum, Zcash or Monero instead of Bitcoin/ASIC coins (which can also be confiscated of course, but at least has a better chance to slip by). Of course like everything else that comes out of Venezuela or out of crypto 'press' you never quite know who to believe.

Here's one I pulled from the top of google, but one can easily find more

https://www.newsbtc.com/2018/05/31/officials-in-venezuela-begin-confiscating-imported-bitcoin-mining-hardware/

[JustFranz]

@fluffypony

@JustFranz I totally agree - the only thing I'd add to that is that picking a date in the future for the switch will help existing miners figure out how and when to sunset their equipment, and will help ASIC manufacturers gear up. It doesn't have to be any time soon, it can even be 5 years out, but putting a peg in the ground would be useful.

I'd like to account for a scenario where RandomX works really well and improving/tweaking it each release is enough to postpone a switch until the ASIC space is deemed sufficiently mature.

The main reason why the ASICs that are made right now are not sold is that they are too good compared to anything else out there, orders of magnitude better. Its just too easy to mine all of the coins yourself and mining all of the coins yourself is going to be maximum profit you can make, unless you sell so many ASICs that the buyers are forced to take a loss.

Perhaps closing the efficiency gap will change this behavior.

[hyc]

It's not an assumption. ASIC manufacturers will get faster and smarter, and companies like NextSilicon and XTend Online will eventually be able to manufacturer their FPGA-like equipment at scale. We're fighting a losing battle. If there is evidence that we can achieve resistance to specialised hardware without hard forks every 3 months I have yet to see it.

Our previous PoW hard forks were just static targets. Sitting ducks, which is why they couldn't hold off ASICs for any long period of time. RandomX (and to a lesser extent, Cryptonight/R) is a moving target.

FPGAs are great for static algorithms but can't handle dynamic algorithms. When you use up FPGA resources to operate dynamically, you're building a softcore processor and these will always, necessarily due to machine architecture, run several times slower than for a static algorithm. These are simply not a threat. Not for RandomX anyway.

ASICs with an outsized efficiency advantage are not inevitable. That's not how hardware works. The more generalized they're required to be, the less efficient they become. This is unavoidable.

[iamsmooth]

I tend to agree that RandomX and to an extent CN-R are new ground in that no other such algorithm has been deployed so there is no track record to say that it will absolutely be ASICd.

However, I also tend to believe that it is largely a matter of (XMR) price, especially if the forking schedule is taken off the table. There are numerous obvious (and perhaps additional non-obvious) ways that a RandomX chip can be more efficient than general purpose processor (GPU or CPU), even if only by removing unused components. The degree of efficiency improvement won't and can't be arbitrary, but at some price and with a reasonably-long equipment lifetime, it still makes sense.

BTW, as I've noted elsewhere, the way the mining profitability math works out, the degree of advantage isn't that important, as long as there is (a significant) one. A 10000x advantage gives near-100% profit margin against competing near-break-even miners. But dropping that down to 10x still gives 90% profit margin. Even a 2x advantage gives 50% profit margin, which is still extremely high and with a naive calculation (not quite accurate, but close enough for illustration) only doubles the pay-back time compared with 10000x. I wouldn't rule out even 10-20% advantage being economically sufficient in some cases (with higher XMR price).

[tevador]

@iamsmooth You can also get a 2-5x operational cost advantage by basing your mining farm in Iceland ($0.04/kWh). Capital costs will be probably much lower than designing an ASIC from scratch.

[iamsmooth]

@tevador That's a nonsense argument. No one locates a mining farm in a high-electricity cost location. They're all in places with cheap electricity. The cost advantages from an ASIC are additive.

Now it is true there will be dorm miners with no direct electricity cost at all, and those will certainly not have to worry about competing. As well as people who mine for a hobby and don't care about profitability. But that's all kind of at the fringes. The bulk of the hash rate is going to end up in places with cheap electricity that is somewhat scalable.

[rw258906]

can someone please elaborate on why these options are off the table?

I have a few questions, I mentioned one on reddit, but maybe I can get a better answer here, I am sure there are good reasons you guys aren't discussing these but perhaps you could make it clear why these ideas wouldn't work.

Why not do 2 algos 1st randomX and the 2nd ProgPow. While neither might be a perfect solution, having both and updating them from time to time seems like it would make it pretty hard to control 80%+ of the hashpower?

If Monero were to use an algorithm designed to be optimized for specific consumer hardware such as RandomX or ProgPow, wouldn't it be easy to create an ASIC detection system using the profitability of the target hardware. For instance, instead of adjusting the algo every 6 months no matter what, why couldn't Monero adjust the algo every 6 months if, and only if, they become unprofitable on their target hardware at $0.10/kWh?

[tevador]

@iamsmooth I would argue that a significant amount of hashrate are miners who pay residential rates for electricity.

My point was that when you start talking about 10-50% advantage being significant, you have to consider that there are already differences of this magnitude between individual miners even without ASICs.

[SamsungGalaxyPlayer]

@rw258906: please read this entire thread: https://github.com/zcash/zcash/issues/3672

[umma08]

Firstly....

@Gingeropolous

that was epic. fair play. ;-)

[iamsmooth]

@tevador I'm going to disagree with you that a significant amount of hash rate are miners who pay high residential rates for electricity. There are certainly places in the world that have low residential rates, some even lower than what you quoted, and people living in those place or in places at least with moderate rates may run large rigs, build mini farms, etc., people paying rates at the higher end of the range will not do this unless the plainly do not care about losing money (and there are indeed some, but even they have limits of how much they are willing to lose).

And, again, it is additive. If the big farms in Iceland, China, NW US, etc. are using ASICs which give them an additional 10-50% advantage then it is that much harder for people with higher electricity rates to compete and many, most, or even all will be pushed out. 10-50% is a HUGE additional margin in terms of mining.

[ArticMine]

I will start first with a question. Did we brick any ASICs this time around or did we simply just make GPU and CPU mining ~3.6 times harder? I actually just tried a little experiment. Mine Monero my my laptop and get ~10 H/s. mine MoneroV and get 36 H/s. MoneroV corresponds to V7 of Monero when it comes to mining and 36 H/s is close to what I was getting before all of this started last year. My suspicion is that either there were no ASICs in the network or if there were any they has a minimal at most impact on the network. This also explains the fast recovery about 2 days, unlike what happened last spring and the fact that there was no impact in the 2018 fall fork. Please prove me wrong with actual benchmarks on CPU and GPU mining that we actually killed 600-700 Mh/s worth of ASICs this time around. If what I suspect is true the it is very hard to argue that our current strategy has failed or that we need to hard fork every 3 months, when the reality has been no ASICs for close to a year. Even if I am proven wrong it is still 8 months before ASICs actually appeared on the network.

I personally consider myself fairly neutral on the ASIC issue. The real threat here is proprietary mining. ASICs are only a threat in as much as they enable proprietary mining. Realistically i do not believe that we can completely eliminate ASICs from the network even with something like RandomX. What I do believe is realistic to narrow down the ASIC advantage to the point where they can co-exist with GPU and CPU miners. This can easily happen with say a 2-3x ASIC advantage vs say 100x ASIC advantage. I also believe that if the ASIC is narrowed down to say 2x this will force the sale and commoditization of the ASIC. For this reason I would consider that moving to RandomX is the correct long term course of action. Furthermore POW changes should only be made it they significantly narrow the ASIC advantage. I do not see the need for "emergency" forks. The latest was in any case as much the result of paranoia over spam bloating attacks as it was over ASICs. I do believe we could have easily have stayed the course with our regular release schedule addressing for example a lot of @fluffypony's concerns. As for a fixed schedule for a move to an ASIC friendly such as SHA-3 I an opposed; however there is nothing wrong with keeping this option were the RandomX approach fail. A little uncertainty here is a very good thing.

On another note: I believe we should strongly consider moving the mining aspects of Monero to a strong copyleft GPLV3+ software license. This is especially the case if we are considering a move to SHA-3 or have any concerns with respect to ASICs. There is simply way too much risk of patents, ASIC boost comes to mind, kill switches powered by DRM, malware, application mining etc. to remain with our current license. We can of curse keep our current license for the rest of the project including basic wallet code which would address issues such as IOS, interactions with proprietary POS and shopping carts etc.

Edit: @Gingeropolous pointed out to me that the is a configuration command to improve the CPU hashrate: MONERO_USE_CNV4_JIT=1 ./monerod. This improved the hash rate from 10 H/s to 24 H/s which still implies a hit. Furthermore it will be interesting to monitor the hashrate during the next few days as people become aware of these configuration issues.

[iamsmooth]

@ArticMine I'm not sure why your hash rate results are as they are on your hardware but as I understand it, during development one objective was to maintain relatively constant hash rate compared to previous versions on typical CPU and GPU hardware, and indeed this was confirmed through testing.

So I doubt that overall we made CPU and GPU mining 3.6x harder, but given your surprising test results, I guess we can't rule it out.

Interesting idea about licensing of the PoW algorithm. I'm not sure if that is actually possible (in that I don't know if the algorithm itself could be protected, and if not people could always reimplement it to avoid the license), but it is something that could be researched legally I suppose.

EDIT: I see from your edit that you were using the built-in miner, which indeed does not deploy by default in the most optimal configuration. However, standalone miners, which afaik, represents most of the hash rate, don't suffer from that issue. So I still doubt that the hit to the network hash rate due to the upgrade is anything close to 3.6x.

[Lafudoci]

Will the ASIC friendly algo keep entity with more fund from producing more efficient miner? My pessimistic view of ASIC ecosystem is eventual annexation and monopoly no matter how we try to make it fair at the start. And this one way ticket will likely be hold in China makes me anxious. We should not ignore China politically fights against freedom and privacy at autocratic level. Profit-driven could always turn into political-driven at any time. "Monopoly miner is not necessary to be a bad actor" should be thought twice here.

I understand current strategy could put Monero in risk, but I don't see the risk is much big from the situation I mentioned above. So I believe we should at least put resource into RandomX. If it works (means reducing gap between ASIC and CPU/GPU, not eliminates ASIC), we should adopt it soon.

But I won't say then mission accomplished after RandomX. As I said, monopoly miner will always be the a potential threat to Monero due to nature of business world, no matter we choose anti- or pro-ASIC. So we should also put some thoughts on: How could we defend Monero properties like secure, privacy, fungible as much as possible in the worst scenario? After all, that's what we aim to build and why the community assemble since day one.

[iamsmooth]

@ArticMine

I do not see the need for "emergency" forks. The latest was in any case as much the result of paranoia over spam bloating attacks as it was over ASICs

I can't agree with that. When it appears that one actor may control 80% of the hash rate, that is profoundly insecure, and is as worthy of an emergency fork as anything. Actually this is the main reason I'm very much concerned about the overall approach currently. The algorithm changing cycle is likely not fast enough to keep out all ASICs, therefore we appear to be increasing the likelyhood of keeping out all but one, which is making the network less secure, potentially very insecure.

This is an existential threat to Monero.

Previous double spend and hash rate attacks on coins such as ETC have not entirely destroyed the coin (though it is hard to measure the damage due to loss of reputation and confidence) but that does not guarantee that a major attack against Monero would not be devastating. As they say, past performance is no guarantee of future returns (or attacks).

[ArticMine]

@iamsmooth I updated my post there is a configuration issue that improves the hashrate from 10 H/s to 24 H/s, but there is still a hit. Also there may be lack of awareness of this which can impact the overall hashrate. My point is that we should properly quantify the threat and that means a proper evaluation of impact of the algo change on CPU and GPU hashrates, before jumping to conclusions. My assumption of 3.6x change may be as bad as no change.

I am not convinced that the ASIC threat this time was even close to what we say last year. 80% seems very high to me, this time around and I would not be surprised if a significant portion for the hashrate drop was mis configuration by miners and pools, apart from a harder algo. One reason is that the recovery this time around is both faster and smother.

Changing the license to GPL V3+ for the mining code will not protect the algorithm but will protect the code and consequently can mitigate against many attacks.

I do agree that POW changes for the sole purpose of keeping ASIC manufacturers of balance is unsustainable. This does not mean that we are on the wrong course right now. If we narrow the ASIC advantage down to say well under 5x, this will mean much stronger protection than simply hoping that an "easy" ASIC algo is not going to be monopolized if for example a large player simply decide ti throw resource s at it. RandomX is looking very good and even it it develops an ASIC component may end up being better than the alternatives.

[JustFranz]

The GUI/monerod miner is a joke miner. I'm getting 220 H/s with my 3770K on XMRig ( 4T x ~55 H/s) and Monero GUI is reporting 30-44 H/s total

1t - 11-14 H/s mostly stable at 14 2t 21-28 H/s mostly stable at 27-28 3t 32-41 H/s seems to be mostly at 38-39, but unstable 4t 39-44 H/s unstable in that range, dips into mid 30s

[bitlamas]

The algorithm changing cycle is likely not fast enough to keep out all ASICs, therefore we appear to be increasing the likelyhood of keeping out all but one, which is making the network less secure, potentially very insecure.

You're correct. There's a risk that one unknown actor can dominate the majority of the network when secret ASICs are introduced. This is real and should not be taken lightly. But I don't think you can assume that this will happen, or that only one unknown actor will join the network with secret ASICs for CryptoNight R or RandomX for that matter. The argument "the risk is there anyway" is valid and I don't want to downplay that. I understand and accept that the risk is there.

But if we're going to put some arbitrary weight to that risk, I think it's only fair to also consider and put in balance other possibilities. The same way we cannot assume one unknown actor will join the current network with secret ASICs, we cannot assume any ASICs will join at all. In fact, if it makes sense to make a profit by taping out secret ASICs, maybe more than one manufacturer will produce them, possibly mitigating the 51% attack possibility. Maybe FPGAs will join the network. Maybe more miners will join the network. This is all based in assumptions, because that's all we can do: make assumptions and projections about the future.

ETC recently suffered a 51% attack, but I think It's possible to argue that that specific chain is less relevant than Monero's. That argument can of course only happen if you consider that the attacker doesn't care about the future of Ethereum Classic, since Ethereum exists and is vastly bigger than the former. Monero in the other hand is not the same chain as Ethereum Classic and might be considered a chain with enough importance to not jeopardize its existence -- who knows, maybe this is the reason it wasn't attacked both times it was dominated by ASICs. This line of thinking might be supported by the very curious fact that Bitcoin Cash and Bitcoin SV both have chains that didn't suffer a 51% attack, albeit being extremely easy to attack them with existing specialized hardware currently mining Bitcoin. Let me remind you that all of this paragraph is purely based in assumptions, the same way the paragraph above this one is based on assumptions. I understand that the risk might be there anyway, and that's true.

I repeat: the possibility that one unknown bad actor might dominate the network with secret ASICs and attack it is real and should not be taken lightly. I just disagree that the best (or only) solution is to accept ASICs and the plethora of problems and attack vectors they will ultimately bring.

To ignore or to believe that these problems and social implications don't exist is wrong. The same way you have a valid point by saying that maybe one unknown bad actor can dominate the network and this poses an existential threat to Monero, it wouldn't be that hard to argue that, maybe, the whole set of problems that effectively changing a core stance of this project will bring (by prematurely embracing ASICs) can pose an existential threat to Monero as well.

[fluffypony]

@JustFranz the GUI’s built-in solo miner is a CPU miner, not a GPU miner.

[iamsmooth]

@fluffypony it sounds like he was using xmrig as a CPU miner. The problem is likely the same as what ArticMine encountered: The default mode for the built-in miner does not use JIT. This is probably dumb. Even if we don't want to use JIT for validation (which is debatable), the built-in miner should always use it. Worst case is that JIT gives the wrong results while mining and the "found" block is rejected.

[fluffypony]

@iamsmooth at the very least the JIT should be enabled by a CLI flag and not by an environment variable... :)

[iamsmooth]

@fluffypony That won't necessarily help with the GUI though

[iamsmooth]

@JustFranz if you are on linux or mac try export MONERO_USE_CNV4_JIT=1 before starting the GUI. If you are on Windows I have no idea.

[iamsmooth]

@vp1111

But I don't think you can assume that this will happen, or that only one unknown actor will join the network with secret ASICs for CryptoNight R or RandomX for that matter

If multiple unknown actors join the network that is not quite as bad as only one, but it is still a failure of the approach and still likely leaves the network in a less secure state to the extent the approach has any 'successful' effect whatsoever in discouraging ASICs and reducing their development and availability.

But if we're going to put some arbitrary weight to that risk, I think it's only fair to also consider and put in balance other possibilities

Yes, but the correct balance is the weight/probability that the strategy is entirely successful and keeps all ASICs off the network (the only possible way the approach is successful) vs. the strategy only being 'partially successful' (in fact this is better described as 'failure'), resulting in fewer or only one ASIC on the network, in which case it made matters worse. We do not absolutely know these weights, but we can observe that the strategy has repeatedly failed already, and virtually no one actually expects it to reliably succeed in the future, the only question people are debating is whether ASICs will end up developed with a six month cycle, or whether they would perhaps need an eight or ten or twelve month cycle instead (and further these all change immediately if the XMR price goes up). This is not a valid security model at all.

RandomX raises even more problematic issues, because as @hyc points out, the 'tweaking' strategy basically goes away as an option. Any ASICs which do manage to implement it (and again, to the extent we 'succeed' in reducing the number but not to zero, this is actually a failure) will probably be flexible enough to adapt to modest changes. The only way to get rid of them at that point would be fork to a very different algorithm.

[SChernykh]

@iamsmooth You seriously underestimate how hard would it be to create efficient RandomX ASIC. Yes, it can be 2x faster using the same process node but it won't be the case. RandomX ASICs will be most likely built on 16, 22 or 28 nm process node and they won't use as efficient IPs as what AMD/Intel have. Either of these will immediately put them to disadvantage compared to newest 7 nm CPUs. You guys give up too early.

[iamsmooth]

@SChernykh I haven't ruled out RandomX being a success. But I also think you have to recognize that the history of ASIC-resistant algorithms, including on Monero, has been overconfidence on the part of developers. Maybe RandomX would be different, maybe not.

Whether it does work is not the whole question though. Part of the question is what happens if it doesn't work, because I would argue we simply can not afford to be 100% or even nearly 100% confident that it will work. If it doesn't work, we are left in a nasty spot, with secret proprietary ASICs again dominating the network, no easy solution in terms of tweaking, and no preparation for an orderly switch to SHA3 (or anything else) because no one is going to build ASICs without knowing with some sort of confidence if and when they will go live.

[SChernykh]

@iamsmooth We're not overconfident, we want independent reviews of RandomX from ASIC/FPGA designers. We also can't simply be binary "it works/it doesn't work". The main question is how efficient real RandomX ASIC could be. If it's really only 2x, it's not a 51% threat.

[iamsmooth]

@SChernykh The only 'review' that counts is putting it live on a big network and having people attempt to attack its ASIC-resistance. Including when the network gets bigger because the price goes up. That's how these things work.

We also can't simply be binary "it works/it doesn't work".

Yes we can, and not only can we, we must consider that because to fail to consider both possibilities leaves a gaping hole in any sort of plan.

If it's really only 2x, it's not a 51% threat

I don't agree. Even a 2x advantage means ASICs can push out anyone with the same electricity costs and less than a 50% profit margin. That's most miners. If they are deployed in a location with cheap electricity, as they surely would be, they can easily push out just about everyone (apart from e.g dorm miners).

[SChernykh]

I don't agree. Even a 2x advantage means ASICs can push out anyone with the same electricity costs and less than a 50% profit margin. That's most miners. If they are deployed in a location with cheap electricity, as they surely would be, they can easily push out just about everyone (apart from e.g dorm miners).

I don't agree on that as well. 2x advantage means literally millions of ASIC chips need to be produced to 51%. And you'll have to organize huge mining facilities for them if you don't sell them and mine in secret. This will cost a fortune. Add very high R&D costs to this. Also add botnets/office miners (arguably a significant part of network on CPU-favoring algorithm) with free electricity which will always be more efficient. Things aren't looking good for ASIC attacker anymore.

[iamsmooth]

@SChernykh Production costs are often quite low once the chips are designed (and indeed producing more chips reduces by amortization the per-unit NRE). There are numerous reported cases where mining ASIC developers have way overproduced chips because it costs so little to do so. (They don't always turn them into working miners though, because of other-component and assembly costs.)

Huge mining facilities are not a major obstacle. These already exist for Ethereum and Bitcoin, and some tiny fraction of them (which is all that would be needed for XMR at its current size) can easily be repurposed if there is a a higher-margin opportunity (any likely ASIC developer is probably already a big miner of other coins, or has close relationships with them).

At the current hash rate and assuming 10 H/W, XMR's total hash rate now rates about 30 MW, which is right about the size of the biggest individual public mining farms.

That's not to say this sort of takeover would happen overnight, but it doesn't need to, as RandomX isn't intended as a temporary algorithm to be replaced with a fork after six months. If someone takes over the network over the course of a year, they've still taken it over, and likely in a stealthy gradual way that will avoid any sort of clear evidence that it has happened.

[SChernykh]

If someone takes over the network over the course of a year, they've still taken it over, and likely in a stealthy gradual way that will avoid any sort of clear evidence that it has happened.

That doesn't take into account that price/network can grow faster than they produce new chips. Too many unknowns. And if price doesn't grow, 51% attack will cost much more than it returns. So profit-driven 51% attacks are unlikely. Non-profit driven attacks could've happened long ago and can happen any moment, ASICs are not needed for this.

[iamsmooth]

@SChernykh The "too many unknowns" work in the wrong direction for your argument. If you want to make a security case, you have to argue why something can't or won't happen, not that it isn't guaranteed to happen.

Someone taking over the bulk of the network is already an attack, regardless of what they do next, and exactly how they decide to make use of that position (a decision which can change over time). It undermines the purpose of a decentralized network.