ProgPoW Audit Delay Issue

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

Proposal to Alleviate Any Conflict-of-Interest by the ProgPoW Authors

If the community’s problem centers around the authors’ alleged business interests, then change the loop constants. I can’t emphasize this enough. There could be a straightforward community effort to collect the best ProgPoW tunings for a variety of popular GPUs, then decide on something that’s “market fair.”

I’ve seen charts that quantify the power-per-hash using the current constants, but that metric doesn’t consider % of resource usage for each card. Yes H/W might be the same across cards, but the overall hashrate on some cards will be artificially low (and still proportional by power).

If such information is not already available, we need a chart of the optimal values for PROGPOW_CNT_CACHE and PROGPOW_CNT_MATH for a variety of popular GPU’s. The optimal loop constant values are the smallest numbers which give a “saturated” maximum hashrate on the card. This requires use of the vendor’s devkit telemetry tools, but a simple recipe and test harness could be made to allow home GPU enthusiasts to try all combinations. With a spreadsheet of GPU cost, power, hashrate, and optimal loop constants, the community can make an informed, transparent decision on the values for the two loop constants, and thereby openly divide the market based on different GPU vendors’ capabilities.

2 Likes

@fubuloubu

Thanks for asking.
I work for a small self-funded chip startup, we are a bunch of folks in a small office in Shenzhen basically. My answers to your questions are “market chat”, things we hear, think, guess, calculate.

Are AMD and Nvidia working on future mining-only chip designs?

I doubt it. Agree with @timolson “using GPU’s for PoW is like using a hammer to drive a screw”. GPUs are good to secure small networks or new coins, and for development.
For now PoW chips are fixed-function, they tend to have much lower margins (utility chips) and are thus not interesting for Nvidia. Therefore, Nvidia will focus efforts on marketing to create enough instability to deter ASICs and to keep the mining revenues on GPUs through forks (btw, in our view the competition between Nvidia and AMD is largely for show, to keep antitrust regulators happy, but that gets us into politics and totally away from technology).

If so, do you have link to public release documents.

No.

Are these the latest BM 1/Inno 1 miners?
Are there more available privately?

I’m combining these two questions.

Let’s assume a vendor will always try to sell their most advanced product. I think neither Bitmain nor Innosilicon are currently offering Ethash machines. I contacted them through a friend this morning, just asking for a quote - anyone can do this. We do know both Bitmain and Innosilicon are “close” to a competitive offering, technically. Bitmain has sold 20k E3 (our latest estimate), Innosilicon decided not to sell/offer for sale.

I want to take the time to walk through the economics, using Bitmain E3 as an example:

Why is the E3 not being offered anymore? When will it be offered again? At which pricepoint?
Those questions can be answered rationally, excluding a few exceptional things like insolvency, unsold inventory blocking the market, willingness to loose a lot of money to bankrupt a competitor, trade wars, politics, etc.

We need to know three things: cost, margin, ROI.

  1. Cost
    Since the E3 is a close competitor to us, we spend some time to analyze its cost. We get a machine, take it apart, think about it, and put some numbers into a simple spreadsheet. The key cost component of an E3 are the 576 memory dies. At the very lowest, we can imagine cost of 40 US cents / memory die (most likely it’s higher).
    We calculate a lowest-possible E3 machine cost of 840 USD.

  2. Margin
    Nvidia needs a gross margin of 60% to be happy (you can take this number from published financial reports). Any new business (sales) with a lower margin is bad for Nvidia, any new business with a higher margin is good for Nvidia.
    We don’t know the margin Bitmain is targeting, but let’s just put it at 30% for now.

  3. ROI
    The current ETH networks pays 2.15 cents/MH/day (bitinfocharts.com)
    We assume an all-in power price of 4 US cents (that’s a realistic number for the purpose of this calculation, just believe me)
    An E3 that hashes 190MH at 800W thus generates 2.15 * 190=4.08 USD at a cost of 24 * 0.8 * 0.04=0.77 USD for gross revenue of 3.31 USD / day
    The machine sells, in the current market, at 150 days ROI flat/flat (again just believe me), that means 150 * 3.31 = 496.5 USD

Now we can put it all together:

At the current Ethash profitability, Bitmain would need to offer the E3 at 500 USD to find a buyer, but it wants 840 * 1.3=1,100 USD. Noone will order, Bitmain won’t even offer, nothing happens.
How high does the Ethash profitability have to go for E3 sales to restart: 1100/150=7.33 USD/day + power .77=8.1 USD/190=0.0426 cents/MH/day.
At the current difficulty, that would mean an ETH coin price of 246*(0.0426/0.0215) = 488 USD.

