Proposal to consider an ASIC-friendly proof of work #3387
Comments
|
Points for ASIC-friendliness: ASIC manufacturing will see more competition, halong mining is already competing with bitmain, and their defensive patent group is promising. There are no ASIC botnets. ASICs are worthless the day after they carry out a 51% attack. Merged mining with bitcoin would means that monero does not have to compete in the same way for the same electricity and capital investment in mining equipment. Points for ASIC-resistance: CPUs and GPUs are more difficult to ban than ASICs the silicon foundries which produce ASICs are quite centralized Merged mining with bitcoin right now would increase centralization pressure on bitcoin mining from the increased cost of node operation. |
|
I propose a process that can satisfy many of these concerns: using a sound game theoretic strategy for ASIC resistance. In my proposal, this would continue the current 6-month release strategy, but would also include the following:
This process would allow for openness in discussion of future direction and would allow for greater trust by the community in the stability of upcoming releases. (i.e. No more "last-minute" POW changes.) And its use of the random strategy will negate any serious investment in ASIC development as means of dominance. This process would not address botnets, partially effective ASIC exploits (discovered post-release), or the need for "industrial scale mining". Please let me know if you think this might be viable. |
|
If you would like something that "...not only can reasonably be implemented in an ASIC, but which minimizes barriers to creating ASICs, minimizes their costs, facilitates the development of a wide range of compatible hardware at attractive price points, and minimizes opportunities for clever proprietary advantages." then why do you immediately disregard SHA256 and propose SHA3? |
|
@jwinterm I'm not an expert on this but I've seen various credible claims that SHA256 is not a particularly ASIC-friendly algorithm by design, due to both its internal complexity and susceptibility to various clever optimizations. This has allegedly contributed to the rather less than competitive Bitcoin ASIC market, since barriers to designing competitive SHA256 mining ASICs are higher than they otherwise need to be, and there are too many opportunities to gain an sustainable advantage with proprietary tricks. But who knows, this may be a bogus claim. SHA3 may or may not be better, but in any case that was only intended as an example which is somewhat more modern by design than SHA256, avoiding some of its pitfalls (for example, length extension attacks, though that in particular may not matter much to PoW). There may well be better choices, but the particular choice of algorithm that seems somewhat of a diversion from the core question of whether ASIC-friendliness is useful goal and then defining the selection criteria. |
|
@SRCoughlin While your idea is good in theory, I'm not sure about its feasibility in practice. It is hard enough (and may fail) to produce even one well-vetted and carefully-implemented alternative/modification without screwing it up (see #1 in the original issue), much less several. |
This is true, and I think ultimately it's futile to try and constantly fork away from ASICs. The original idea of cryptonight afaik was that it was somewhat equivalent between CPUs, GPUs, and theoretical ASICs, and I think trying to meet that original vision is probably more realistic than trying to constantly fork to prevent ASICs from mining on the network. |
That's somewhat getting at the core of the intended topic of this issue: Is that still considered a useful goal, and if so, is it feasible in practice? If it is useful and feasible, how should it be done? |
That's non sense and a non issue, those foundries are the EXACT SAME that fab out the chips for NVIDIA and AMD. NVIDIA and AMD don't seem to be able to scale their productions due to the same issues BTC ASIC factories have atm. This discussion should have been had in detail way before merging in this untested and unreviewed PoW change. Using SHA3 or our bastard child of keccak we currently use for the PoW has the advantage that we do not need to implement another unrpoven crypto library besides what we already have. I dont think merge mining with BTC makes any sense as i do not think that the same HW should be used for both coins, it gives BTC maximilaists easy access to attack our network. The whole securing multiple billion dollar networks using a bunch of hobbyiest miners that can easily overtaken renting some AWS instance is a pipedream to me. So far it seems mostly mined by botnets and shitty JS webminers that steal other peoples resources and can dump them at whatever price because they were essentially free anyway. |
|
First of all I strongly favor this conversation. One of the notable outcomes of ASIC resistance besides botnets have been browser miners. One side effect of dropping the ASIC resistant stance would be to greatly diminish if not eliminate the use web miners both being used nefariously but also in the open like Salon.com etc. |
|
The community has opposed the use of ASIC miners due to the nature of centralization that this entails. If ASIC supporters should wish their implementation, it stands to reason that this case be addressed. (Counterexamples of botnets, Salon, etc. are likely not going to convince the community.) |
|
No matter what, we should fork away from these current ASIC's, rewarding them is not a good idea. |
|
Perhaps the Monero Project should fund the development of its own open source ASIC design. It could also manufacture ASICs and commit to selling all of its chips retail. |
|
@metamirror Interesting. Consider: the community creates a number of new POW algorithms and, in tandem with development and testing, openly releases the VLSI designs for FPGA/ASIC (even MPW?) to go along with each (every?) algorithm. After the RNG, miners can either coordinate bulk purchases through the community, or use the VLSI to fab an independent run of chips and create a custom ASIC. The beauty is that in 6 months the next network release (hard fork) would choose another algorithm by RNG, negating the processing advantage of the existing ASICs and requiring new VLSI designs. This would allow for full ASIC implementation to anyone's content, yet this would also be limited (by the random strategy) to be economically viable for only a small number of miners. Hence, it would be predictable and controllable, and, should any of the above criticism prove valid, could provide reason to delay the given POW algorithm change schedule to avoid issues. This would be, in essence, a completely open source anti-ASIC strategy and unlike anything attempted before. |
|
@otheATgh Numerically I think renting a bunch of AWS instances is really not a viable attack. In terms of naive cost estimate, perhaps it is feasible, but while AWS may have a million or more high end CPUs or GPUs to use for this (or an even equivalent even-larger number of small ones), actually renting that many at one time is not trivial at all, and may be totally infeasible. It means you are competing with their other customers, some of whom are not particularly cost sensitive in the short term (the don't want their enterprise computing shut down so you can attack a network for an hour). Setting aside Amazon KYC-ish requirements on large capacity demand (they want to see justification and also that you will not disrupt their service), let's look at some numbers. A high end AWS node generates something like $10000/year revenue if rented long term and $4-5k/year if rented on the spot market. AWS total revenue is something like $20 billion/year not all of which comes from instance fees (some from storage, bandwidth, value-add services, etc.). If it were all high-end node instance fees which of course it isn't, the entire company would only be 2 million nodes, and you would need need to pull something like half of it to pull off an attack which you won't be able to do. This seems implausible. Even combining other providers it seems far from easy. You are significantly underestimating the strength of the current 'hobbyist miner' network (though it isn't really that, there are definitely some large scale miners) and the difficulty of renting very large amounts of resources from cloud providers (particularly for short time which they will find disruptive and not allow) in practice. Nevertheless, given potential price drops, emissions reduction over time, this may become an issue. Also, Ethereum GPU farms have far more than enough capacity, if they decided to be become Ethereum-maximalists doing the attacking instead of the Bitcoin maximalists you mentioned (or just underutilized after Ethereum PoS). |
I don't think the Monero project wants to be a point of centralization on the design and manufacture even if they are being sold. The issue isn't only who is building the miners, it is that someone is doing so and has a lot of control over the market (who gets miners, how many, when, and at what price). Possibly an open source design could make sense, but I don't know enough about the realities of the ASIC design and manufacturing marketplace to know whether this is useful. More generally (not referring to miners here), I see a lot of people talking about 'open source hardware' and not that many actually doing it, particularly at the ASIC level. |
While software experience is highly portable and abstract, hardware requires EE skills, which are much more time-consuming and particular. Very few EEs donate their time to open projects.
I do, but donating time for EE work would only make sense as a means to an end. In other words, there has to be very specific reason why EE work is being done. The abstract ideal of decentralization may not be enough to justify this. As an example of the EE work costs, I give you the (very high) fees associated with the optimal GPGPU code for Cryptonight POW algorithms. In fact, I'm wondering now if including a (much lower) fee in the POW algorithm and VLSI code would allow for FFS bounties for their own development. This could be interesting, but might also create a conflict-of-interest with the EEs working on these very designs. |
|
(sorry closed by accident) @SRCoughlin "Very few EEs donate their time to open projects" Donating time and open source are two different things. A very significant portion of Monero development has been paid for.
The entire purpose of a decentralized cryptocurrency project (indeed the entire purpose of cryptocurrencies at all) is decentralization. It isn't just an abstract ideal, it is at the very core of the mission statement. My view is that ASICs only make sense if there is an expectation of a commoditized market developing in a reasonable period of time. That hasn't happened with Bitcoin at all, but maybe it still will. Unless we have some alternative approach which does get there (and at a much smaller scale than Bitcoin might get there), then I would consider the answer to this issue to be in the negative. |
This makes the most sense to me. While the crypto community always admonishes "don't roll your own crypto" I think it's important to highlight that goals of a PoW hash function don't align with the goals of a typical cryptographic hash function. Most hash functions are designed for efficiency of implementation and execution. (Password hashes may be a notable exception to this goal.) We want something that is equally difficult for CPUs, GPUs, and ASICs. AFAICS this means we want something that is branch-heavy, where multiple branches are all equi-probable. That would defeat CPUs' branch predictors, and GPUs are already poor at branchy code. We also want something that is comprised entirely of serial data dependencies, to defeat any CPU instruction-level parallelism. And we want something that cannot be simply reduced to a compact set of lookup tables. I don't think it'd be hard to come up with such a design. |
|
@hyc The cryptographic soundness (at least some aspects of it) is extremely important otherwise the algorithm can be analyzed and shortcuts found which avoid the need to execute some or all of the (branch-heavy, etc.) code you initially assume is necessary to search the space of possible solutions. That said, something that is both cryptographically sound and better tuned to the needs of PoW (in particular, ignoring efficiency of execution, good point there) is probably possible, but I'm not sure "not difficult". In a sense all previous attempts at ASIC-resistant, GPU-resistant, memory-hard, etc. PoW have been that, and most if not all have failed in some aspect or another. Cryptonight has held up better than most, in terms of maintaining a balance. Also, I'd guess that intentionally defeating things like instruction-level parallelism in CPUs puts them at a big disadvantage to ASICs and possibly GPUs since those will employe parallelism in hardware (unless there is some method proposed to limit or prevent it, such as a very large non-optimizable scratchpad). To maintain parity, CPUs probably need to take advantage of their accessible parallelism too. |
|
Linking because it is worth reading. I don't necessarily endorse every aspect of it, but I endorse (strongly) at least being familiar with the document :) |
|
Has there ever been a hybrid PoW scheme that combines an ASIC-unfriendly function with an ASIC-friendly one? I am thinking of a scheme whereby the first stage of the computation uses an ASIC resistant algorithm, with its output being passed as input to the second stage, which uses an ASIC friendly algorithm. Miners could earn block rewards for performing either (or both) stages. Consider a bad scenario: a botnet controls a disproportionate amount of the hashrate and/or ASIC farmers do the same. The botnet could never compete with the ASICs on the second stage, but the ASICs would have difficulty competing with botnet on the first stage. Some separation of hashing power would exist, similar to a bicameral legislature. All Google showed me was hybrid PoW/PoS schemes, so I haven't been able to find anything similar to the one I just described. If someone knows of one, please let me know. |
|
Please pardon me lobbing up out of nowhere and leaving this here. Please keep in mind that I'm speaking from ignorance(or at best only small knowledge), so I could be barking up the wrong tree entirely. Or possibly just barking. What if the two-part algo has some kind of requirement that the same hardware can't do both parts? |
|
Having worked on compilers, optimizers, auto-vectorizers, and the lot, I'd say it's harder to write optimization-friendly code. But it's a heavily studied field by now; we can look at any guide to optimizing code for parallelism, and do the opposite. And what we use can of course start with a cryptographic hash (like Keccak/SHA3) on the front, to decorrelate the intermediate data from the input. After that it's just an issue of making sure nothing we do cancels itself out. |
|
For me, the problem with an ASIC friendly PoW is that you can never beat the economies of scale that ASICs provide. So even when ASICs become commodified, and every phone has an ASIC because reasons, and lightbulbs and toasters because you have to hash for service, we may have achieved an egalitarian access to the hardware, but we may not have achieved egalitarian access to the nonce space. When I first encountered Bitcoin, it was post-ASIC. I read about it, saw the mines, and concluded that Bitcoin had already become, and would continue becoming, just another space where the Rich get Richer and the everyperson is forced out. And because ASICs breed centralization, it seemed to me that Bitcoin had failed in its primary purpose - being decentralized. At first, I didn't get into Monero because of "the privacy". I got into it because the egalitarian PoW aligned with how I understand decentralization. Finally, I think ASICs give too much power to the miners. Yes, I've read the logic that "well the ASIC can only be used to mine that coin so therefore the miners will always support that coin and their intentions are good" but we shouldn't care what the miners support. The miners get rewarded for providing a service to a decentralized network, where the value is completely dependent on the extent of decentralization. The network is not rewarded by the service of the miners. |
I've completed reviewing this document. It is either incorrect or inapplicable in every claim. While it may have some important information about efficiency when it comes to SHA256 algorithms such as Bitcoin, there is nothing to be learned from it when it comes to Monero and its POW algorithms. My critiques are as follows:
Incorrect. ASIC resistance costs labor primarily (designing VLSI, etc.), as ad-hoc production runs of chip fabrication are common now. Capital outlay for the run is not a concern.
Inapplicable. It is possible to create algorithms which surpass the economic feasibility of ASIC design within the timeframe of change in POW. If it's not profitable, there is no incentive.
Incorrect. This is happening right now.
Inapplicable. As above.
Partially applicable, but only as for certain implementations. Say, Arduino or other small devices.
Inapplicable. As above.
Incorrect. Testing and optimization can reveal these issues. See Cuckoo Cycle as an example. |
|
@SRCoughlin Cost of labor to design is a capital outlay. Someone is paying for the labor long before revenue. That investment is a form of capital. Yes the document takes the position that effective ASIC resistance is impossible. That may or may not be correct in practice, but the idea that ineffective ASIC-resistance may make matters worse seems valid to me. @Gingeropolous "but we may not have achieved egalitarian access to the nonce space" I don't see how this is ever possible, outside of some sort of KYC for mining (and not even sure how that would be done in a decentralized manner). Even if you can mine on a laptop, nothing prevents someone else from using two laptops and therefore having access to twice the nonce space, right? |
|
IMHO, the issue is that ASICs currently are very centralized. If there were ASIC products on the market with fair competition then there would be no reason to be ASIC resistant. Currently that's just not the case. The problem is, whilst there is this path of ASIC resistance, what incentive is there for anyone to develop ASICs for Monero mining; zero. It's a double edged sword (or rather chicken and the egg scenario). We either let the current players develop ASICs for Monero and accept it will be centralized to some degree for a period, or we resist, which deters possible ASIC development and competition in the market. I guess I feel a good end-state is multiple ASIC producers, as then ASICs become commoditized, and there's nothing bad about that (hardware the masses can use to mine at commodity prices with better margin, r.e. electricity cost & hardware cost / return). Let's be honest, mining is already centralized to some degree. GPUs (AMD and Nvidea) and CPUs (really just Intel by the numbers). The price of these, which were once commodity hardware, have been growing due to demand. Ultimately I feel mining has to be profitable for the masses. If ASICs make it more profitable for the everyman then great. If there is no profit in mining at all then what's the incentive; ideology alone? Independent miners is more decentralization, which is the ultimate goal. In summary, I think we are not yet at a place where there is sufficient ASIC competition, and thus decentralization. But to some degree, by being ASIC resistant, we contribute to the problem. I'd welcome a world where there were more ASIC manufacturers that current GPU/CPU manufacturers! This may be the future! |
|
I'm not sure a competitive/commoditized market for ASICs will ever make sense. CPUs and to a lesser (but still some) extent GPUs have the markets they do not because of the manufacturing (which is at least as centralized), but because they are general purpose products which lends itself to having many disperse and competing distribution channels. In most even mid-sized cities you can find multiple stores where you can go and and buy CPU and GPUs both as individual components and as part of a system. Plus of course on-line from both many resellers and manufacturers directly. There are thriving gray market channels (probably actual black market too, thinking about hijacked shipments, etc.), a robust and deep used market, etc. None of this really exists for mining ASICs (just as it doesn't exist for other forms of ASICs) and may never exist, because it is far more specialized (er, "application specific"). It is natural to have a narrower and more structured distribution system which in turn naturally lends itself to a higher degree of centralized control and vertical integration where efficiency trumps reach. Though I guess it is possible to envision enough diversity among types of miners that there might be value in broader distribution (if so, then one likely needs to accept 'hobbyist miners' as an important part of the system). Still this doesn't change the fact that unsuccessful ASIC-resistance (which some argue is inevitable) may still be worse than ASIC-friendliness. |
|
@tevador
which seems to correspond to the following description in NPPoW's README:
I don't see the point of this "final PoW" because the work is not targeted at producing small hash values. Doesn't it suffice to include only the nonce and its corresponding solution in the block? |
The PoW hash is not included in the block. It's calculated to check if the block meets the required difficulty. The NPP solution is not a hash and cannot be used as one. In order to keep the difficulty targeting mechanism, a random 256-bit value must be produced at the end. Another option would be to set the difficulty by adjusting B (the number of bits), but this has low granularity (difficulty could be adjusted only in approximately powers of two), so it could skew the block emission frequency. Also pooled mining would be very difficult if not impossible (how do you define a partial solution?). |
|
If we’re worried about mining centralization, why aren’t pools demonized as much as ASIC manufacturers? Almost all of them are Stratum based, not getblocktemplate, and Stratum pools can forge malicious blocks without the pool users knowing or approving. IMHO few people really care about decentralization or they would force pools to use getblocktemplate instead of Stratum. Let’s be honest: most people just want to make “easy” money at home and they tout “decentralization” as a moral excuse. Getblocktemplate puts more work on the client which means less money, and clearly home miners have chosen money over “decentralization.” Anyone crying about “decentralization” while pointing their home rig to a Stratum pool should STFU and just admit it’s greed that drives them, not some abstract democratization principle. So really, why should we be worried about whether a PoW is useable in a pool? Shouldn't we design one that's NOT useable by pools? |
|
the original protocol was getwork, but was replaced... ...many years later: BUT... what avoids a 51% attack is Not the pool, is the Node wallets, if 99% of the miners are in 1 pool, and all miners have light wallets = just 1 Node Wallet, Mining Decentralization is Bad for small miners, where do i start? to copy books was slow, by hand, a lifetime work, when technology has advanced enough, Decentralization happens Naturally, for example the Earth, technology is Not advanced enough, Humans are Centralized in 1 planet. Decentralization allows survival. Economy, is Not advanced enough, is Centralized by Banks, by government, but there are other Centralized vs. Decentralized problems, "layers" inside the Decentralized Economy, a proper Decentralized algorithm will give equal opportunity to CPU, GPU & ASIC, or FPGA and other pools, Bitcoin is ASIC centralized, if price is high, but popularity is Not enough, they could develop a secret faster Miner, and use it, Not sell it. The goal of Decentralized Economy is to allow Survival of the Economy, anything that goes against Decentralization is wrong... anyway... e-coins price is "down" now, because 3 reasons, traditional economy is strong now, and most e-coins were centralized by few miners & pools, most had 10k coins, those people are dumping the coins in the traditional economy, lowering the price more... Bitcoin was Not mass adopted by small daily economy, because 21Million coins are Not enough, making too much decimals, and transaction fees too high, also waiting lines too long but thats another story... solving 1 problem with another, few coins, high fees, long waiting lines with assumed valid blocks, pruning & segwit. each wave ripple, ecoins will become less & less centralized... https://mining.bitcoin.cz/media/download/mining_proxy.exe |
Oh, I thought the idea was to adjust the difficulty of NPP according to the network's compute power and replace the current hash-based PoW with it. In other words, is your idea to change the current scheme:
to something like this?
So, the difficulty adjustment will apply to these two places (NPP and hashing)? How should it be done? I'm new to this idea. Or perhaps, the difficulty of NPP is fixed?
How about fixing B and adjusting N? AIUI, decreasing N seems to make the problem harder progressively.
I see this as well, which is also true with Cuckoo Cycle (a relevant post on Monero StackExchange). |
|
I think you misunderstand how pool mining works.
Pool miners calling getblocktemplate doesn't make sense at all; this PRC is called by the pool operator against the operator's node with the operator's wallet address as the (only one) argument. Each time a new block is found, the operator receives the block reward in full, and pays out to the contributing miners later. If a pool miner were to call getblocktemplate with his own wallet address as the argument, he is effectively solo mining. Pool mining works by having many miners work on the same block template.
The basic assumption in any cryptocurrencies is that all participants are greedy and will cheat/attack the system if they can. The whole point of our effort is to eliminate the possibility of cheating and make the adherence to the same strategy optimal for everybody w.r.t. financial gain. We seek for decentralization because it's fundamentally valuable, not because it's moral. IMO, pool mining by itself is not a problem as long as miners are reasonably spread out, which is quite a different kind of question. |
|
@stoffu |
|
So it's probably different in Monero. I'll humbly admit very little knowledge of what a Monero block looks like. But GBT vs Stratum for the majority of coins, you are way off base. |
|
Maybe this is our misunderstanding: you're talking about the pool operator calling GBT on the daemon, building the block, then using Stratum to broadcast to miners. This is a bastardization of what GBT is about. I'm talking about the original purpose of GBT where it was meant to be a pool protocol for mining clients so that pool operators wouldn't be able to effect a 51% attack containing malicious transactions. |
|
Oh yes, I was assuming you were talking about the Monero daemon RPC of the exact same name. I was unaware of this GBT protocol in Bitcoin which seems to have never been implemented in Monero AFAIK. Indeed, this type of pool can be helpful for decentralization.
I'm also largely ignorant about how exactly Bitcoin blocks look like, but apart from the vast differences in the individual transactions' format, the basic structure of blocks should be mostly the same between Bitcoin and Monero in my understanding (merkle root, prev block id, difficulty, timestamp, nonce, etc). |
NERVA, Blur and Turtle coin are 3 projects that are experimenting with mining without pools. |
What is your point exactly Tim? |
|
@timolson I'd love to hear your thoughts on this https://medium.com/@turtlecoin/introducing-cryptonight-soft-shell-2c2d4c497efd |
Yes, that was the original idea. The difficulty of NPP would stay fixed with B = 42 and N = 128 and just the hash threshold would change. Cuckoo cycle actually uses the same mechanism (with a SHA-256 hash of the cycle solution).
Adjusting N would also work, but the dependence of NPP difficulty on N is more complex (for example N also affects the value of the critical ratio and size of the search space). For a fixed value of N, the difficulty would be simply proportional to 2B. The only problem is that with a high enough B, 64-bit integers are no longer enough and CPU performance would drop sharply. Third option would be to adjust both N and B to set the required difficulty.
Someone could argue that pools help decentralization (up to some point), because most small miners wouldn't consider solo mining viable. Without small/hobby miners, it would be just big GPU farms who would mine. The fact that existing Monero pools are stratum pools is a different point. |
|
@FromMeanas There are ways to prevent pools from being malicious even if they have >50% hashrate (getblocktemplate) so as long as we’re talking about PoW and ASIC’s, I thought a quip about pools and pool support was germane. @LordMajestros This doesn’t mean I’m against distributing mining power and coins. Maybe pools are a necessary evil just like ASICs. |
|
@timolson Bitmain really did bring this problem on themselves, and it isn't fair to disparage those who are reacting to it by calling them greedy. Sadly, I am going to have to stereotype here, but there is no way around it. I've lived in Asia for more than 20 years, and Chinese companies just don't see the world in the same way as we do in the West. In their eyes, things like insider trading, giving mining equipment preferentially to their friends, etc. is not necessarily wrong. That is not to attack the Chinese. Westerners have customs that are equally bizarre. But I will point out that Bitmain has never been fair in the Western sense of the word when selling devices, and people are now naturally suspicious of every mining equipment manufacturer due to this. The same is not true of pools. When a new pool starts mining, it is quite clear. When a much more efficient ASIC unit comes on line however, it can be disguised such that it can only be seen in hindsight as the difficulty level slowly creeps up. And those who have early access to the miners are very adept at keeping it under the radar for a while. Until your new vision of a Utopia comes true, where there is a large group of competitive mining manufacturers that are all competing fairly during the day and singing Kumbaya together at night, you need to be a bit more open minded about the feelings of the community. This isn't solely greed. The emotion of fear plays a very large role here as well. |
|
@timolson People have definitely expressed concerns about pool centralization but it is hard to solve. GBT was not a solution because its usage isn't enforced and neither an individual pool nor an individual pool miner has any incentive to use it. Their individual optimization is to stick with stratum. For a pool decentralization solution to work it needs to be enforced (or at least properly incentivized) at the consensus level and also avoid or address various work-arounds and cheats/semi-cheats that people have come up with or will come up with. It's not easy, but a good solution that avoided too many negative unintended consequences would indeed be valuable. |
|
@LordMajestros |
|
A relevant discussion currently occurring here: |
|
This seems to have been decided against when Monero was upgraded to RandomX. Propose to close. |
|
Agree, it can be referenced in a new issue if we need to have this discussion again. |
|
@selsta Wrong type of closure: The correct one is closed as not planned. |
|
ASIC Friendly Monero = Old algorithm = XMC XMC for Android works ok, its a forked light weight Monerujo wallet. has too many deprecated functions. |
and others
Currently Monero is pending a hard fork to modify the PoW in order to invalidate existing rumored and reported ASIC designs, and in addition to continue making such changes repeatedly to attempt to prevent ASIC development and deployment on the network. For various reasons, there are longer-term concerns with this strategy, particularly going forward, including:
For these reasons I would propose that we consider (which does not necessarily mean implement) abandoning the ASIC-hostile approach and instead consider adopting an ASIC-friendly approach in a future hard fork.
By ASIC-friendly, I mean something that not only can reasonably be implemented in an ASIC, but which minimizes barriers to creating ASICs, minimizes their costs, facilitates the development of a wide range of compatible hardware at attractive price points, and minimizes opportunities for clever proprietary advantages. By doing so we may maximize the likelihood of a competitive ASIC market developing and minimize the degree of (temporarily or sustained) monopolization. This could possibly be achieved by using a simple, well-known, and well understood algorithm such as SHA3.
There are numerous other potential advantages and disadvantages of this approach relative to Monero's current PoW algorithm and strategy, which can be discussed in comments.
Postscript: My personal view has always been largely ASIC-hostile (primarily based on my analysis the history of the Bitcoin ASIC market when Monero launched in 2014, but reinforced by the continued evolution of the Bitcoin and other coin ASIC markets over the past four years), however I am open to the possibility that unintended consequences of attempting to maintain this approach may cause more harm than overall benefits, in which case it should be dropped.
The text was updated successfully, but these errors were encountered: