ASIC resistance

[tarrenj]

Bitmain will begin shipping the Z9 Equihash miner soon. Let's use this thread to discuss ASIC resistance: Is it something we want to spend the time/resources to continue, or should we embrace ASICs? Staying ASIC resistant will likely require multiple updates in the future as ASICs progress, and would currently require updates to the core software, pool software, and mining software.

X16R and MTP have been mentioned several times, though the specifics of them have not yet been investigated: https://github.com/zcoinofficial/zcoin/wiki/What-is-MTP-(Merkle-Tree-Proof)-and-why-is-it-an-ideal-Proof-of-Work-algorithm%3F https://github.com/ethereum/EIPs/files/1861292/X16R-Whitepaper.pdf

NeoScrypt is another interesting option, again, it has not been investigated as a potential Equihash replacement for ZenCash: https://github.com/ghostlander/NeoScrypt

Interesting information: https://github.com/ethereum/EIPs/issues/958 https://forum.z.cash/t/let-s-talk-about-asic-mining/27353 https://github.com/ZcashFoundation/Elections/pull/1 https://github.com/amiller/Elections/commit/d0820571a359f682e519d89375dc162570361cd2 https://github.com/BTCGPU/BTCGPU/issues/308

There is also interesting discussion taking place in the #general and #mining channels of the ZenCash Discord: https://discord.gg/zTd7C5

This is not a ZenIP, just a thread to continue the discussion. Please ignore typos until I can edit them out, as I'm on my phone...

[aleqx]

Moreover, if you wish to develop your coin to something worthwhile, you need wide acceptance, you need a fanbase.

Glad someone is finally bringing up this point ... how many of you have dealt with asic miners, the crypto farm kind (mostly chinese)? how many of you have taken part or read about meetings between miners and devs around bitcoin? the attitude from the asic farm miners is the opposite of what Zen has continuously touted about (community spirit, etc). Apathy, general non-participation, preferring to be told what to do etc. Best of luck using that gang to "foster innovation".

[peteyteepee]

I wholeheartedly concur with aleqx! Bitcoin is a shining example of centralization. If they brick asics, they brick their coin. It's too late. The world's most popular cryptocoin is controlled indirectly, by Jihan Wu. The argument that AMD and Nvidia are no different from Bitmain is false. AMD and Nvidia did the legwork to make their products readily available to virtually everyone. In addition, they've even publicly stated their opposition to gpu farms which hoard gpu's. Until asic's share these properties the decision to fork should not be up for debate. Yes gpu's did put an end to cpu mining, but when they did, they were available to virtually everyone and decentralization remained. It is also false that endless forking is needed to keep asic's at bay. Monero forked without hesitation and it's alts followed suit. All Bitmain's r+d was vaporized. We shall see how many years pass before Bitmain takes another poke at Monero! The idea that all miners are solely focused on profit is also false. When Ethereum expressed disinterest in forking I turned my back to it, as did other miners in my small community. I refuse to own it, mine it or even speak of it without invitation. When Zcash expressed apathy to the Bitmain problem I turned my cards at Zen. My hashpower is my only means of expression as we chase the dream of economic freedom from centralization. If Zen is to show the same ambivalence as Zcash or Ethereum, one tiny star in Zen's hashing universe will dim forever. That will be me as I collapse into a black hole and swallow every star in my immediate vicinity, or at least the ones who will listen haha. Wait for shipping day. Fork with extreme prejudice.

[NagyGa1]

All the rhetoric aside - which is just cheap talk -, it will come down to one single "argument": when miners use hardware vendors like AMD and NVidia, the coin developer does not get any share from the daily mined coins.

By cutting a deal with Bitmain, the coin developer can tap into an large additional source of revenue, without doing much for it.

It is no surprise that ETH decided what it did, and it is very clear at this point what ZEC will decide as well, one following the "debate" can clearly tell it is already decided and Zooko just try to pretend otherwise. Bot coins are large enough to be able to cut a deal with Bitmain.

The whole ZEC selling point was ASIC resitence, it is in their papers all around. Very clear that something big must have happened behind the scenes when they turn away from that.

That's more or less all about it.

[moyumz]

@nagyga1

You're advocating for corporate interest and endorsement. Explain to me how that is beneficial to a decentralised economy and network?

If that mentality is rife within the community, this experiment is effectively failed.

What's wrong with a donation model? Vertcoin has this, for development, general expenditure and etc.. in which the community donates towards...

Their OCM also provides an option to donate 1% of earnings to the development fund as well.

[NagyGa1]

@moyumz I am not advocating for anything, I am just telling you what's going on behind the scenes. If you ask me, on long term this is definitely bad for the coins, but immediate profits largely overrule that kind of logic.

Just wanted to add as well that it is highly unlikely that Bitmain invested shitload to an ASIC, or if they did, rolled out their ASIC for public and risked their hidden mining capabilities without consulting the decision makers of the largest coins before doing so.

[moyumz]

@nagyga1

It's hard to speculate on what is happening behind the scenes between the development teams and Bitmain, simply because we aren't involved.

However, collusion between the development team and Bitmain, if this to be true should be shunned and condemned.

If it could be agreed, that the Bitmain effect in the long term will be absolutely detrimental to the progress of the industry, market and networks... then why aren't we working together to address this.

[NagyGa1]

@moyumz

If it could be agreed, that the Bitmain effect in the long term will be absolutely detrimental to the progress of the industry, market and networks... then why aren't we working together to address this.

Precisely for the same reason why Communism does not work: any system assumes altruism from participants deemed to fail.

[NagyGa1]

....however, I hope you will defy that logic.

[moyumz]

@nagyga1

The users are what gives the network value.

[nikmit]

Some great arguments presented - I found myself giving 'thumbs up' to both sides... There's two aspects to this discussion - a long term strategic view of where we want to go, and an immediate term 'what will we do right now'.

To figure out the long term stance some (more formal) analysis of the arguments made so far should help but my feeling is that there will be most support for 'accept ASICs once there is more than one vendor making them'. That is not my opinion though, I think we should move away from PoW and mining altogether - in the long term.

For right now we need to get back to the reassuringly down-to-earth @blockops1 post and establish what our options are 'on the ground'. What actual changes to the code are feasible and safe, and what are the chances of these changes to prevent the Z9 from mining Zencash. The team should certainly order one now for testing.

[blockops1]

Excellent discussion, just had a chance to read through the points made by everyone. Involving all who have an opinion and well-reasoned argument allows us to address many different points when making a decision on which way to go.

For gathering more information, it would be useful to determine what changes can be made, and the effect of those changes, just like @nikmit mentioned above.

One of the aspects of ZenCash that speeds development is the ability to pull upstream improvements from Zcash and Bitcoin into the ZenCash code. Would changing to different Equihash parameters or a different algorithm make pulling upstream improvements from Zcash much more difficult? If so, how much more?

The Zcash Sapling upgrade is a big one that enables shielded transactions in a lightweight wallet on a mobile device, Selective disclosure keys, and view keys. These are all features that are extremely important for the usefulness and usability of Zcash, and it would be a huge benefit for ZenCash to have those capabilities as well.

Perhaps maintaining the Equihash algorithm but with just parameter changes would allow the Zcash improvements to be added to ZenCash safely going forward. It would be shortsighted to change the mining algorithm to increase resistance to purpose built miners while at the same time making it much more difficult to improve the ZenCash software.

It is important to test what is possible with the existing Equihash algorithm by changing the parameters. If we change the parameters for testing, we would need a development branch with new parameters, mining pool software that has new parameters, and GPU mining software as well. If this the testing of these items works well, then they would be in place before a fork.

There is already a version of z-nomp in the ZenCash GitHub repository that can be used to develop on with a development branch, and some mining pool operators prefer to use MiningCore, so it might be useful to create a development branch for that application as well.

The ZenCash development team has recent Equihash development experience in doing the C++ rewrite of the equihashverify code to address the fake miner issue that was affecting many pools.

Keep in mind that many of the larger (10+ systems) GPU mining pool operators use purpose built mining operating systems like EthosDistro, SimpleMining, and Pimp. These mining OS's go through their own upgrade cycles. For example, when RavenCoin mining became popular, it took some time for the X16R algorithm to propagate to ccminer, sgminer, then those versions to be available on the mining OS's. It took even longer for them to propagate to the miner monitoring software.

Perhaps adjusting the Equihash algorithm with different parameters would allow us to create a new version with a new name - Equihash-ZEN or something like that - that would make it more difficult for a purpose built miner to be created for ZenCash.

Selecting the parameters would be important. Is it possible that the parameters could be set to optimize for the current and next generation of GPU's? Is it even possible that the parameters could be set to make only CPU mining profitable for now? If that is possible, should mining capability be rolled back to just CPU mining until a generation of GPU's are created? Or would changing to CPU mining only put ZenCash at risk of being controlled by centralized botnet mining systems.

