ProgPoW Audit Delay Issue

@timolson Have you watched the DevConIV ProgPow talk by @ohgodagirl? I think it addresses most of the issues, apart from the deep dive into floats. I would ask that anyone who is serious about debating ProgPow watch it first. She is Miss If (of If/Def/Else) so her word is gospel when it comes to the authors intent.

First, let’s not conflate ASIC-resistance with ASIC-proof. No algorithm is ASIC-proof. What ASIC-resistance aims to do is to resist, not prevent. By making an algorithm that is very well suited to the GPGPUs it makes the economics of producing and maintaining unpalatable, short of a sustained tripling of Eth’s all time high. Making GPUs the best device on the market to do it and designing the algorithm so that an ASIC would look like a GPU missing some ports an chips is their method. Miss If admits it is a short term solution and that this resistance has a time limit. The goal is to make that time limit past the Proof of Stake transition.

And that one of the reasons I think ProgPow should be done. We need to move the cheese before ASICs dominate the mining aspect in the way they have controlled BTC and other cryptocurrencies. The need for a return on investment is a contradictory alignment of interests. By moving to a GPU favorable algorithm the miners who do remain will have devices that are still useful when mining on the original Ethereum mainnet becomes moot, because Serenity is fully activated. If all the miners were on ASICs their incentive would be to sabotage such a transition as their hardware would be useless. But with a GPGPU there is still utility in AI, other cryptos, or even gasp video games.

So there is a community commitment to “move the cheese” once Proof-of-Stake becomes viable. If we flinch now updating the Proof-of-Work algorithm because the chosen algorithm isn’t ASIC-proof then there is a reason to doubt if the community will ever be willing to pull the trigger to end the mainnet and let the difficulty bomb fully explode. Remember, we were supposed to already be on a Proof of Stake network by now, the plan has already changed.

6 Likes

FFS I try to post a highly-educated technical review and first get insulted that I don’t even know the basics of floats, and now you think I don’t know who Kristy is or understand that ASIC resistance is a continuum?

We specifically call out the 2x threshold which seems to be a common number used for “resistance” and also say it’s not clear that ProgPoW is an improvement over Ethash (but it’s an honest try.) Really, it could go either way. If you just care about delaying ASIC’s with forks then the PoW doesn’t matter much. Just keep forking to something new every 6 months. If you think ProgPoW will last 12 months then that is purely speculation.

I thought the community would want an expert opinion that didn’t come from the authors. If you’d like to ask for more detail on our assessment I’m happy to oblige, but I have no interest in devolving into a philosophical PoW conversation. I shouldn’t have said anything about my personal view on PoW.

To my knowledge, no one has mentioned or considered a VLIW architecture for ProgPoW before, and it’s a clever approach that will give a nontrivial performance increase, so you’re welcome. I could have sat on this design and made a lot of money selling a ProgPoW ASIC.

I find it strange that no one has yet commented on this VLIW proposal or its implications for ASIC resistance. Instead, you seem most interested in just quoting KLM to me and defending a philosophical position you were already entrenched in… Have you even bothered to add up the gate counts in Linzhi’s design? Hmm? What do you get for your die area calculations?

3 Likes

My intent wasn’t to insult. Many people read these threads so I wanted more available resources. I’m not denying there are clever ways to create new ASICs, some we know about and some that will be invented, that is the nature of the beast. VLIW is one of those possible methods.

My first goal was to clarify the meaning of ASIC resistance vs ASIC proof, your statement “My personal view on PoW is that there is no such thing as ASIC resistance” contradicts your new claim that you “understand that ASIC resistance is a continuum.” I’ll give you the benefit of the doubt and interpret that when you said “there is no such thing” what you were arguing was that ASIC resistance is too easily overcome to provide meaningful value. We both agree there is no such thing as ASIC proof. The main question are can we delay the entry of ASICs into a ProgPow POW ecosystem, but does the mechanism proposed to delay it in a fashion that makes economic sense. A two week delay fixed by a change order is a delay, but a pointless one. Is ProgPow a similarly pointless delay? That’s the answers I’m looking for from the audit.