We got it! E3 sales will restart if ETH goes back to 488 USD :slight_smile:
This may be impacted by irrational assumptions aka “risk taking” by certain market participants, but by and large this gives you a good mental model to relax and watch what’s happening.

Are they doing any private mining with more efficient hardware that is to be released?

Who can rule this out after all that happened in recent years.

Who is to say that “they” must be the ASIC designers or manufacturers. It could also be the ASIC (or GPU) buyers that want to do private mining with more efficient hardware that they have secretly acquired. You may remember tweets of the EIP 1057 author directed at you (since deleted)

  • “Genesis Mining and others also benefitted heavily from private optimisations for 2+ years”
  • “I even traded VBIOS’ for hardware discounts”

Yes this is mudslinging, but since an unfair story is repeated forever (“greedy chinese asics”), you might as well hear the other side once in a while.
We know who comes to us and tries to meet and tries to buy, and what they want. Some ETH community members should be flies on the wall, that’d be fun…

I know this is annoying, but it’s a fact that the EIP 1057 author is doing big business deals with Calvin Ayre’s and Craig Wright’s companies (just read the news, linked in the last post).
Whether mining becomes more transparent or more private is a consequence of the aggregate decisions of the community.
In a community that prefers theories over business scrutiny, business people will continue without oversight.

If there are 5 others working on chips (I assume you are one of them),
how close are they to be production?

We are transparent, we are trying this. We are very far from production :slight_smile:
I want to reiterate a general invitation to our office and factory in Shenzhen. ASICs are fun, a lot to learn. Let’s go through the others - market chat…

  1. vidtoo in Hangzhou: even further from production than us
  2. Ingenic in Beijing: just starting with crypto, confused about Ethash vs ProgPoW, even further from production than us, but don’t want to underestimate them
  3. Samsung: May be the real reason of Nvidia’s ProgPoW effort (in addition to excluding Bitmain). Instability will keep them away.
  4. unknown (to us) team working with Xilinx ZU6EG/9EG: Since ProgPoW has a lot more logic than Ethash, it has brought some FPGAs back in play. We don’t know many details about this effort or how it would work for Ethash, but the team is real afaik. If ProgPoW progresses, I would love to hear from people who take a serious look at the ZU6EG/9EG and are willing to share their findings openly.

I admit that I don’t have a specific fifth one for you. The entire sentence reads “We think the current ETH mining is quite stable and decentralized, … with at least 5 others working on chips.” You bet there are at least 10, 20 or more “others”.
In Shenzhen alone we have about 1000 semiconductor startups. Maybe people forgot the garages. The beauty of PoW chips is that you immediately have great constraints to focus your design skills on. Professors all over semiconductor classes are saying “This semester we are going to design an Ethash ASIC”, and the students say “yeahh… coool…” :slight_smile: Then you have existing chip businesses with under-utilized design teams who need to be kept busy, so why not try a PoW asic?

Bottom line: Noone is close to production.

How much more efficient will they be?

OK the crazy fun answer first: ETH DAG size increases linear, but semiconductor density increases more than linear. How about a single-die 5nm chip generating 20 GH hashrate? How about 3D chips, high-density wiring between dies, silicon photonics?

More seriously, your question asks for an economic answer: As much as the monthly payouts for Ethash (or ProgPoW) increase, efficiency gains will be made. However GPUs are holding up well against E3 and A10.

How easy or hard is it for higher-efficiency machines to push out lower-efficiency machines?
Before we calculated that E3 sales could restart if ETH coin price reaches 488 USD.

Let’s calculate how low coin price can go before the big GPU operators would be pushed out:
Let’s take a GPU average of 30 MH at 150 W (there is quite some variance in this).
Daily power cost: 0.15 * 24 * 0.04=14.4 cents
Daily revenues: 30 * 0.0215=64.5 cents
246/(64.5/14.4)=54.92 USD

So in this way of calculating, ETH price could go as low as 55 USD! That shows how strong the position of existing machines is, once they are paid for and installed.
Let’s try another way of calculating recycling resistance, from SHA-256 machines: We know the Avalon machines best because we designed and manufactured them. Here in Shenzhen nothing gets wasted, we see the parts of our old machines in the parts market, then we know the recycling situation. We are certain that all A6 have been recycled, we are guessing about 50% of A7 have been recycled, and we think no A8 has been recycled yet (we haven’t seen A8 parts in the used parts market).