I don't know the answers to how the algorithm parameter changes translate into equivalent hardware specifications for CPU and GPU mining, and not just into the larger specifications like number of parallel processors and amount of addressable memory, but also memory bus width. It would be useful to have some approximate information like that, and it may only be possible to get that with actual testing using opensource GPU mining applications and varying the parameters.

If the algorithm were changed, it would probably be helpful to either not set a policy for future changes of algorithm, to say no further changes would be made until the Treasury/Governance system is in place and representative community voting is practical, or to schedule future algorithm changes for every 6-12 months.

An entirely new algorithm that is different than Equihash would need the same type of testing, and would cause even more complexity and potential obstacles to pulling in upstream improvements from Zcash. It would probably be best to start testing with changing Equihash parameters to see how that works.

[PeaStew]

@blockops1 agree upstream is most important, particularly for sapling, after that who knows. But such a dependency means any decision has to be made by Zcash first right?

[blockops1]

Not sure if we need to wait for Zcash to make a decision. If we can pull upstream improvements and just change Equihash parameters every time we pull improvements, then as long as Zcash maintains Equihash as the algorithm, ZenCash continues to get the benefit of upstream improvements (assuming current open-source license is maintained by Zcash, of course, which is entirely different discussion)

[PeaStew]

@blockops1 I am sure you have seen the controversy around the changing of ZCash's stance on ASICS (editing forum posts from ~"will change to combat ASIC" -> ~"will likely..." if that resolves itself to an actual change (zooko's recent comments aside) that would likely enforce a change on ZenCash (depending on the content of that change of course). I'm sure you're already planning on doing so, but coming out clear on the thinking/gaming of the various paths forwards (if-then-else) which are already in front of us (known knowns/known unknowns) would be something to think about even at high level problem domain description.

[Sto1cNate]

@blockops1 @PeaStew I will also parrot that agreement for upstream improvements. I have had a bit of time looking into some of the equihash changes other projects, like ZERO have made. ZERO boasts that their solutions are smaller (about 3.3x smaller), whilst at the same time increasing complexity and memory usage by over 16x.

Looking at their main bitcoin talk thread, the number of sol/s are decreased anywhere between 40x to 48x. I have some AMD Rx Vega 64s and some 1080Tis I can test the algorithm on. Sometimes an algorithm where it becomes much more computationally intensive, tends to show less favor between architectures and more or less seems to correlate more with singe or double precision performance. The changes made here also would eliminate most cards with less than 8GB of RAM, they note some exception for mining within linux where a 1060 with 6GB can handle it at about 9 Sol/s and another exception for some AMD cards with 4GB of RAM at about 7 Sol/s.

I'm going to change up my mining software on my linux machine with the 1080tis and test out ZERO there, as well as on VEGA 64s, try to get some performance metrics.

[PeaStew]

@Sto1cNate what a can of worms that would be, pitting low RAM miners against high RAM miners? Divide and conquer? ;) Also wasn't there some speculation the the ASIC may use linked memory, in which case it could be increased?

[Sto1cNate]

@PeaStew I just had to edit my post, missed one part where they mentioned it can be ran on AMD cards with 4GB.

[blockops1]

Here is some useful information regarding Equihash parameters and memory requirement from Optiminer https://github.com/Optiminer/OptiminerEquihash

Optiminer/Equihash GPU miner for Equihash supporting many coins. A (probably incomplete) list:

Zcash (-a equihash200_9) Bitcoin Gold (-a equihash200_9) Hush (-a equihash200_9) Zero (-a equihash192_7) Minexcoin (-a equihash96_5) Kommodo (-a equihash200_9) BitcoinZ (-a equihash200_9)

This is a replacement for the previous versions of separate miners for Zcash and Zero. Unifying all three variants of Equihash used by different coins ([N,K]=[200,9] / [192,7] / [96,6]) into a single binary simplifies further development on all variants.

Note that depending on the Equihash parameters the amount of GPU memory needed varies a lot:

equihash200_9: >512MB equihash192_7: >6GB equihash96_5: >32MB

Due to the high solution rates achieved with equihash96_5 the CPU demans are higher. Take this into account when putting 5 or more cards into a rig!

[Sto1cNate]

@blockops1 Thanks. Fortunately I was doing some experimenting with one of my 12 card rigs in the past and have a high spec i5 quad core with 8GB of RAM. Let me know if there is anything I can help test out.

[Stephenglfox]

@blockops1 keep in mind that bitmain made a claim that the Z9 can mine equihash. Not Zencash, ZCash, BitCoin Private or any others. It stands to reason that they have taken into account that equihash algorithm parameters can be changed. At this time the amount of memory inside the Z9 is unknown. There is also a 180 day warranty which could allow them to upgrade RAM or change internal configuration to support any changes the coin software uses to defeat the ASIC.

If they have the algorithm they have the parameters. To resist you may need to consider something a little more radical. There are folks from bitmain watching every one of these discussions.

The order limit of one device per order is a marketing strategy to gain wide acceptance and obviously a response to the Monero experience.

[Sto1cNate]

@Stephenglfox the limit one order, and the mini SKU could also be Bitmain testing the waters for how the market will react. They're in the business of making money, and probably don't want to waist all their R&D on a full size unit, probably 4x more powerful. Just my own speculation.

[Stephenglfox]

@Sto1cNate the fact of an existing product is evidence the research and development cost has already been sunk. At this point market research has already been done to justify the expense. If they can make a Z9 mini they can easily scale up to a Z9+ with little additional cost.

The name Mini is a signal that the Z9+ or Z9 Maxi is already in design

[aleqx]

Too much speculation already.

@blockops1 please consider putting out a call for a (faithful) Zen fan to lend you one of these ASIC miners so you can dissect it. You're far more likely to get one this way. I'm sure you can get help for analyzing it, but if you need it, I would try my best to make time to provide assistance (my first large scale FPGA and ASIC designs were in 1998 as part of a company who pioneered 802.11).

[elkimek]

@blockops1 have you already contacted the person as I proposed in the mail? They know the shit like noone else and can be very helpful with this matter at least on the insight side. If not, please give it a shot.

[blockops1]

@aleqx and @Stephenglfox completely agree that we need to see what the actual design of the miner from bitmain is before making any changes.

If it's a purpose-built processor or fpga with external memory interface then merely changing equihash parameters could be easily circumvented by minor code changes and adding external memory.

Fpga experience is definitely helpful. Back in the late 90s I worked for the Xilinx, VLSI and Intel manufacturer's rep in Colorado and had the opportunity to learn a lot about when and how different architectures can be used, but my knowledge is about 20 years out of date and memory controller implementation has changed a lot since then.

As soon as I saw the Bitmain announcement about the Z3 on Twitter I retweeted it and ordered one because I knew this would be important and we needed to get our hands on one quickly. I know a few other people on the zencash team did also so we should have a few to take a look at.

[blockops1]

@elkimek thank you for putting me in touch with industry experts and I did have a chance to reach out to that person on email every conversation and bit of information helps.

[blockops1]

Here is an interesting thread posted May 1 about build on FPGA: https://bitcointalk.org/index.php?topic=3459858.0 ----quote People asked me to make a new thread on this topic, so here it is.

Here are some pics and video of my 8 x Xilinx VCU1525 rig. Each VCU1525 card has one Xilinx VU9P Virtex Ultrascale+ FPGA. Hash rate for the whole rig combined is:

Keccak (Smartcash, Maxcoin): 136GH/s (17GH/s per card x eight) ($160/day at Apr-30 prices) Tribus (Denarius, Virtus): 16.8GH/s (2.1GH/s per card x eight) ($304/day at Apr-30 prices) Phi1612 (Luxcoin, Folm): 5.2GH/s (650MH/s per card x eight) ($456/day at Apr-30 prices) Skunhash (Various coins): 10.4GH/s (1.3GH/s per card x eight) ($261/day at Apr-30 prices)

Those yield around US$20-$57 per card per day ($160-$456 per day for the rig). Each VCU1525 card costs $4000, or $32K for the whole rig. At $160-$456 per day, ROI is 70-200 days depending on the algorithm. I'm not the only one mining with these cards. Apparently some guy in Germany is getting 64KH/s with Cryptonight-V7 on the same VCU1525's, earning him over $100 per day per card or $800+ per day for a whole rig.

Next up on my implementation list is SHA-224 and Neoscrypt. I am also developing for the Bittware XUPP3R-VU9P which is an almost identical board as the VCU1525. I'm planning on releasing the first bitstreams (FPGA config files) to the public May 30 with an embedded 4% development fee. If you are interested in acquiring hardware, contact jason.harvey@avnet.com for the VCU1525, or Christian Robichaud of Bittware, for the Bittware XUPP3R-VU9P (crobichaud@bittware.com). Tell them you were referred by Zetheron Technology and you want the cards for crypto-mining and they can expedite the lead time, which is currently around 4 weeks. The intro price (at Avnet) on the VCU1525 is $3995 USD, but it will be going up to around $5K in July. The Bittware XUPP3R-VU9P crypto version is $5895 USD, and has two advantages over the VCU1525: (1) it has four QSFP28 100G ports so you can daisy chain 4 FPGA's together to mine Xevan at 162MH/s, and (2) it has flexible memory options, so you can install either DDR4 or QDRII+ SRAM; the QDR memory gives way faster hash rates on Equihash vs. DDR4. I've been in communication with many members of this forum who are already organizing a group buy.

----end quote https://drive.google.com/file/d/1Oh8VV0CDi-R6ls4Up9n7uJk5_gVp5OK2/view

[MrGold86]

I just read this article, http://markwilcox.com/articles/03/. It is a great read, and especially revalent to this discussion is this paragraph:

ASICs aren't a weakness, they're a strength.

ASICs ensure that energy pointed towards the chain is in line with the security model to defend the currency against third party attacks. Requiring a significant capital investment of specialised hardware aligns the incentives of the network with the role to be played by miners. It protects against vulnerabilities. Competitive consensus is not about fairness, it's specifically about unfairness. Artificial restrictions against optimisation create morally unfair systems because they deny the market the ability to make a profit, denying harder-working providers the opportunity to enter the race and encouraging low performance. David Vorick from Sia wrote a great post on this topic.

The post from David Vorick is here: https://blog.sia.tech/choosing-asics-for-sia-b318505b5b51.

Regarding what someone above posted about getting rid of POW due to the energy usage, the Mark Wilcox article has these words right above the ASIC paragraph:

<<<<<<<<<<<<>>>>>>>>> This paragraph is referencing words from this article: https://medium.com/@preethikasireddy/fundamental-challenges-with-public-blockchains-253c800e9428

Consensus As public blockchains like Bitcoin that use proof-of-work consensus continue to scale, increasingly, more energy will be wasted. If the goal is for the public blockchain to scale to millions of users and transactions, the unsustainable wasted energy and computation costs of proof-of-work are not conducive to this outcome. <<<<<<<<<<<<<<<>>>>>>>>>>>>

I disagree with this premise entirely. It's proof of work, and efficient wasted computation (that is, energy that could not be put to a more profitable use) that enables the blockchain to scale to millions of users, by building a more logical and convincing argument for its security as money. Proof-of-Work has scaled enormously, to several ExaHashes today, 9 years after the first block was mined, and the energy wasted for each of these hashes is orders of magnitude lower today than was needed in 2009.

This argument is not new with Bitcoin. "If we don't stop burning fossil fuels ..." "If we don't stop building houses ..." "If we don't stop trying to live beyond our means ..." then we will never make any progress! It's this constant desire to do more with less that results in growth and progress. Check this section from George Land's book Grow or Die, written half a century ago. The argument applies as much today as it did to anything in the 1970s. Then re-read Szabo's blog, understanding that Bitcoin is the best machine for energy optimisation ever built. Port some software to the bitcoin mining network and be amazed at the energy efficiency gains that the market can extract from it if we allow them the freedom of profit.

[ekool]

100% in favor is keeping this coin ASIC resistant. Bitmain is a behemoth who has proven time and time again to be hostile to anything that hurts their profits -- even at the detriment of miners and upgrades to coins. Will not support Zencash if it does not hard fork. (I run 3 secure nodes and mine Zencash currently) -- while I can mine and support other coins, I choose to support Zencash because of the community. This community will not be the same without smaller players.

[sloppycoffee]

I have been mining ZenCash since it forked from Zclassic. I have enjoyed the ride but ASICS are the only way to ensure the security of the network. I don't like BitMain but I noticed that they are limiting 1 asic per person which would help keep it decentralized. Regardless, I like ZenCash enough to help secure the chain into the future and purchased the ASIC. Moved the GPU farm over to RavenCoin which should be GPU only for the foreseeable future.

If you are going to fork ZenCash please include something like x16r since the ASIC companies can easily adapt and you will be right back where we are today.

Either accept that ZenCash is moving to ASICs or Fork to x16r. My 2 cents.

[ekool]

I can't understand how someone can say this: "I don't like BitMain but I noticed that they are limiting 1 asic per person which would help keep it decentralized" -- So let me get this straight, since they are the ONLY ONES making an ASIC, but because they are limiting them to "1 per person" -- when in reality, they won't even do that.... you think that keeps it decentralized? If they want to make 1000000000 units and sell .00000001% that's decentralization? You like the idea of this ONE COMPANY controlling the hashpower of Equihash on a whim, at any time? That's "decentralized" to you?

[blockops1]

For changing Equihash parameters, Tromp (creator of Tromp solver) recommends 144, 5. here is a quote from the thread https://github.com/zcash/zcash/issues/1211

---quote

The current parameters are putting Zcash at risk of a single-chip ASIC, which is the worst possible outcome.One of the goals of a memory hard PoW should be to force off-chip communication to separate memory chips, so as the make ASICs face the same memory bottleneck that GPUs do, and minimize their advantage.Equihash at (200,9), allowing for a 144MB solver, fails to serve that goal, unlike (144,5), which would need 2.5GB of memory.Could Zcash invest resources and stretch schedules to increase memory requirements in Overwinter or Sapling? ---end quote

But without knowing how the Bitmain Z9 is built, it is difficult to determine if that would limit Equihash mining to GPU/FPGA mining only

[blockops1]

My point about posting a FPGA miner that is state of the art is to show what they can do. FPGA's are a stepping stone to an ASIC miner, so if it can be done in FPGA, it can be done in ASIC. That FPGA miner can solve X16R without a problem.

More quote from the Bitcointalk FPGA thread: ---quote

• It is possible by using data from initial algorithms to project the hashrate within +/-10% for future algorithms, and in that light the expected rates (per card) are about 300MH/s for X17 & X16R, 25MH/s for Neoscrypt, 600MH/s for Lyra2v2; 150MH/s for Xevan (Bittware card only for Xevan!). For Equihash it is much harder to calculate the projected hash rate. I don't think Ethash would be profitable enough to be worth it. Those numbers are just projections though, and their profits are in the same range as the initial algorithms being released, with X16R and Xevan looking the best at around $75/day
• X17 and X16R require two FPGA cards daisy chained together with 2 x 100G ethernet cables, one FPGA does half the function, the other FPGA does the other half
• Xevan requires FOUR FPGA cards daisy chained together with 6 x 100G ethernet cables; this is only possible with the Bittware card
• The QDRII+ SRAM modules for the Bittware board are very expensive: $2250 for one 76MB module, four modules max per board (288MB max). This is the way to do Equihash but I have not yet been able to calculate if the price of the memory is worth it for the increased hash rate ---quote

[Sto1cNate]

With all the FPGA news coming out (which is awesome BTW), it is looking more and more like the real question is.... What is the real benefit of changing the POW algorithm? With people willing to open up their work on FPGAs to the public like the poster on bitcoin talk, this can obsolete GPU mining if brought to scale. The poster also mentioned the manufactures of these chips having no issues with large volume productions.

[aleqx]

Here is an interesting thread posted May 1 about build on FPGA: https://bitcointalk.org/index.php?topic=3459858.0

Who paid for the PCIe license? Last time I checked a pcie IP core was bloody expensive. I'm not that impressed by that FPGA rig, but I didn't know of those FPGA boards -- they are quite interesting. I'm not that compelled by it though and I think others wouldn't either and would still prefer GPUs (especially as they become better, particularly the fast memory compared to DDR3/4 on FPGAs). I see the space density and power advantages but price wise I'd get more out of $4k with GPUs, and also more flexibility, ease of use, wider applicability, and resale value.

The economic model may eventually turn it into another Bitmain-like product, but perhaps this will encourage manufacturers to build more FPGA boards like this. Still, you're looking at something different from a bunch of GPUs that are available to most (bar shortage and all that) who can start mining with freely available software. FPGAs will always be more specialist friendly.

[Oubiizii]

Gpu miners are fans and voice for your coins. What would be the current price of zen without Community and gpu miners?

[koljenovic]

Here is a study on lessons learned when Bitcoin had the same issue: https://download.wpsoftware.net/bitcoin/asic-faq.pdf

Definitely worth a read and a lot to learn.

[grenwolde]

I am new to this community and GPU mining -- I do own a L3+, for me, the appeal of GPU mining has been the decentralization and the technical challenge of maintaining my rigs. However, I am not naive enough to ignore that as long as there is an opportunity for profit companies will enter and hawk their hardware. I personally believe that ZenCash should fork and remain asic resistant, however that will take time and money, and will have to be done on a regular basis. So dev fees will have to rise. But on that point even if Zencash forks -- this is no guarantee of decentralization -- as long as there is an opportunity for a decent ROI you will see centralization -- whether in asics or GPU's. I think the bigger problem is the current oligopoly in the asic market -- and until others enter the centralization problem will be more extreme. So until there is more competition in the asic market I think in terms of the desire to maintain decentralization -- fork and fork often.

[blockops1]

@koljenovic thank you for posting the link to that paper. It is an interesting read. Theoretically, Asics should not be bad and decentralisation should only be temporary, but a lot can happen during the temporary centralization of hash power of a cryptocurrency, especially one that is in it's early growth stage.