3 Likes

Sorry, it was my fault to say anything beyond the ProgPoW facts. I shouldn’t be snippy.

When I say ASIC resistance is not possible, it is an opinion that “even economies of scale in GPU’s or CPU’s are not enough to prevent a 2x improvement by ASIC’s in terms of total-cost-per-hash for any given PoW.” I don’t mean ASIC-proof; even a loose “economic resistance” seems too much. And even if 2x is achieved, I do not think that is enough to save GPU’s. But these are personal opinions not ProgPoW facts.

Maybe ProgPoW proves me wrong. I’m open to that. Like I said, I think it’s the best try so far, but I’m not sure if it’s better than Ethash. It’s a good try for sure.

Certainly ProgPoW is much more than an ECO on Ethash. It’s an all-new chip for sure. But the spec has been around long enough that you should expect a great deal of ASIC design work to already be completed. You could see ProgPoW ASIC miners on the network within 4-6 months of a switch to ProgPoW being finalized. I would expect manufacturers to wait for certainty on ProgPoW before taping out, so it’s actually to your benefit to keep alive the possibility of not switching. That’s 4 months from decision time, not from launch time…

For a case study in forking to fight ASIC’s, look at Monero. Their first attempt was useless (quickly ECO’d) but even big changes were overcome by ASIC’s within 6 months or so. The thing currently keeping ASIC’s at bay in Monero is the threat of further imminent forks, not anything to do with the PoW.

3 Likes

A separate point about mining economics:

Many people assume hash-per-joule is the ultimate mining metric, but anyone who has run a mine knows that capital expense is actually a HUGE factor, because the lifetime of mining hardware is so short. Of course the total lifetime cost for a miner is capex + time*opex, so if time is short, capex dominates. It’s a line with capex at time 0, going up with slope opex.

< deleted some wrong speculation about ethash vs progpow in capex vs opex >

ProgPoW will have both a bigger capex and opex cost compared to Ethash, so both the offset and slope of the total cost line will go up. That may seem like ProgPoW is an instant win vs Ethash, but it’s not clear, because maybe ProgPoW ASIC’s improve the slope of the cost line vs GPU’s more than Ethash ASIC’s. Then things depend on the lifetime you choose for the equipment, and the economic-ASIC-resistance lines of the two PoW’s will cross at some point…

You need to basically make an ASIC in order to know its power and area well enough to compute the cost lines that would inform any economic-ASIC-resistance determination.

Also, no one should worry about the audit firm dropping the job. It’s a thankless task and honestly very little money. Generally you’d need something like $500k to $1m to do enough work to make specific power and area claims. With the amount you have in the fund, under $20k I believe, you shouldn’t expect any real conclusion on ProgPoW to come out of the audit. Not sure what your specific goals are for that review.

There was more money allocated privately than that donations pool, but you’re right that it was no where near $500k. It’s somewhere around 1/4 to 1/3 of that.

This is a very interesting point, but I’m not sure you give a clear explanation for why that is so. At least, not clear to me. Would definitely appreciate if you could make the argument of “capex vs opex” differences in the algorithms, using some of the features of the algorithms to show why those points are true.

At a high level, the opex/capex argument is interesting to me. It would seem to make most sense that ensuring the opex for specialized hardware vs. commodity GPUs is as similar as possible and capex somewhat favors commodity GPUs, with a higher ratio of capex to opex, would ensure that the chosen algorithm has a good chance of resisting specialized hardware production for a reasonable period of time (12-18 months being a target). It would also being interesting to hear your take on what practical ranges of these parameters can be expected and under what time frames they would probably be valid for.

1 Like

Let me emphasize the word “might” in all those capex/opex statements. It’s probably not fair for me to conjecture. To explain:

Ethash primarily relies on bandwidth to memory with only very light computation, but ProgPoW adds a lot of computation, which means both extra silicon (capex) and extra power (opex). Actually it probably adds more to the opex side than the capex side, but I don’t know, so I shouldn’t have said anything. But yes they are using more chip, which means more up-front cost (capex), but there will be a lot more power too (opex). I don’t want to speculate whether one or the other will be better for typical miner lifetimes, only to point out the complexity of calculating economic ASIC-resistance.

This is wrong BS by me don’t believe it. In fact it’s probably the opposite way around. I was thinking only about the silicon not the power… We won’t know the power requirements of a ProgPoW ASIC without basically prototyping one, like I said above about the audit cost.

Definitely makes it really hard to speculate on what is the best decision here. On one hand, making the change has a non-trivial chance of being worse than Ethash in terms of efficiency by specialized mining hardware, although that is hopefully not the case since we have more data now. On the other hand, doing nothing seems to all but invite manufacturers of that hardware to the table, with whatever incentive misalignments they may bring. The best approach, as you said above, is to create the threat of making a change, but we are a large community that requires a lot of transparency to function, so it would seem unlikely we could fake it for very long. In my mind, the best scenario is therefore to build, test, and integrate ProgPoW, and at least have it within a hair’s trigger of going live. At that point, you might as well just try the damn thing so you are not seen as bluffing. The more well-researched and implemented options we have at our disposal for alternative mining algorithms, the less appealing it would be to develop hardware for it.

The VLIW proposal sounds very interesting to me!

1 Like

[Disclaimer/Background: I work for Linzhi Shenzhen, a small independent privately funded ASIC startup in Shenzhen. We are working on an upcoming crypto chip whose first application will be Ethash, as announced at ETC Summit 2018 in Seoul. We are facing some delays, but all is fine. All things worth doing take longer than expected.]

In my view, @timolson did the Ethereum community a great - free - service with his series of posts and replies in this thread. Thank you Tim!

We at Linzhi are a little more open to speculating about the intentions or business deals that may have led to ProgPoW, which look very different from those behind RandomX. The anonymous nature of Mr. Else and Mr. Def as well as a number of surprisingly uniform accounts and articles/presentations are quite intriguing.
We don’t know the deals between Core Scientific (where Kristy-Leigh Minehan the main ProgPoW proponent is CTO) and Nvidia. We believe cost advantage leads to centralization

ProgPoW risks turning Ethereum into an Nvidia-managed game, with ETH devs becoming unpaid support staff to keep the game going.

I’m relaying the following quote from people with more GPU expertise than we have
or are willing to acquire (not from Linzhi, take it fwiw):

"On AMD V_MUL_LO_U32 uses 16 cycles, on Nvidia starting from Volta IMAD uses 5 cycles.

32-bit multiplication in ProgPoW was pushed under the pretense of it being inefficient on both manufacturers but that turns out to be a lie as on Nvidia it was only inefficient on Pascal. The algorithm is tuned to still let Pascal utilize full memory bandwidth due to simply sheer compute capacity difference coming partially from higher die size which is why comparing GPUs based on price is being pushed as of late. It’s not a secret that 4xx & 5xx series AMD GPUs are not high-end but because ProgPoW’s compute to memory bandwidth ratio is tuned to match Nvidia GPUs, AMD GPUs are not utilized to their fullest, most importantly losing the full memory bandwidth utilization which is the very basic foundation of the Ethash algorithm."

Is this true? If so would it leave much of the “honesty of the attempt” that @timolson sees?

Phil Daian wrote a great paper over a year ago
https://pdaian.com/blog/anti-asic-forks-considered-harmful/

There is another anonymous guy out there writing about ProgPoW, ether4life (no, it’s not us).

ASICs are designed and manufactured when there are buyers.
Currently there is sufficient demand if a machine can offer 150 days ROI (with flat/flat assumption, that is coin price flat, difficulty flat).
ETH currently pays out 3.6 mio USD / day or about 100 mio USD / month.

