Closed dEBRUYNE-1 closed 4 years ago
@SChernykh - Will add that. Although, 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.
We need to re-evaluate what Zcash found. Maybe some new bright ideas will pop up.
GRIN uses dual PoW, so they seem to have resolved these issues.
The 4GB memory requirement for RandomX worries me more than ASICs. It means hosting the node would cost me 88% more, and I guess I'm not the only one. That, together with elimination of local lightweight nodes, might be a harder blow to decentralization than allowing custom chips.
The dual PoW option sounds interesting but also opens a Pandora's box of further questions; especially how to keep the ratio of different blocks.
@dEBRUYNE-1
Fairly new and untested. It thus has not succeeded the test of time.
We are planning to implement it in Wownero first, which should provide some test data.
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.
The slow verification mode of RandomX is about 3x slower than CNv2 on comparable hardware. CNv4 is also about 3x slower than CNv2 on all non-x86 platforms, including Raspberry Pi (due to missing JIT compiler). So there would be no practical difference between RandomX and CNv4 on ARM hardware.
Additionally, RandomX has a fast verification mode, which is about 7x faster than CryptoNight (but it's only usable in some cases).
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.
There is a significant difference between a 20x more efficient ASIC (like the recently bricked CNv2 ones) and a 2x more efficient ASIC. The latter has a much lower potential for attacking the network. For example, electricity prices across the world vary by more than a factor of 2, so there are already miners with this kind of advantage.
@emesik
The 4GB memory requirement for RandomX worries me more than ASICs.
The slow verification mode of RandomX requires only 256 MB.
2x more efficient ASIC is not as dangerous indeed. Just look at ETH which still stays the most profitable for most GPUs.
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.
100% agreed. This plan is infeasible, will damage Monero in the long term, and furthermore there's absolutely no guarantee that 3-4 months will be enough, if the price rises sufficiently. ASIC manufacturers are restless and always improving their methods. What if after a year or two we notice ASICs again, will we switch to a monthly PoW upgrade?
I'm actually quite astonished on the fact that this plan is even under consideration, does somebody really think that users/exchanges would like to update their software every 3 months, with a potential Ledger/exchange bug in between? Users will either leave or switch to custodian wallets, leaving to somebody else to deal with the mess of running a full node/wallet; at this point we will ponder whether our "ASIC resistance battles" have led us to a far more centralized situation.
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.
If ones make the assumption that we want ASICs to be introduced in Monero in an as fair way as possible, and avoiding the "early-stage-monopoly" effect as much as possible, 3, 4 and 5 are not optimal:
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.
I believe that will ultimately mean throwing away the big time window RandomX would've given us. The question is not if someone gains an edge, it's when and how. After a year, or two, we'll be back to discussing frequent PoW changes again. Back to zero.
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.
Assuming that RandomX works and is tested for a while, that's the most sensible way to go for the long term, and the only way to take advantage of the (hopefully larger) time window that RandomX will give us if/when ready. Ideally, this time window will be used to gradually introduce the ASIC friendly PoW share to the network a-la Grin.
I'd personally be in favor of option 3, 4, or 7. I have some reservations about RandomX though, which are as follows:
Many interesting points. I would gladly pitch in for a RandomX audit, and I suspect I'm not alone. If RandomX does not prove to be stable/optimal/whatever, things are more difficult; maybe we can make a few tweaks, all while precommiting to introducing ASICs gradually? Would something along these lines be sensible?
<pulls numbers out of ass>
Next PoW tweak (6m) , 10% SHA3
Next PoW tweak (1y), 45% SHA3
Next (and final) PoW tweak, 100% SHA3
GRIN uses dual PoW, so they seem to have resolved these issues.
Grin has resolved those issues not because they just use dual PoW, but because their (temporary) dual PoW system serves as only as a smooth and fair introduction to ASICs for the long term. To their credit, they immediatelly started thinking about this once it was clear that a Cuckatoo ASIC would be inevitable.
The slow verification mode of RandomX requires only 256 MB.
Sounds better.
How about committing to be ASIC-friendly with the block when tail emission kicks in? Approaching that goal in GRIN-like manner looks sensible, as we could watch the ASIC development during the transition time, instead of plunging into new world as proposed in point 7.
Of course, ASIC-dominated network in tail emission era brings different dangers than in mining era. Like purposeful withholding hashpower to trick people into higher fees. But there's plenty of time to spend on preparations for that moment, instead of adding another tweaks to PoW.
- 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.
i would be inclined to support this. with concerted effort (in the form of a funded workgroup) to find a manufacturer that would design and test an open hardware design.
@tevador
We are planning to implement it in Wownero first, which should provide some test data.
That will certainly improve the situation, but we can't deny the concept is relatively new and largely untested.
So there would be no practical difference between RandomX and CNv4
The difference is that CNv4 is meant as temporary stop gap, whereas RandomX is meant as a long-term solution. Furthermore, as far as I know, enabling JIT is still possible for ARMv8, whereas ARMv8 devices would take a large verification performance hit with RandomX. We also have to account for other lower end 64-bit devices.
There is a significant difference between a 20x more efficient ASIC (like the recently bricked CNv2 ones) and a 2x more efficient ASIC.
I agree, but as I said, I have my doubts about whether the theoretically claimed 2x will work out in practice.
I'm actually quite astonished on the fact that this plan is even under consideration
I think there is little support for that option, but as long as it remains an option we have to list it in my opinion.
There is a significant difference between a 20x more efficient ASIC (like the recently bricked CNv2 ones) and a 2x more efficient ASIC
Less than you might think. When joining a network at break even equilibrium, an ASIC with 20x efficiency gain has a 95% profit margin. At 2x, the profit margin drops to 50%. So the profit is about half, and the break even is almost twice as long. This is certainly significant, but not the 10x one might infer from the 20x vs 2x comparison.
The way the math works out the minimum efficiency improvement is far more significant than the maximum in these comparisons. As long as there is any significant efficiency gain and sufficient revenue, ASICs become feasible. The difference in this equation between 20x and 2x is only a 2x increase in the XMR price.
Just copying a comment I made on Reddit, to make my position clear:
I've said from the beginning that ASIC resistance is ultimately futile. As Monero grows bigger, ASIC manufacturers will get smarter and will indeed start to co-opt developers or slip their own developers into the fold. We have no way of telling if our reliance on vtnerd making changes at the last minute is at all meaningful.
There's also the very real risk of high-end FPGAs and similar (suggest you look at what NextSilicon and XTend Online are doing) which will make our changes meaningless.
I agree that geographical decentralisation is a desirable trait. So one way we can solve for this is by (1) choosing an algorithm where we can dominate the mining capacity; (2) choosing an algorithm that is easy to ASIC, is general purpose, and is easy to validate - I suggest SHA3; and (3) setting that fork date right now so that ASIC manufacturers have a few years to get their act together. By the time we go live there should be a plethora of ASICs available, and if it's something general purpose like SHA3 I can imagine motherboards building it in, CPU manufacturers adding support via an instruction set, and so on. This also gives existing miners enough time to sunset their hardware and make a profit on it, whilst pricing in new hardware, knowing that there's a time limit on how long they'll be able to run that hardware for.
We started this as a fight against Bitmain, against a single known-bad manufacturer dominating the mining space. I fully support that, but I do not support a futile attempt at evading ASICs forever, as that is impossible.
setting that fork date right now so that ASIC manufacturers have a few years to get their act together
A few years means a few years of uncertainty as to the state of the network and having it get monopolized by secret ASICs, including potentially malicious ones (we seem to have lucked out this time, in that the apparent ASIC builder didn't feel like attacking the network when they controlled 80% of the hash rate, but we can't assume we will always be lucky).
RandomX might work out for a few years, in which case great. But it might not. What do we do if RandomX goes live and there are ASICs on the network within months? Continue a tweaking strategy that is actually working against the security of the network? Speed up the tweaking cycle, to which there are valid objections in terms of stability and frequent forks? Etc.
Given that we don't have a lot of good options left, I'm not sure a firm plan to wait a few years is really sensible.
To be clear on this, I would be perfectly happy waiting a few years if what we do over the next few years actually works better than what we have been doing for the past year. Otherwise, I see dragging out the current state for another few years to be bordering on suicidal.
@iamsmooth the alternative is to switch to SHA3 in the October fork, or to switch to RandomX in October followed by SHA3 in April 2020. This leads to two questions:
Is 6 months / 12 months enough time for existing miners to be profitable enough that they're fine with it?
Is 6 months / 12 months enough time for ASIC manufacturers to spin up and produce competitive miners?
@fluffypony I'm not necessarily saying to switch at a particular time, but I'm saying that if RandomX does not work out, then we must do something else, rather than committing to stick with a failed strategy for some set period of time (say, three years).
I don't believe we can make any promises to existing miners any more than we can make promises to the community of "egalitarian mining". If it isn't feasible to accomplish (without putting the network at great risk), then it simply must be dropped out of necessity. It is a shame if this happens, but it is more of a shame if real world conditions require it, yet we deny that reality and make bad decisions as a result.
While there seems to be consensus on this conversation's primary goal being to find a way to free precious dev brain cycles from having to maintain PoW algorithm ASICs/FPGAs-resistance, thus embracing ASICs/FPGAs in the long run, the debate seems to rather be about how this is going to be done or transitionned into. And even then, regardless of the transition strategy (RandomX, etc.), I don't see two points of view being expressed here on the ASIC-embracing algorithm to be transitioned into, only one : that ultimately, the algorithm should be general/useful enough to ASAP 1) be easily implemented by large consumer motherboard/CPU manufacturers 2) be useful as to have the research in acceleration and optimization benefit the whole crypto ecosystem, not just the miners, and if possible, Monero specifically. And still, SHA3 is the only option being mentionned here, so is there consensus on that too or are there other options being investigated ? Should this conversation be divided into two indepentent ones: the first about the transition algorithm (RandomX, etc.) and another one about the algorithm that will ultimately and permanently be transitioned into (SHA3, etc.) ?
@ctrlshp there aren't a lot of options when it comes to PoW algorithms that are (1) lightweight, (2) useful in other things, (3) proven, (4) not used in any other major cryptocurrency. I'm VERY keen on hearing suggestions from the MRL!
@fluffypony My point is similar to yours: I feel that the "ultimate" algo(s) is/are on a different timeframe than the "transition" one(s) and that by forking the conversation, we will give enough time to find a "ultimate" algo as groundbreaking as RandomX as a "transition" algo. I don't know, maybe BigNumber or ECC primitive arithmetics (mod, etc.) ? I'm just saying this on top of my head as examples of where this conversation should allow itself to thoroughly investigate, with the MRL and anybody who has an idea. I might be wrong too: maybe that it doesn't matter and SHA3 could be implemented first and then there could be a permanently ongoing conversation on its eventual replacement. I don't kow for sure, I'm just suggesting. And I do think that "officially" taking the matter before the MRL and giving them enough time to think/research it through is a strict minimun.
EDIT: I just realized that I'm not assuming that it has to be a (known) hashing algo and that might not be a "natural" way to think about it. That should, IMHO, also be part of the conversation. I know that if it is not a hashing function per se, it breaks the "workflow", but can it be excluded now ? I don't know.
@ctrlshp if we're looking for an ASIC-friendly algorithm I don't think we'd want to design something, we're not a group of seasoned cryptographers who should be doing so (see: Iota's hash function fail). We'd want something that has existed for some time, has strong pre-image resistance, and is unencumbered. SHA3 is specifically designed to be ASIC friendly, per the original paper:
Its throughput for a given circuit area is an order of magnitude higher than SHA-2 or any of the SHA-3 finalists. And if you care beyond plain speed, note that it also consumes much less energy per bit. In this sense, Keccak is a green cryptographic primitive.
I would say that throughput/energy per bit (aka absolute hashrate or hashrate per watt) are not important. What's important is that it must be easy to implement in ASIC, so easy that even a startup company could do it.
RandomX might work out for a few years, in which case great. But it might not. What do we do if RandomX goes live and there are ASICs on the network within months? Continue a tweaking strategy that is actually working against the security of the network? Speed up the tweaking cycle, to which there are valid objections in terms of stability and frequent forks? Etc.
If this happens, we'd be in a hole that we've dug ourselves into. So the question should be, what strategy will get us out of this hole in the long term? Not keep digging, that' for sure. If miners get an edge earlier than expected, which is entirely plausible, their reign in RandomX will end soon anyway. It's risky, sure, but it will be a one time thing instead of something that has a chance to happen every 6 months.
Guys, you are way ahead of me. I'm merely saying that for now, there should be two conversation spaces. Because the two conversations are independent and if done in the same space, they will phagocytize each other and confuse everybody. Can we do that now and then talk ?
@SChernykh from what I can tell, GRIN did not resolve any of these issues. They had committed to a dual-PoW before Zcash began its testing. I personally do not feel confident in a dual-PoW unless new research comes out suggesting it can be safer. Until then, I think we should consider it off the table for the reasons the Zcash team presented.
If one thing is certain about switching to an ASIC-friendly PoW, we should NOT choose one where our global hashrate is a minority (i.e. SHA256). This risks any sufficiently sized pool from the larger network to launch a 51 at any time, and defeats the decentralization aspect from a different angle.
There are 2 separate issues. First, the quest for an ASIC inefficient POW - RandomX and what that means for the need to tweak the algorithm for ASIC bricking. How good is RandomX really?
Second, picking an ASIC friendly algo (which one?) and the conditions that need to be met for its orderly adoption. Are we OK with 1 or 2 companies mining Monero? Are we OK with them mining in china? Are we OK with an export ban on the ASICs? Mandatory KYC for ASIC buying? Import ban and confiscation in some countries?
What do we want the Monero ASIC manufacturing and mining landscape to look like?
There is a clear course of action for RandomX and a success condition, sort of. I don't know what success looks like for the ASIC route, seems like the current failure condition to me.
One more option suggested by hyc on IRC.
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 once ASICs appear on the network.
Trade-offs (personal addition):
Firstly, I am disapointed to see what I view as myopicism, fatalism, and incongruence in the current discussion regarding the Monero PoW.
I guess I'll start with the incongruence. I know many people came to Monero for many different reasons, so its impossible to state what everyone thinks about this. However, a common starting point for all of us is the cryptonote whitepaper. And yes, there is plenty to question about the motives of cryptonote, considering that bytecoin etc. was a bunch of scammers. Despite this visceral birthing of our beloved Monero, the people that got into Monero connected with the concepts presented in that paper.
So its important to note that even in the whitepaper, it is presented that "Our primary goal is to close the gap between CPU (majority) and GPU/FPGA/ASIC (minority) miners." They go on to further expound that "It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power. More generally, producing special-purpose devices has to be as less profitable as possible".
Therefore, I view the notion that Monero will switch to an ASIC-only PoW as completely incongruent with what can be considered the gestalt of Monero.
I will then move to fatalism. Some view it as an inevitability that the only way for a PoW network to exist when the network has grown to a significant size is through ASICs.
And finally, myopicism. Being short-sighted. We don't know whats around the corner, and everyone seems to be talking about 1-2 year timelines.
OK, well, I guess framing this ramble in those three things wasn't ideal, because I want to get into some scenarios. ( And also using sublime text, because I apparently haven't install a spellcheck plugin. )
Imagine we somehow swallow this proposed inevitability that ASICs are the only way. We switch to SHA3. A handful of manufacturers are onboard. Everythings going grand for, I dunno, 2 years. And then.
Boom.
The hashrate quadruples. Not only does some entity have twice the network hashrate. They have twice the network hashrate of twice the the network hashrate.
What happens then? Do we just go forward with "Well.... uh, the network is clearly pwned, but... lets build some more ASICs I guess"
Because at that point, we're walled in. We're an ASIC coin, and everyones bunkered in. Changing the PoW at this point is as much as an option as is to choose to breathe air.
And then to top it off, nations start blocking shipments of SHA3 asics. Hrmmm. Whats happening? Well, the code is ossified and no one will change PoW so there goes any hope of cryptocurrencies doing anything to change the world.
I mean, the problem with ASIC manufacturers is they are entirely profit driven. If someone can prove otherwise, great. And do you know what could be the most profitable for an ASIC manufacturer? Providing control of the chain to an adversary.
Lets compare this the scenario where we settle on RandomX, or some variant of RandomX that we figure out over the next year or so. Monero network hashrate quadruples. People wanting to defend the network can rent server time from, yah know, anywhere. People wanting to get in can buy computers from, yah know, anywhere. People wanting to go all out and build their own ASICs can, yah know, go ahead and do that.
I basically just can't get it through my head how a tool (cryptocurrency) that is supposed to be permissionless can have this huge gatekeeping mechanism of hardware production and distribution.
I mean, the revolution of cryptocurrency is that it enables monetary liberation dependent on ones ability to receive and transmit data. Walls for data are hard to build.
And I guess here its important to state that I feel mining decentralization is important not for some egalitarian rewards notion. I mean, yeah thats great, everyone should be able to get rewarded for contributing to the network if they want to. No, decentralized mining is more important for block creation decentralization. As stated elsewhere, if we're moving towards a network with centralized block creation, we might as well just turn into a scamcoin and get the developers to sign the blocks.
Despite my strong stance against embracing ASICs, I do recognize that specialized hardware can be made to perform operations faster than general purpose hardware. However, I wish to propose a concept that may be more in line with the original concepts that we greater fools found attractive.
ASIC equivalence.
I ask the reader to ponder the possibility that RandomX performs really well, and that an ASIC developed for it is within 1 to 2x more efficient. Is this any different than AMD or NVIDIA making a new GPU in todays market? Perhaps there are some differences - an ASIC manufacturer won't have the same infrastructure to distribute as effectively as a GPU manufacturer. And there may not be an incentive to distribute, as the Monero mining market is miniscule compared to general purpose hardware.
However, now the ASIC manufacturer is directly competing with AMD, Intel, and NVIDIA. They will have to continue to increase their ASICs performance to be more efficient than whatever the leading computational developers are creating. This market force may incentivize them to distribute their hardware, or at the very least get to distribution more quickly than they would have otherwise.
And there are factors that can increase development costs for ASICs. For instance, a growing data size (the 4 gb thing) could force ASIC developers to include expandable memory, so the end user could upgrade their memory as time goes on.
Additionally, RandomX could lead to commoditization faster than an ASIC friendly PoW, as absurd as that may seem. Motherboard developers or processor developers could create RandomX co-processors. Presumably, AMD and Intel already make CPUs.... so they are already making hardware that is a bloated RandomX ASIC. they could probably make RandomX-ASICs at some ridiculous percentage of the cost of a CPU, and get themselves into the cryptocurrency mining market.
So in conclusion, I think that if RandomX works, we should stick with it. I think we also need to consider a reality of ASIC equivalence, where a RandomX ASIC does provide a competitive advantage, but it is an advantage that is market appropriate and is exposed to the existing market dynamics. I think we need to focus on our network remaining borderless, and to do so, consider the hard truth that critical components may not exist in hardware-only forms.
Now is not the time to throw in the towel.
For these reasons and many others stated elsewhere, and as lead troll developer of Monero, I hereby proclaim that Monero continue the fight against ASIC centralization and forever speculate bananas.
(edited to undo manual 80 char lines)
@dginovker totally agreed - SHA3 is a good candidate for that, as the only coins using it are MaxCoin, SmartCash, and CreativeCoin.
@JustFranz the outcome would ideally be something like Bitcoin, where there are a host of manufacturers, and mining farms are geographically widespread. If we choose an algorithm that is WIDELY used on the Internet then there is the same chance of export bans and mandatory KYC as there is for GPUs. There's also a high likelihood that chip manufacturers will add support for the algorithm via an instruction set.
The alternative is that we keep coming up with "random tweaks" every 3 months, and ASIC manufacturers just co-opt a bunch of devs and/or insert their own devs who ingratiate themselves. The network becomes highly unstable, services like MyMonero and exchanges struggle to keep up with the changes, and people stop using Monero. We're fighting a losing game.
@dEBRUYNE-1 any strategy we come up can be gamed. ASIC manufacturers will just introduce it slowly, on public pools, spread out across individual "miners" so that it appears to just be GPUs. If we're going to precommit we need to precommit to a date so that ASIC manufacturers can work towards that. We need to stop being reactive, and be proactive instead.
@dEBRUYNE-1 why not add:
@dEBRUYNE-1 any strategy we come up can be gamed. ASIC manufacturers will just introduce it slowly, on public pools, spread out across individual "miners" so that it appears to just be GPUs.
That is indeed a large drawback. Kind of falls under the "How do we reliably detect ASICs?" trade-off I listed.
If we're going to precommit we need to precommit to a date so that ASIC manufacturers can work towards that. We need to stop being reactive, and be proactive instead.
Agree.
why not add
Sure, will add. I don't agree with "they won't be much faster anyway" though. As I said before:
These numbers are theoretical and I am not entirely convinced they will hold up in practice / the real world as well.
Committing to ASICs is capitulating to China & centralised wealth creation
Why would ASIC manufacturers EVER sell their hardware until they've mined all they can with them, until difficulty goes up enough to make their projected earnings less than the cost of the hardware+electricity?
From a game-theory perspective, the right decision is to shadowmine to maximise centralised wealth creation, then sell the hardware 'as new' when the profit projections switch from net positive to net negative, thus decentralising losses. If this sounds familiar, it's because that's basically what is happening in all modern banking and finance. Gains are centralised / privatized. Losses are decentralised / socialized.
This is the question that is at the heart of this debate: do we want to perpetuate a broken system that benefits the few, or (continue) to build a new one where the majority can participate and gain? You can tell which side I'm on, and which side the majority of the community (technical, miners, hodlers) are on.
For monero to last 5, 10, 20 years or more it must remain decentralised in wealth creation/mining, and (arguably, therefore) in wealth distribution
@Gingeropolous makes a good point that if we move to ASIC-friendly, there probably isn't any going back. Monero's reputation will most likely be irreparably harmed if we expend a lot of effort working with manufacturers to make sure that several ASICs are available, only to switch to the new algorithm.
But if something goes awry, we don't have good short-term options. Are we going to brick the ASICs that we worked with the good actors to support? Do we then fund a new community design, knowing it will take months for R&D?
Sticking to a CPU-friendly algorithm gives Monero more flexibility. We can change the algorithm to harm any bad actors without severe community consequences.
I don't think our goal needs to be able to compete with all economies of scale. People can do this today by purchasing bulk GPUs or CPUs and cheap power. While mining is supposed to be boring, the market isn't completely efficient since there is a lot of volatility. Monero's price isn't known a year from now, so ASIC creators can't invest without sizeable risk. If we take these volatility risks into account, even 2x seems like a hard sell, at least for some profit-driven actor attempting to control the entire network. Even if they exist, the network can still be healthy. And if it's a malicious actor, they will have less relative advantage to normal hardware.
I totally agree with @Gingeropolous
He got all my concerns explained in a single post.
@fluffypony Aren't FPGAs already rampant on SHA-3? I know this has been discussed heavily among the coins that have implemented Keccak. Is it a smart move to put the safety of Monero's network into the hands of FPGA owners? Is it not antithetical to Monero's original intention that one would need to acquire a $5,000 piece of equipment and pay a developer for a private bitstream, just for the opportunity to contribute to Monero's decentralization?
@Gingeropolous I really don't think we should EVER claim "but the whitepaper says" unless we want a Bitcoin SV scenario. Let's PLEASE put that aside. We absolutely DO NOT need to do what the whitepaper says. There are multiple claims in the whitepaper that Monero has never had from its outset, and multiple claims that no longer apply to Monero.
I hear your concerns about possible outcomes, 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 am also deeply concerned that we are largely unqualified to be designing our own hashing algorithms, and we're going to end up with egg on our proverbial faces.
If we end up committing to RandomX and then ASIC manufacturers are able to get significantly higher performance improvements than we expect, that is when "Monero's reputation will be irreparably harmed", to quote @SamsungGalaxyPlayer. Do we have any clue if RandomX is strongly resistant to pre-image attacks? I feel like we're playing in a pool reserved for very experienced cryptographers, and it's not going to end well. I'm concerned that the only reason we haven't had an incident thus far is because we change things too often for anyone to really be bothered to analyse the algorithms.
@moracha doesn't matter if they are, none of those coins are worth enough for an ASIC to be made. If ASIC manufacturers have a two year lead they will produce ASICs that are orders of magnitude better than existing ASICs. As mentioned, SHA3 is specifically designed to be easy to ASIC.
We can change the algorithm to harm any bad actors without severe community consequences.
I don't think we can realistically execute this strategy. You're essentially arguing for further tweaks, which has shown to be a rather futile and potentially dangerous strategy.
even 2x seems like a hard sell
To reiterate, I have my doubts about whether the theoretically claimed 2x will work out in practice.
Even if they exist, the network can still be healthy.
Only for so long though. A miner with as significant advantage will eventually push out most other miners.
fwiw I also agree that we don't need to do something just because it's in the whitepaper. That's dangerous. However, I agree that CPU-friendly mining is an important part of the Monero ethos. This can change, but I understand why people (often myself included) like to hear about solutions that attempt to maintain this property.
@iamsmooth
Less than you might think. When joining a network at break even equilibrium, an ASIC with 20x efficiency gain has a 95% profit margin. At 2x, the profit margin drops to 50%. So the profit is about half, and the break even is almost twice as long. This is certainly significant, but not the 10x one might infer from the 20x vs 2x comparison.
It's not so simple, you have to also include the R&D costs and the manufacturing cost per device. Price of electricity will be the smallest expense of these short ASIC runs.
@fluffypony
Do we have any clue if RandomX is strongly resistant to pre-image attacks?
RandomX is not a hashing algorithm. Internally, it uses a cryptographically secure hashing function (Blake2b), so unless that is broken, there is no doubt about pre-image resistance. It's important to distinguish between the work and the proof that together make up a PoW algorithm. This was explained by hyc here. RandomX is only the "work" part. The proof itself is given by a cryptographically secure hash.
Hi there, sorry if I disturb. What if we try to think about the POW not as a formula, but as a task for AI. Like for exsample: win a game in GO or solve a riddle in a virtual world...
SHA3 is a good candidate for that, as the only coins using it are MaxCoin, SmartCash, and CreativeCoin.
Pretty interesting. SHA3 looks like an ideal ASIC-friendly PoW. Standardized, high security margins, much more efficient than BLAKE2, Skein etc. in hardware. And not picked by a coin with substancial market cap, yet. What more to ask?
@fluffypony , yeah I did not mean to do a "but the white paper said" thing. I tried to couch it appropriately, I guess I failed. And I don't want to do that either, because of the whole bitcoin SV type thing.
I guess my point was is that what held 5 years ago also holds now. That this discussion is not new. Things, unfortunately, really haven't changed. There's no ASICs at my local bestbuy, there's not a healthy market of ASIC competition, etc. ASICS, IMO, have failed the cryptocurrency movement.
It's true, we can say Monero has succeeded where others have failed (a functioning fungible currency network, shoe-string budget bootstrap development)... I just have real reservations about Monero's ability to single-handedly change the ASIC landscape. I feel that the machinery is different between these two things.
Maybe I'm wrong. Maybe the greater fool mentality can win in this arena as well. If we choose to go down this road, I sure hope it does.
I hear your concerns about possible outcomes, 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 disagree. I think Monero creates a different scenario than Bitcoin.
I am also deeply concerned that we are largely unqualified to be designing our own hashing algorithms, and we're going to end up with egg on our proverbial faces.
I'll admit that I'm no expert, but as stated by people that may be more expert than me, randomx doesn't fiddle much with cryptography. Though to your point, I agree that a lot more resources should be put towards RandomX development if this path is chosen.
Things, unfortunately, really haven't changed.
I think that is myopic to say. Whilst ASICs have not been commoditized yet, the ASIC (manufacturer) ecosystem has vastly improved in comparison to a few years ago. A variety of manufacturers now exists including manufacturers not based in China.
I think that is myopic to say. Whilst ASICs have not been commoditized yet, the ASIC (manufacturer) ecosystem has vastly improved in comparison to a few years ago. A variety of manufacturers now exists including manufacturers not based in China.
Has a single one of them ever put the network before their profits?
What constitutes putting the network before their profits?
Has a single one of them ever put the network before their profits?
PoW works because it gives economic incentives for actors to secure the chain and to compete while doing so. 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.
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.
1) 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?
2) 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?
@antanst the fact that Bitcoin survived its early years when it wasn't even worth 1 cent proves that statement false.
What constitutes putting the network before their profits?
I guess focusing on distribution of their product. Maybe making products that did more than just hash... like store the chain, speed up some other parts of the code, anything to actually support the infrastructure as opposed to just milk it.
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.
I guess all of the developers that aren't paid for their work on monero are just stupid then? Its OK to be goodwill driven for one aspect of network security, but not the other? And the first 3 years of monero mining was an illusion?
I gotta admit. I'm starting to feel this again
https://media.giphy.com/media/NPyHgTkMStCXC/giphy.gif
Call up Gordon Gekko. After 5 years of toiling, we've once against discovered that greed is good.
I'm sorry. I've derailed this discussion. Lets get professional again. We got Billy in Marketing coming up with a whizbang promotion for Monero-sanctioned ASICs yesserreee boy, these bad boys are gonna be lickity split top-o-the line. Airdropped from moon hellicopters they'll be. 100% market driven, no hopium ever. Realistic, chart-proven market saturation ballistic humdingers they'll be.
I think I'm sleep deprived.
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:
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.
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.
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.
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.
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.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.
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.
Explore a GPU centric algorithm.
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.
Game Theoretical approach to ASIC resistance (proposed by MoneroCrusher).
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:
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.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.