It appears that paper was written when the Bitcoin proof of work was SHA-2, as opposed to today's sha-256, or is that a typo?

[blockops1]

There are benefits to the Equihash algorithm, and the ability to change the parameters to achieve different performance is a potentially useful feature.

The full Equihash paper is worth a read and is available here https://www.cryptolux.org/index.php/Equihash

One of the concerns that I have about potentially changing the parameters of the equihash algorithm within zencash is the effect upon backward compatibility.

I don't know the level of effort required for software development, verification, and testing in order to produce a version of zencash that uses different equihash parameters going forward while still maintaining compatibility with all the previous blocks.

There is already additional work that has to be done every time that zencash integrates with a partner or Hardware wallet or exchange due to the implementation of transaction replay protection when zencash did a chain split from zclassic.

If zencash were to change the Equihash algorithm parameters at a specific block would that create additional integration difficulty going forward or would it be straightforward. That's another thing our developers need to look at.

[aleqx]

I would be cautious, to say the least, in extending or applying to the future the lessons of the past from Bitcoin, a different coin, advertised with different intents and which evolved even more differently (some would say diverged). Remember that one common trait advertised by most modern coins at launch, many years after Bitcoin, was "ASIC resistance".

I can't help but feel that Zen has grown into a powerful project which could soon afford to make big changes, bearing the responsibility, while being trusted by its users and investors alike. You guys made a lot of progress. You should be very proud.

[sebaschan001]

My personal opinion on this as a miner is that ZenCash should fight against ASICs as long as the market is dominated by only one ASIC supplier. The problem with Bitmain being the sole ASIC supplier is that they can dictate pricing and decide who gets ASICs and who not. I don't want to go as far as implying that Bitmain would implement a feature to shut down any mining operation on their will, but the network will be more vulnerable if most of the hash rate is provided by the same mining hardware from just one supplier world wide. Just imagine if somebody is capable of taking control of all Antminers via a trojan... they could just END bitcoin. GPU mining will not last forever, and I am not against ASICs in general, I just think that the ASIC market is not ready yet to provide ASICs to everyone interested in mining and supporting the network. In a couple of years, maybe months, things will certainly change. Again, I recommend fighting ASICs for now, but not forever.

Best, Sebastian

[aleqx]

I would also not be quick to assume that the Z9 mini can adapt to changes in Equihash parameters. If it's an ASIC and not an FPGA (and judging from the price, it's an ASIC) then chances are it's rigid and can be rendered useless in many different ways that are easy to implement ... similar to Monero - if the XMR ASIC had been flexible, we'd have already seen the Monero hashrate back up to March levels. Instead, we have a series of new asic-friendly coins (great!).

Keep in mind that companies like Bitmain won't necessarily have built in flexibility towards equihash params to ensure future proof resilience. The latter is inherently guaranteed by the mere fact that there will be a subset of Equihash coins which won't fork -- not to say about the coins which will be created to be asic-friendly (see Monero). Either way, Bitmain is anything but concerned, that you can be sure of.

p.s. Just please don't make the algo more demanding. Equihash is already the most power hungry and most heat-generating algo out there ... if anything, I'd welcome a bit less heat and power.

[blockops1]

Regarding the potential of changing the N and K parameters of the Equihash algorithm to 144 and 5 as suggested by @tromp, it should make the Equihash verification more efficient. https://forum.z.cash/t/let-s-talk-about-asic-mining/27353/137 is a post from @Daira (zcash developer)

---quote from link

This was a scheduling and technical risk decision: we don’t have time or sufficient headroom in the complexity+risk budget to change the PoW in Sapling.

For the record, I’m strongly in favour of changing the Equihash parameters to increase memory requirements (which incidentally makes verification more efficient), possibly in the next upgrade after Sapling. The current parameters were chosen before the development of optimised Equihash implementations that happened just before launch, so they’re definitely not ideal. I’m also in favour of researching other ASIC-resistant PoW algorithms as potential replacements in case just changing the Equihash parameters turns out not to be sufficient.

I find the centralization of mining in Bitcoin to be alarming and a serious security vulnerability. I’ve never been convinced by the argument that investment in mining equipment provides adequate incentives not to exploit the network. Consider for instance that a government could take over any majority miner in an instant, and many governments have demonstrated animosity to the whole idea of decentralized currency. If we thought this argument was a basis for an acceptable security model, why would we be using PoW (with the attendant gross environmental cost), rather than a centralized sale of mining rights by the developers of a coin to the highest bidder?

We haven’t done as well in avoiding mining pool centralization in Zcash as I’d hoped. That is a security problem, but it’s a potentially solvable one, and I believe the situation would be very much worse with ASICs.