Without doing much math, it’s not hard to see how a system that pays out 100 mio USD / month can incentivize the design and development of chips. A lot can be done for a few million USD and it’s only natural that different businesses are competing for that money.

@fubuloubu - prepared or irregular PoW changes are a big incentive for secret mining. The alternative would be to pre-announce a PoW change one or two years in advance.

Quoting @timolson
“If GPU integer performance sucks very badly then ProgPoW may be worse than Ethash. If GPU’s perform pretty well at integers, then ProgPoW may be better. We’re not willing to speculate without a lot more work.”

+1 from Linzhi.

Tim made many other good points, I can tell you what I am doing: re-read his points, think. There are always new realizations to be had. What about the VLIW design? :slight_smile:
We are happy to have more discussions also in our Telegram group LinzhiCorp.

We did not look at the AMD vs Nvidia issue. When we say “honest attempt” we mean that ProgPoW doesn’t have some secret way to make ASIC’s easy, or any backdoor, or anything like that. It is definitely pro-GPU.

It may be true—almost inevitable—that one manufacturer or card series outperforms the other. It may be true that the authors have specifically tuned the PoW to favor Nvidia over AMD.

AMD vs. Nvidia may be tuned using ProgPoW’s loop constants for compute and memory, and IMO it’s up to the Ethereum community to test different values on different cards and decide what’s fair. The structure and design of ProgPoW does not fundamentally favor either vendor in my view, and the tunings my be adjusted and tested by any GPU enthusiast who can change one number and compile code. If the Eth community doesn’t want to do the simple work of trying different loop constants on different cards, then the hard work of fighting over what values are fair, then they can just accept the authors’ suggested tunings. But don’t be afraid to adjust the loop constants if you are concerned about GPU vendor bias.

3 Likes

Thanks Sonia, you too! Linzhi has also offered valuable free insight into ProgPoW including a basic ASIC design with gate counts, and they’ve been generous in also helping RandomX improve their effort. Sonia knows what she’s talking about, and free advice in hardware is really rare. It’s wonderful to see such entrepreneurial spirit and transparency!

Hello @Sonia-Chen

I have to comment on your post as the information you present is incomplete and misleading.

For the record, I am with ePIC Blockchain, a team of former AMD engineers who have over a century of experience designing GPU, mobile SoC and Blockchain ASIC. ePIC does not have a vested interest in either Ethash or ProgPOW.

Our sole interest is to help set the record straight with facts or pose questions that a hardware auditor need to address to conduct a comprehensive audit and reach a valid assessment for the Ethereum community.

I will address the key points that you posted above that ProgPOW favors Nvidia and that ProgPOW ASIC’s are easy to design:

1. Misleading claim that ProgPOW favors Nvidia

Measured benchmark results do not support Linzhi’s post that ProgPOW favors Nvidia over AMD. I will point to a Medium post, Comprehensive ProgPoW Benchmark by Theodor Ghannam to support my observations.

From the Ethereum Hashrates chart, I extracted the following data comparing ProgPOW to Ethash performance for 6-8GB cards using GDDR5 memory. I excluded GDDR5x and GDDR6 cards, to maintain an apples to apples comparison, as faster memories improve ProgPOW performance

Card….ProgPOW…Ethash…Relative perf

RX470 …… 9.7 ……… 20.6 ……47.1%

RX480 …… 11.4 ……. 21 ……… 54.3%

RX580 …… 12.7 ……. 21 ……… 60%

1060 ……… 10.2 .…… 20.6 …… 49.5%

1060ti ……. 14.8 …… 26 ……… 56.9%

1070 ………. 13.7 .…. 27.7 …… 49.5%

1070ti .…… 13.9 …… 27.7 .…… 50.2%