I’m using averages: A6 = 3.5T@1100W. A7 = 6.5T@1000W, A8 = 11T@1200W.
At power cost of 0.04 cents/kWh, and current SHA-256 rewards of 27 cents/TH/day, it looks like this:

A6 (100% recycled): 3.5 * 27=94.5 cents revenues, 24 * 1.1 * 0.04=1.06 USD cost.
94.5 < 106 : 100% recycled

A7 (50% recycled): 6.5 * 27=175 cents revenues, 24 * 1 * 0.04=0.96 cents cost.
175 > 96: 50% recycled

A8 (0% recycled): 11 * 27=297 cents revenues, 24 * 1.2 * 0.04=1.15 USD cost.
297 > 115: 0% recycled

This gives us a lot of confidence, it looks right! Some people have higher power costs, lower power costs. Higher or lower labor or capital costs. But in the end it all has to come down back to earth.
For ETH, there is a lot of variance in GPU performance, and GPUs will continue to improve. If an E3 needs 488 USD/ETH to sell, but (some) GPUs by (some) operators can still be profitably run at 80 USD/ETH, that means the E3 will not push out GPUs anytime soon.
The pain you are hearing from GPU operators at 150 USD/ETH, 120 USD/ETH, 100 USD/ETH and lower is the small GPU guys hurting from competition with the large GPU guys. It has nothing to do with ASICs.

Bottom line: expect incremental efficiency gains, because theoretical efficiency gains are held back economically.

Thinking about these numbers may be a bit depressing. The ETH community shuffles hundreds of millions of USD to some very weird business people and megafarms. If the community cannot or doesn’t want to stay in control of this, or thinks it can do better with less waste, then switch to PoS faster.

Will they self-mine before release for “quality assurance purposes”?

Depends on what the community or the customer of the manufacturer wants. We are open to community oversight, just board a plane to Shenzhen.
Why do we try an open process? Because we don’t believe in fixed-function chips and are targeting programmable chips for which we need to cowork with developers.

Hope this makes sense, thanks again for asking.


Final Thoughts:
I’m sure I made mistakes in this post, some numbers wrong, some thought paths wrong. So what, we are learning. At least I’m sharing something. Maybe it’s helpful to an auditor.
The ProgPoW team is also fun, once you can decode their language. Kristy, Henry, Jon Stevens, Jean Cyr, Teddy, Amel, Sarah, Heisenbug, Greerso, etc. - ha ha.
The details of their corporate scheming don’t matter because we will most likely never see leaked contracts anyway. What’s happening is obvious though, just do research, read news, connect the dots.
Yes the community should turn those knobs and make sure mining is fair, but it won’t be enough to address the deeper problems of GPU mining in that large companies such as the one where the EIP 1057 author is CTO can gain an unfair advantage because they have co-opted the community to monopolize the supply chain for them down to the one chip vendor they have hooked up with. The solution to that is to bring Samsung, Bitmain, Inno and small guys like Linzhi in to decentralize. A self-serving argument :slight_smile:

For reference here is a collection of writings of team ProgPoW, maybe someone can run some stylometry over this.
Dust off your bitcointalk password, login and check out the trust page of the EIP 1057 author. Follow other links. Do your homework.

20180518 EIPs/EIPS/eip-1057.md at master · ethereum/EIPs · GitHub
20180530 The Problem with Proof of Work. Proof-of-work had a goal. It was a… | by K. L. Minehan | Medium
20180602 A Perspective on ProgPoW. A lot of research was done into ProgPoW… | by K. L. Minehan | Medium
20181025 Understanding ProgPoW. Performance and Tuning | by IfDefElse | Medium
20190111 ProgPoW FAQ. After gaining some mainstream press… | by IfDefElse | Medium
20190207 Re: My take on ProgPOW. Thank you for approaching this… | by IfDefElse | Medium
20190330 The Cost of ASIC Design. It’s not rocket science. But it is a… | by IfDefElse | Medium
20190330 Everybody knows ALUs are relatively tiny circuits. | by Sarah Osbourne | Medium
20190318 https://medium.com/altcoin-magazine/13-questions-about-ethereums-movement-to-progpow-e17e0a6d88b8
20190327 Comprehensive ProgPoW Benchmark. By a miner, for the miners! | by Theodor Ghannam | The Dark Side | Medium