The fact that Zcash was originally presented strongly as having an ASIC-resistant PoW, and has built its mining community on that basis, needs to be taken into account.

PoS might be part of the solution in the long term, but it isn’t ready, and Zcash’s policy has always been “wait to see how that works out in Ethereum”.

I also think that individual opinions (such as @zooko’s or mine) should not override community consensus if the latter is in favour of hedging against ASICs, as it seems is the case. Technical and engineering feasibility, and security requirements, are always an issue in deciding how the protocol evolves, but in this case, there’s no severe technical/security obstacle to changing the Equihash parameters. That would at least buy some time against ASICs, and also has the (minor) advantage of better PoW verification performance.

[Edit] As noted by @tromp, this would also be consistent with the recommendations of Solar Designer’s Equihash analysis. ---end quote

[Stephenglfox]

It stands to reason that another company can mass produce an ASIC using a FPGA development platform offered by the Xilinx VCU1525 or Bittware XUPP3R-VU9P. Why not have an EQUIHASH consortium develop and release an OPEN SOURCE DESIGN for an ASIC. This way any company can manufacture the design and sell it on the open market.

You would be creating an ecosystem similar to NVIDIA or AMD and have manufacturers like EVGA, MSI, or any other contract manufacturer produce the unit to the design. Simple, problem solved.

You could probably get this done with a team of 1 to 5 engineers. Not insurmountable.

[tarrenj]

There's been a lot of great points made by both sides here! It's becoming clear to me that we may need a vote to decide this. With the DAO and On-Chain voting still a ways away, what do you guys think the fairest way to conduct a vote would be? We have to take into account all the users who aren't active on Discord, GH, or BTCTalk. We can distribute the vote via the announcement mailing list, but I'd like to use something better then survey monkey..... Any ideas?

This is not a statement saying we'll be conducting a vote, or that the outcome of said vote will be our path forward, I'm just trying to get some input on how that could be done.

[blockops1]

@tarrenj We are not ready for a vote, much less a vote that will decide what we will do. Have you tested what using a different algorithm would do for exchange and hardware wallet integrations? For upstream compatibility with zcash improvements like Sapling? For any of the other issues and questions I mentioned above?

[tarrenj]

I don't see asking for input on how to conduct a fair vote as anything binding. It's true we still have to research all the above points, but it's possible we'll come to the conclusion that a vote is the best option, and if so, having some feedback on a fair way to conduct one would be beneficial.

As for HW wallet and exchange support, changing the PoW algo shouldn't affect them Apart from requiring a node update, which is regular), as long as the TX format stays the same. No idea on how it would effect upstream compatibility yet though...

[blockops1]

ok, cool, I thought you said we need to vote to decide this, glad you did not mean it as binding that we would make a decision by voting.

It seems to me that if we change the proof of work algorithm at a specific block, that older blocks would use the original algorithm for hash verification, and newer ones the new algorithm. Not a big deal with transparent transactions, but we also have shielded transactions on the blockchain. zk-snarks are complex, and when we've looked at changing thing that in other cryptocurrencies would be trivial, when zk-snarks get involved, it gets complicated.

[kgcrypto]

@tarrenj I've heard that VoteCoin would be useful, but hopefully you're not thinking the actual direction of the project would be determined by the vote. I think the vote would be useful to determine if we should even spend the energy doing the research that @blockops1 has been doing. (Not to say that it isn't useful!) Maybe the majority is actually cool with the ASICs. I know there are a lot of vocal people, but the majority is not always vocal.

Before any kind of vote about actual direction, we need to continue the research along the lines of what @blockops1 is doing so that we can be better informed about options and effort. For instance, I don't think we can afford to sacrifice Zcash upstream changes for sake of any old ASIC resistant algo. Once that's understood, the project should vote on what to do about this particular threat, given the facts. It might not even be possible to counter this effectively before someone has laid hands on the hardware, although I bet we could make some pretty good guesses.

Eventually, we should probably vote on a couple things, since people are paying attention to the topic. First, there's this particular threat, and second, we should consider voting on the stance that the project should take, since we assume that there is no way to create an algorithm that is eternally resistant. Life would be so much easier if Zcash took the same view.

So far I am encouraged by @tromp's suggestion quoted by blockops just an hour ago. I have a mix of GPUs that I could test with if there are memory requirements that rise with parameter changes. 1080, 1070, 1060s with 3 and 6GB, 980, 980ti, etc. If you need some help, I can build whatever branches and give them a go on my extra rig. I'll keep an eye out and watch the issue.