Note that these results were measured using factory clocks and therefore slower than what miners are used to seeing. I should point out that comparing BIOS’ tuned for Ethash is not a valid comparison as one typically increases the memory clock while underclocking and undervolting the core clock. In ProgPOW, one needs to overclock the core to get higher compute performance.

The results show Nvidia and AMD both drop about 50% in performance on ProgPOW. This is to be expected as memory access are now 32 bytes as opposed to 16 bytes requiring double the memory bandwidth.

I will reiterate that Linzhi’s post that ProgPOW favors Nvidia over AMD is wrong. I would also chastise Linzhi to do their homework and check the facts before posting incorrect information.

2. Misleading claim that ProgPOW is easy to implement in an ASIC

Buried inside the article is Linzhi’s misleading claim that states:

The random instruction of EIP 1057 increases die cost/power by about 1%, and causes a die increase of <1mm². The proposed open design is demonstrating a logic-only performance of 1.2 GHash at 30W and could be deployed by Bitmain or Innosilicon, resulting in a machine with about half the hashrate of their predecessors, similar to the best GPUs.

These statements are completely incorrect for the following reasons.

While it is true that the ProgPOW logic is small and easy to design, Linzhi completely ignores the fact that the performance limitation of a custom ASIC still remains the required memory bandwidth and the resulting logic required for caching and performance.

For ProgPow, sequential accesses to the memory is the performance limiting factor. These operations are driven from a 16 kB cache which would be needed in the math block to ensure the pipeline is full and the performance is optimal. This would add area (depending on node/technology chosen) which is not included in the original design.

Taking from this Github cache load example:

Light DAG init done
Full DAG init done
ProgPoW version 0.9.3
Block 30000
Digest 6018c151b0f9895ebe44a4ca6ce2829e5ba6ae1a68a4ccd05a67ac01219655c1
Result 34d8436444aa5c61761ce0bcce0f11401df2eace77f5c14ba7039b86b5800c08
DAG 64 loads, 16384 bytes
Cache 11264 loads, 45056 bytes
Merge 33792 total (8192 7168 10240 8192)
Math 18432 total (0 2048 0 5120 5120 0 0 0 4096 0 2048)

The cache loads are very significant and play a major role in PPA (performance, power & area). This fact was noted by someone who responded to your Medium post. However, somehow the reply was removed from public viewing. Luckily this was captured on Reddit on this counterpoint refuting Linzhi ProgPOW post..

From Medium: Sarah Osbourne reply to Linzhi

The first major thing you omitted in your attack on the insignificant ALU is the size of the register file relative to the ALU. A 12 kiB register file will require almost 400,000 gates just for storing the bits. This completely dwarfs the ‘large’ multiplier at only 20,000 gates.

The most important thing that you have conveniently omitted are the 12 completely random cache operations per loop. Note that there are only 20 math operations per loop, so the cache operations are extremely significant. The cost of integrating a 16 kiB SRAM would be at least 500,000 gates just for storing the bits. You would need a 12-port SRAM just to service these requests for one pipelined processing element (which would destroy your simple register file idea), and that is completely ignoring address conflicts and many more problems. If you want anything even remotely resembling the heavily banked SRAMs in GPUs with all their advanced request conflict resolution and so on, then it’s going to take a lot of engineering effort. You might as well become a GPU manufacturer at this point.

Posting such misleading claims do not help Linzhi’s credibility in the Ethereum community. Some people would view this action as a deliberate attempt to sabotage ProgPOW in order to protect your Linzhi Ethash miner which would be bricked by a change to ProgPOW.

Let the hardware auditors and the experts in the community present their findings based on facts and then we can discuss why we agree or disagree.

Why can’t we all be friends and have FUN like SpongeBOB instead of spreading FUD like Plankton?

4 Likes

Linzhi’s four core principles are: truth, learn from customer, innovation, customer trust.

@epic.henry

Why can’t we all be friends and have FUN 1 like SpongeBOB instead of spreading FUD like Plankton?

No. Don’t try that. Don’t like you.