Happy weekend @Sonia-Chen,

I am responding to several of your comments including:

    1. potential ASICs for Ethereum;
    1. Why Ethereum doesn’t scale with process nodes;
    1. Other information/FUD

1. Follow the Money – why small companies are eyeing Ethereum?

There’s saying in North America that encapsulates what you are pointing out here about multiple companies eyeing Ethereum ASIC’s … “Follow the money!”

To elaborate, Ethereum is the 2nd largest coin and represents over $700M USD in mining rewards. Currently there are only 2 serious contenders, AMD and Nvidia (and counting the weak E3 effort from Bitmain) and in theory, ASIC’s should have an overwhelming advantage over GPU’s. So multiple companies are relishing the opportunity to make bijillions of dollars by building Ethereum ASIC’s.

This is no different than how the market evolved with Bitcoin ASIC development. The path to Bitcoin success is littered with defunct companies, failed efforts and $100’s of millions of dollars of lost investments. I point you to this Bitcoin Wiki which shows:

  • 28 ASIC’s going to market
  • 10 ASIC’s being canceled
  • About 50 ASIC’s announced but status is unknown

Ultimately only Bitmain, Canaan, Innosilicon/Holong and Whatsminer/Bitwei were successful. Even a giant with deep pockets and early access to 7nm nodes like GMO failed and withdrew from the market.

Ethereum is a much more complicated design and has the added cost burden of memory dependency (that I will post on a different thread one day).

As you well know, Ethereum ASIC’s are not easy to build. Even with a superstar designer like your CEO, Chen Min, Linzhi is at least 11 months (Aug 2018 to June 2019) into development with no tape-out date in sight. Assuming you are taping out at the end of July and the earliest you will see “super hot lot” samples is Nov. 7. Assuming another 2 weeks testing and qualification, you are another 80 days from production depending on fab availability. Oh and add another 2 weeks for OSAT (Outsourced Assembly & Test) which takes a little longer due to your use of an interposer and HBM stacked die.

Linzhi’s total project time is “guestimated” to be 19 months (i.e. August 2018 to Feburary 2020). That’s a far cry from your original presentation in September that was projecting April 2019 projection or 9 months (August 2018 to April 2019)

2. Semiconductor densities translate to non-linear improvements

Sonia, my friend, let’s debate using facts and empirical proof.

Your comment makes no sense as Ethereum is bottlenecked by memory bandwidth and not semiconductor logic; therefore, Ethereum hashrate will improve but only to the extent of available memory bandwidth (in other words, zero improvement, unless memory subsystem changes).

Case in point is the 7nm Radeon VII at 90MHs (1400c/1000m) compared to the 14nm Vega56 at 38MHs (1138c/800m). Performance increases by 2.4x which is the increase in memory bandwidth by 2x bus width (ie. 4096-bit vs 2048-bit) multiplied by 1.25 or 1000MHz/800MHz (increase in memory clock).

38 MHs x 4096/2048 x 1000/800 = 95MHs (close to the measured 90MHs)

To reiterate, moving from 14nm to 7nm and increasing the core clock by 23% (ie 1400MHz/1138MHz) DID NOT improve hashing performance beyond the increase in memory bandwidth.

3. ProgPOW and BSV conspiracy

What point are you trying to make about Kristy, Calvin and Craig? Are you suggesting that Bitcoin SV is going to adopt ProgPOW as their POW instead of SHA256 and nChain? ROFLMFAO

4. Help from friends

Send me a PM. We can help you with design of your ASIC and procurement of HBM memories. My team is from AMD and has extensive experience with HBM through 2 generations of Vega design and 8 generations of GPU design. Even the Beatles know that they need to get by “With a little help from my friends.”

3 Likes

Thanks @epic.henry for referencing my benchmark. I’m glad I did them getting some truth. I haven’t been active because this whole damn progpow discussion continues to go around in circles, I’m sick of it all.

I want to know a straight answer from the Devs working on ProgPoW Audit
A) Is it 100% agreed that “Audit must be complete for ProgPoW to be implemented?” I’ve heard this thrown around but I’ve haven’t heard it as the official statement for inclusion.
B) Do we have ANY time-frame now because of this company that dropped out to do the ASIC tests?
C) By April 2020 The next “Ice-age” will start effectively putting ProgPoW and the Iceage together for miners meaning it’s damn near disaster. What is the point of the ice-age until PoS is few months out(which it isnt)?