EIP 1057 author bitcointalk trust page (need to login)

EIP 1057 author employee review
https://www.glassdoor.de/Überblick/Arbeit-bei-The-Mineority-EI_IE2404190.11,24.htm

EIP 1057 author speaking at coingeek event

https://coingeek.com/kristy-leigh-minehan-bitcoin-should-work-but-not-be-seen-video/

DYOR

The best crypto ASIC related work lately in my opinion is happening in Monero, look for tevador, hyc, solardiz, Tim Olson and others.
They have secured funding and tasked 4 auditors with a review within days: Kudelski, QuarksLab, X41, TrailOfBits
https://www.reddit.com/r/Monero/comments/bozr0z/randomx_auditor_selection/

One thought that is still rarely brought up is that “ASIC friendliness” just means repeating the “ASIC Resistance” pseudo-science one more time (third level maybe ASIC Assistance? :slight_smile: ).
The cost of making a Bitcoin miner is far higher than people think. Maybe we find time for a substantial article on this subject one day. We drove sha-256 from 8000 W/T to 100 W/T, we learned a lot.

@shemnon

The main question are can we delay the entry of ASICs into a ProgPow POW ecosystem, but does the mechanism proposed to delay it in a fashion that makes economic sense. A two week delay fixed by a change order is a delay, but a pointless one. Is ProgPow a similarly pointless delay?

It’s impossible to find a satisfactory answer.

ETH mining is a multi-billion USD industry. At a high-level, if we assume a network capacity of 800 MW and 4 cents/kWh, that’s ca 23 mio USD monthly electricity cost. ETH payouts right now are 103 mio USD / month.
That means 80 mio USD/month gross margin. The small guys may be hurting and fighting, but the big guys are making good money.

Remember I said a machine sells (there is a buyer) when it’s priced at 150 days ROI flat/flat?
That answers the capex question that was brought up earlier.

We are happy to answer questions about ASICs and costs and mining economics, all publicly.
Hardware manufacturers optimize along 5 dimensions that are often mutually exclusive: cost, performance, efficiency, time to market, reliability.
They shouldn’t forget about complexity either, something we are learning right now :slight_smile:
Cheers.

@timolson

It’s wonderful to see such entrepreneurial spirit and transparency!

Thanks. That means the mistakes are also transparent though.

In 09/18 we announced our Ethash chip schedule to be 12/18 tapeout, 04/19 samples, 06/19 mass production. Today we are in 06/19 and haven’t taped out yet. That means we are 3+6=9 - 2x off in our tapeout schedule. If we are also 2x off for the rest of the schedule the machine won’t sell for another year or more. If we are off by 2x on time-to-market, we can arguably be off by 2x on cost or efficiency or performance or reliability as well. We are just WRONG, and not happy about it. We haven’t taken a single prepay order or dollar.
We will continue with the open process.

I wrote this elsewhere, the division of labor in ASIC resistance is best seen as someone claiming “X cannot be done”, and someone else just doing it. Otherwise you are in an infinite circle of that other person saying “X can be done”, and the original claimant repeating “X cannot be done”.

We have always worked on the “just do it” side.

@epic.henry

I would also chastise Linzhi to do their homework and check the facts before posting incorrect information.

Knowledge is power. Kristy/Core/Nvidia/nchain/epic is chastising for homework!
chastise = “rebuke or reprimand severely”, “infliction of corporal punishment”.
There is indeed punishment for people not doing their homework.
If “epic blockchain” is even remotely involved in the audit, we already know the result.

Some homework:
https://github.com/ethereum-cat-herders/progpow-audit/blob/master/Least%20Authority%20-%20ProgPow%20Algorithm%20Audit%20Proposal%20(v2).pdf

The areas of concern were listed as
(11) Other effects impacting the ecosystem at large (distribution, economies of scale, cost, etc) and other externalities of such a change.
(13) ProgPoW’s ability to provide better decentralization

This just came in:
https://www.nasdaq.com/press-release/squire-enters-into-a-binding-letter-of-intent-with-core-scientific-for-hosting-of-blockchain-cloud-20190604-00893
https://www.bloomberg.com/press-releases/2019-05-30/squire-agrees-to-purchase-companies-with-cloud-computing-assets-totaling-2-985-petahash-to-become-one-of-the-world-s-largest

The EIP 1057 author stated this morning, linking to those news: “Core Scientific is killing it! Stay tuned for more massive announcements. This isn’t the only one.” (in Telegram, just believe me, or believe Nasdaq/Bloomberg).

Should we ask the EIP 1057 author whether some of those future announcements relate to Ethereum? What are the deals between Core Scientific and Nvidia? Core Scientific and Squire/Calvin Ayre/nChain?
The auditor better look into that (areas of concern 11 and 13), if you don’t want to be surprised by news from Bloomberg one day.

We think the current ETH mining is quite stable and decentralized, with at least 4 vendors having competitive chips (AMD, NV, BM, Inno), and at least 5 others working on chips. That’s exactly why some parties who don’t like fair and decentralized mining are working towards centralization. ProgPoW is their tool. It’s an interesting process to see this battle between centralization and decentralization unfold.

Good morning @Sonia-Chen,

Please do not put me in the same camp as Nvidia and Kristy-Leigh. (Core and nChain are not relevant to this discussion).

For the record, ePIC has not done the analysis on ProgPOW to determine whether it is a positive or negative change for the Ethereum community. All I did was present to Linzhi some facts and empirical proof that Linzhi’s assertions are incorrect.

I clearly showed you in this link ProgPoW Audit Delay Issue - #53 by epic.henry that both Nvidia and AMD GPU’s perform virtually the same with 256-bit wide GDDR5 memory i.e. both take a 50% hit in hash rate. And also why Linzhi’s Open ASIC design is inaccurate.

Yet you respond back with FUD.

If you have alternative information about GPU performance, please present this in your post. Likewise if Linzhi doesn’t agree with ePIC’s and Sarah’s comments about the need for complex memory cache, please show us how your design changes with the addition of a cache.

Please check your facts. Alex Ao (Innosilicon’s VP marketing) admitted on Grin forum that Innosilicon did not ship their A10 Ethminer. Check out this post. Innosilicon would be stupid to ship a revised A10 miner when they are 1/3 of Linzhi’s claimed hash rate.
https://www.grin-forum.org/t/grin-improvement-proposal-1-put-later-phase-outs-on-hold-and-rephrase-primary-pow-commitment/4653/23?u=grinorovitch

And as the Ethereum community knows, Bitmain E3 is lame duck. It basically cost the same, performs the same as 6 RX570 GPU and uses the same power. No one would buy an E3 over a GPU rig because there is no advantage and no resale value.

Who are the 5 other vendors working on Ethash miners? Show us the proof so we know it’s not Sonia Chen FUD. If it is true, you are signing Linzhi’s death warrant. The community will fork later this year to brick those 5 new rigs and your Lavasnow miner will be killed in the process. I don’t think your CEO Chen Min will be happy that your FUD will cost Linzhi a lot of money by causing a fork and resulting in Linzhi having to scrap any Ethhash inventory.

2 Likes

@sonia-chen, in response to your post, I provide 1 knock, 1 question and 2 compliments.

1. Linzhi Core principles at conflict

Sonia, from what I can see truth doesn’t seem to be one of Linzhi’s core values. You berate “Sarah” on her post but claiming FUD and then you remove both Sarah comment and your reply from public view. I have included your reply on Medium below.

Hidden Linzhi reply to Osbourne’s critique of Linzhi’s Open Chip Design The history of the Sarah Osbourne reply is this: | by Linzhi ASICs | Medium]

Linzhi ASICs

Mar 30