5 Likes

@xazax310

Thanks for all your hard work pulling the analysis together. It must have taken days of benchmarking, reconfiguring systems and tuning memory clocks. I thought your article would have put an end to the AMD vs Nvidia argument but the FUD and mudslinging continues. (Btw, are you going to update the data for DDR6 and Navi? I have some boards on order so I can send you test data when I get the cards. Unfortunately, it won’t be an apples to apples comparison as Nvidia uses 384-bit wide memory as opposed to AMD’s 256-bit wide bus)

I too am sick of the controversy around ProgPOW. Ultimately my company, ePIC Blockchain decided to step in and contribute our expertise, which consist of both GPU and ASIC design, to help with the ProgPOW audit. See this post to Hudson Jameson after all requests to emails, PM’s, to ECH (Ethereum Cat Herders) and Least Authority were ignored for a week prior to my post.

You ask good questions since the whole audit selection process has not been transparent as Anlan and other pointed out in this post.

I have little faith in the audit as the goals and methodology has not been made clear. For a more robust audit, the methodology also needs scrutiny and input. ECH and the core devs are not ASIC and GPU experts and, therefore, are not the best people qualified to assess whether the methodology is valid and complete. ePIC offered to provide input and help with the audit, even as a contributor, to fill in the gaps but that offer was also met with silence.

There are a lot of open questions to address in the audit and expertise needed which is not generally available, including ASIC development tools and GPU architecture and driver knowledge including the ability to code to the metal. @timolson noted in this post that the audit is a thankless job, that loses money and needs tools that many firms don’t have. I would also add that the Linzhi Open Chip Design needs to be synthesized to show if their claims are true and not.

I finally received an email 9 days ago that ECH had selected a hardware auditor but that has not been announced yet. Minutes from the core dev meeting #62 stated that ProgPOW is likely to miss Istanbul due to the hardware audit slipping.

Based on current pace of ETH 2.0 development, it is almost impossible for PoS to go mainnet in 2020. The pace of research is slow; there is a lot to be done to ensure security of the network and to prevent a hardware arms race.

EDITS - to fix links and typos

2 Likes

Sorry, but unfortunately I think @xazax310’s benchmark is not what is needed, and it’s probably misleading.

First off, it looks like he only tested one program (a single block height.) Any single program may have a non-representative distribution of math operations, so many possible block heights / programs must be tested and an average taken.

Secondly, as I mentioned above, merely optimizing the hashrate & power per card does nothing to show whether the card is near 100% utilization on all resources. The ProgPoW authors could have tuned the loop constants for Nvidia cards, and xazax310’s benchmark would not show the bias.

This is not FUD. I have zero interest in Ethereum politics. I own zero ETH and do not mine it. If you want to claim that the ProgPoW authors have no Nvidia bias, follow the proposal I wrote above, which requires modifying the loop constants and testing GPU resource utilization NOT total hashrate or hash-per-watt. Do the ProgPoW authors’ proposed constants cause higher utilization on Nvidia cards vs AMD’s? xazax’s benchmark does not answer this question.

Anyone can follow these steps to benchmark resource utilization. I agree with Tim Olson, we have been very clear on how to benchmark ProgPoW.

Please note, this was, admittedly, on 0.9.2 of ProgPoW, so it is outdated.

3 Likes

For those that were curious on a independent review of 40+ different GPUs using 8-10 different settings/configurations per GPU, all recorded live on twitch.tv and recapped on YouTube for any audit/review here is a Google Sheet covering my 0.9.2 benchmark results.

Additionally, on the Channel “BitsBeTrippin” you can search “PROGPOW” and find each of those GPUs testing details.

I am about to go through a refresh of testing with the latest architecture (RDNA based Radeon 5700 XT) and revisit the entire RTX lineup with latest miners avail. If there is something specific the community would like me to cover, I have over 70 different GPU types in my studio. If it makes sense for any selected auditing party to do testing, I will make available this lot of GPUs for their independent testing. This includes nearly the entire lineup from AMD and NVIDIA since 2012.

3 Likes

To @timolson point on changing the loop constants or as us less technical have been calling it “turning the knobs”, this was already done. IfDefElses original spec was 0.9.2. Community testing led to 0.9.3, this was not a change dictated by IfDefElse it was a result of a community effort.

1 Like