Thank you “Sarah Osbourne”. We received a lot of very good constructive feedback, for now I include yours in the list. Other great responses came in over github from tevador, solardiz and Peter Salanki. We are collecting all responses and will then think about how we go to the next level. Maybe we will take this design to github and continue a revision/issue process there, so it’s more organized.

Is your feedback given in good or bad faith? What is your interest? Who is your employer? We are seeing amazing things around ProgPoW everywhere. We know that we don’t FUD (but we make mistakes). Do you FUD? Your account seems to have been created only for this one reply, which immediately goes into great details of a chip design. Weird, yes?

We give you the benefit of the doubt. We assume you are sharing knowledge for truth finding, and you are trying to help us fix mistakes in the design.

Thank you!

If Linzhi were interested in the truth, why don’t you do the work to model the 16kB cache and update your Open Chip Design with the complete ProgPOW design? You will find that your claim of 1.2GHash per chip will require exponentially more bandwidth and logic that than you think. This Rocket science to most but innate knowhow that we GPU designers know how to solve after decades of experience designing complex caches e.g. that service 4,000 cores (threads) operating at >2Ghz, all needing simultaneous memory access and needing to deal with memory contention.

2. Does Linzhi’s Bitcoin expertise apply to Ethash and ProgPOW?

You claim that your CEO Chen Min’s, Bitcoin design background makes Linzhi an ASIC design expert. I would argue that the design principles for a Bitcoin chip are very different those used for an Ethash or ProgPOW ASIC. That said, we know that Chen Min during her tenure at Canaan used a VCA (Value Chain Aggregrator) to design at least 2 of their chips.

Bitcoin/SHA256 ASIC’s are simple designs with each core taking less than 100 lines of code; you take 1 core and replicate it over and over again in an ASIC core. The difficult part is that custom design process which takes time and a lot of hand crafting. Full-custom layout that requires greater attention to area and performance than the full digital (ASIC) flow, but has less stringent requirements for speed and less need for control over device-level layout than datapath or analog layout: We call this type of layout "custom digital layout.” More details about custom design methodology in this EEtimes article. https://www.eetimes.com/document.asp?doc_id=1277368#

By contrast, you would use a digital design methodology for more complex ASIC’s like those for Ethash and ProgPOW (although Ethash and the FMV block are relatively easy to design). As an example, custom Bitcoin ASIC’s are 16-20mm2 in size and digital design GPU’s are typically 200-600mm2 in size, which are an order of magnitude larger than BTC ASIC’s. The skill set needed for digital design is different than those needed for custom designs.

3. Open and transparent audits

I totally agree with you on the need for transparent audits and the Monero model is a great one to mimic. It’s pretty clear to expert ASIC designers like ourselves and to Linzhi that any audit will be ineffective if the audit firm doesn’t have the latest design tools, in depth GPU design experience, in-depth development experience with crypto algorithms and memory controllers.

It seems many Core Devs like @Anlan and @fubuloubu share the same concerns about the lack of transparency wrt auditor selection as shown below.

4. Why can’t we be friends?

Irrespective of what you think, we have a lot of respect for your CEO, Chen Min. Maybe we can be friends and ePIC can help Linzhi design that complex memory controller you need for ProgPOW. Any mistake in your design wrong will cost Linzhi several million dollars for masks and wafers as well as a 3 month schedule hit for chip spins and fab cycle time.

I’ll close this long post with a song by War, Why can’t we be friends? :slight_smile:

1 Like

Questions (if you are still being transparent):

  1. Are AMD and Nvidia working on future mining-only chip designs? If so, do you have link to public release documents.
  2. Are these the latest BM/Inno miners? Are there more available privately? Are they doing any private mining with more efficient hardware that is to be released?
  3. If there are 5 others working on chips (I assume you are one of them), how close are they to be production? How much more efficient will they be? Will they self-mine before release for “quality assurance purposes”?

Interesting questions I’d like to know, if you are being so transparent so as to help us along.

1 Like