ProgPoW Audit Delay Issue

@gcolvin @fubuloubu

Only 1 ETH ASIC miner, Bitmain E3, has been shipped and made available to the public. It never caught on because the economics was inferior to GPU’s. ie. 1 E3 rig was equivalent to 6 RX570 GPU.

Innosilicon A10 was announced but never shipped to the general public. Inno commented on Grin-forum that there were issues with the ASIC and therefore being modified and may go into production. IMHO, this is unlikely as it is now 9 month late and inferior to Linzhi at 1/3 the performance.
https://whattomine.com/miners/4-innosilicon-a10-ethmaster

Linzhi announced but as @Sonia-Chen states on this thread, they may tape-out in August which means October production at best. However, confidence seems low as there have not updated their website yet.

2 Likes

Epic Henry! (whoever this is today).
For once this is an entire response from you without any disinformation or deception or FUD. Great! We should congratulate each other on FUD-freeness, how about that?

I see everything just described by Epic Henry the way he did. Before we thought a total of 100k Bitmain E3 were made, but now we believe it may only have been 10-20k. 100k would mean < 20 TH of the total hashrate of 160 TH right now, 20k would mean < 4 TH out of 160 TH.

Our Ethash chip, late or not, is not a threat to anyone just considering how small we are.
We will definitely do a tapeout announcement, in line with our open approach since the beginning.

Thanks Henry, I would appreciate if we can continue in an open and honest way going forward.

@greerso

I have 4 pieces of feedback regarding FPGA mining on Ethash. I would like to know what evidence you have to support the claim that there are FPGA miners on ETH?

1. Memory bandwidth limitations on FPGA
FPGA’s are not viable for mining ETH as they are memory interface bandwidth bound. From a high level, Xilinx FPGA’s eg. VU9P/11P/13P chips, U200/250 boards and 1525 boards support DDR4 in up to 256 bits wide (depending on board layout). The DDR4 limitation makes FPGA’s uncompetitive (to low cost GPU’s like the RX580 at $100 street price compared to $3500-$10000+ for 1525 and U250 boards). I can do the bandwidth math if you need it but it’s too early in the morning.

You may be able to get GDDR5 and GDDR6 memory controller IP but I am unable to validate whether such IP exist and whether the business model is viable (ie. licensing fees). Internet searches yield zero hits on Xilinx boards with GDDR5 and GDDR6 memory.

2. Economics of mining on moderately priced FPGA
Most of the commercial FPGA miners are using VU9P or 1525 like boards. The ROI is relative long at $3500+/board for DRR4 or GDDR5 performance if you accept my memory bound assertion. Assume than the board is 50W and equivalent to RX570 at 30MH/s and you get an annual return of $12/month or $120/year which translates to 30 years ROI. Why would you not mine SHA3 or X11 or other Altcoins with higher returns?

3. Secret mining on FPGA
The hardware acquisition cost of VU9P and 1525 boards (now discontinued) are very high relative to ROI period. Why would you secret mine on FPGA when the hardware cost are so high at $3500+ per board?
If someone had a viable FPGA bitstream, they should sell the ETH bitstream and try to monetize the NPV (net present value) of the mining rewards for some portion of it by licensing the bitstream. However, you can NOT make enough money by mining ETH on FPGA’s … but then you will not sell any bitstreams if FPRGA performance levels are similar to GPU’s.

4. Known FPGA ETH miracles
There are 2 known FPGA ETH hardware fairy tales. They are:

A. Ubimust in Montreal with a 1.9GHs hash rate claim
The claim was widely echoed on the internet but the rig based on the 8x1525 boards never shipped and Ubimust does not list this product on their website. It is technicially impossible to get this type of performance on DDR4 memory.


https://ubimust.comh

B. Squirrel Research - Acorn boards
There was a claim by SQRL that ETH performance would be improved by 30% using low end FPGA board to offload Keccak processing from a GPU. Needless to say, this product did not work and the bitstream never shipped. Rumour has it that Kristie-Leigh aka OhGodAGirl of ProgPOW fame was involved in the bitstream development through her Mineority connections with SQRL.
https://bitcointalk.org/index.php?topic=4391318.740

@Sonia-Chen, I love you too. Shall we get married at Dappcon.io in Berlin on Aug. 21 for the entire Ethereum community to witness? Hudson @souptacular can be my best man and Kristy-Leigh @OhGodAGirl, can be your Maid of Honor. We can merge our 2 companies to build an Ethereum ASIC to collectively mine ETHash, SHA3, ProgPOW and POS algorithms. :joy::rofl::upside_down_face:

2 Likes

Yes, because she (and many of the miners advocating) has direct experience working in the industry, including experience with the supply chain aspects of mining, hardware design, and has spent time with some of the hardware manufacturers in the industry. Everyone has been calling it “conflict of interest”, but expertise and CoI are two sides of the same coin. Phil has expertise in software security and compilers and many other things, but there is something to be said for practical experience with hardware vendors, running a mining operation, etc. As I said before, I respect both people’s opinions on the matter.

This is the unfortunate side effect of the fact that not doing anything is also favoring a special interest, and sets a governance precedent that we are incapable of making tough decisions and thus can successfully be controlled into inaction by that special interest in the name of “not picking sides”. At some point, you gotta make decisions.

ASICs have higher efficiency than GPUs, so really what you are getting is an increased hashrate for about the same marginal cost and energy expenditure. Therefore, ASICs do not have a higher cost than GPUs in that regard, it takes the same amount of money to purchase 51% of the hashrate no matter what hardware is used. The amount of cost expended is directly related to the amount offered by mining rewards, which is why we call it the “security budget”. ASICs don’t change that math.

What does change is the number of people operating that hardware, and the number of people you have to convince politically to do an attack. People talk about “rental attacks” with GPU hardware and reference the ETC 51% attack. In that scenario, you would need a large number of GPU miners to feel apathic about Ethereum mining and list their hashpower up for rent. As long as we remain the largest and most profitable use of GPU hashpower, this really shouldn’t be possible.

Using Bitcoin for example, the number of political entities you need to convince is less. When CZ wanted to reorg the Bitcoin chain and steal back Binance’s money, he didn’t try to assemble a large and political diverse group of ASIC miners through hashrate rental, he talked to the mining pool operators that he knew and most notably Bitmain, who has a large portion of the Bitcoin mining hardware market (and operate a large amount of machines themselves). Ultimately, he relented because of community sentiment against the idea, but he definitely could’ve made it happen, and a less benevolent actor acting in the dark with the right incentive might not react that way. This is the kind of attack scenario I worry about.

I’m one, and I think Martin Swende changed his mind over the course of the last few ACD to be for the proposal. I believe a majority of “core developers” are for this proposal, and not because of a “conflict of interest”, unless simply talking to a person is enough to get you painted as having a CoI.

This is a fair point. Any grassroots campaign (even one paid for by mining hardware manufacturers) is likely to have this sort of effect. At some point we’ll have to make tough decisions to do things like reduce the mining reward. If we’re incapable of making tough decisions now, it does not bode well for when we reach that point.

I have a confession to make: I earned $40 worth of ETH from mining with my desktop in 2017. That was my first experience with Ethereum. It took me a month to do it though, so I figured I’d be better off earning money from working on core infrastructure for Ethereum and being an application developer. But I understand that $40 I earned 2 years ago and the fact I support this proposal is enough to paint me with the dreaded CoI scarlet letters.

Seriously, why can’t people just evaluate things for themselves instead of painting CoI on everything they disagree with? It makes for piss-poor discussions.

Everyone has a Conflict of Interest in a network where everyone has their own self interests or the interests of their companies at stake. If we cannot understand that and take it into account in the decision-making process, instead of sticking our fingers in our ears whenever we see those CoI scarlet letters, how are we ever supposed to make contentious decisions? I’m sorry for getting worked up over this, but CoI is my least favorite term and it’s how we’ve forced other important community members out before. Good decision makers can take these things into account without relying on it as the crux of their argument.

1 Like

Here’s a link to Martin’s post (from March) with his reasoning for supporting ProgPoW:

As I said before, I have seen several who were against or abstaining from support for ProgPoW switch to being in support over the past year. I’ve seen exactly zero switch in the other direction.

Support for ProgPoW seems directly proportional to the amount of time spent analyzing the arguments. As a point to that, Phil’s blog post was written over a year ago, and I don’t think he has revisited the topic since.

1 Like

@elliot_olds

what are we more worried about, people from outside the ecosystem attacking Ethereum or mining companies attacking it?

Are Core Scientific and nChain inside or outside the ecosystem?

I think you want to decrease the chance of attack (increase the cost of attack) of any single entity, whether inside or outside the ecosystem.
The best way to get there is sustained competition between as many parties as possible aiming for both cryptographically and thermodynamically provable PoW. “Parties” means anyone from chipmakers to machine/system integrators to hosters/miners/mining companies to mining pools.

Despite my disagreements, Kristy deserves props for engaging with the arguments of ProgPow opponents.

Kristy is your attack vector, from within.
They created the problem (threat) they are now pretending to fix. When someone comes and tries to solve a problem that doesn’t exist, think harder. You may need to do more than just say “no thanks”.

When the ASIC fear campaign started, global Ethash hashrate was 265.8 TH (May 30, date of the article), and today it’s 177.9 TH. Why?

The #1 problem with PoW: It’s open to the kind of social attack ProgPoW is pulling off. If you are loosing on the hashrate, who said you can’t try something creative to fight back?

[Linzhi seems to be] quite small and without much influence

True, and good. PoW is a service to the network.

For instance miners coming onto the dev calls to lobby for this and being treated as just normal concerned community members.

Have you found out the identities of Mr. Def and Mr. Else?
Does the community agree with the verification slowdown due to ProgPoW and its impact on light clients?

ProgPoW was kicked off by Nvidia, initially staffed with about 15 people in total. It seems to be a rather standard attempt by Nvidia to control a market using proven marketing. Forget what they say about being volunteers and the fake disclaimers under their articles.

attacks from ASIC miners rather than external actors.

You mean “ASIC miners” as in people already running Bitmain E3 today?
Hashrate is impartial, you always want the hashrate distributed between as many different parties as possible (logically and physically separated).

Maybe you are assuming that someone who is already mining on the network today is less likely to attack than a new/external miner?
In that case you are excluding the possibility that ProgPoW was brought forward by one large existing miner to become even larger, and be able to dominate the network and extract value at will.

The chance of an existing miner with known-good intentions today turning bad is equal to the chance of a new miner joining with either good or bad intentions from the beginning.

doesn’t really engage with the issue of how the cost for an external actor to attack the network is higher with ASICs

Buying hashrate is always the most expensive (and for new hardware also slowest) way to attack a network. From most to least expensive you have: 1. buy 2. rent 3. steal
There are some smart (as in business-smart) ways that are close to #3 such as financing a purchase and then not paying.
ProgPoW is also close to #3 because it steals hashrate from the network by excluding ASICs and thus increases the relative share of the hashrate of the ProgPoW proponents.
ProgPoW thus reduces the attack costs (which I believe is the intention).

I believe the best way to increase (internal or external) attack cost is competition between chipmakers, but I should think about a long-form article to make that point.
If all parties (from chipmaker to pool) are under competitive pressure, noone will be able to accumulate enough profit to dominate the entire system.
There will be no centralization, and attack costs will be high.

What we’re really trying to do is lower the probability and severity of future attacks on Ethereum.

ProgPoW increases the probability and severity of attacks.

This article is the kind of thing we should have been debating before ProgPow got the tentative go-ahead.

You didn’t?
Some comments, quoting the article (KLM for Kristy):

KLM: The equation for [PoW’s goal of preventing network centralization] was a combination of cryptographic math, philosophy, psychology and resource costs inherent with hardware

It is a combination of cryptographic math and thermodynamic competition.

KLM: [ProgPoW] is designed to target a critical part of the centralization problem: specialized hardware.

Red herring. The definition of specialized hardware doesn’t hold under any kind of critical analysis. It’s meant to distract from the fact that GPU mining machines are as specialized as ASIC mining machines.

The GPU chips that are used for Ethash mining today are built into highly specialized hardware, from special firmware to specially tuned memory to special cards to special machines. None of it is resellable or reusable outside of mining.

Rationally thinking about hardware means thinking about cost, hashrate and power consumption.
Then there is also order lead time and reliability, but they seem to be of lesser importance in the Ethereum PoW context.

KLM: Specialization comes from removing unnecessary parts of hardware

Contradicts her own F1 racing car example later on. If you keep removing from a 4WD, will you eventually have an F1 car?
Specialization comes from designing a machine with only one goal in mind.

KLM: When people talk about ASIC resistance, what they really mean is “centralization resistance”. That’s an important distinction to make, because the problem isn’t the hardware itself — it’s the companies and incentives behind it.

Yes. What are the incentives of Core Scientific?

KLM: network security is relative to the amount of energy spent

Network security is relative to the amount of energy spent efficiently.

KLM: Making specialized hardware means you’ve gamed the mining metric in a way that encourages everyone to buy more

Buy more until a maximum is reached. That is called competition, and why PoW is not only cryptographically, but also thermodynamically provable.

KLM: [analogy of a car race between a 4WD and an F1 racing car]

The F1 analogy fails to think through the alternative: If everyone is forced to stay with the 4WD (GPU), the attack vector (the F1 car) is still possible technically. The security (inability to be outcompeted) was reduced.
PoW is thermodynamically provable, or it’s not PoW.

KLM: The energy-to-work ratio is the same. The network isn’t anymore secure.

Who is the judge to check that none of the 4WD got any secret tuning?
The network is more secure if the competition is open between the 4WD and the F1, because an attack vector (the F1 car) was eliminated. And maybe the higher reliability of the 4WD means it’s more competitive to the F1 car than anyone would have thought.

KLM: Bitmain is a corporation, and that means it has a duty: to maximize returns for investors. They’re chasing their incentives, and that incentive is to make money.

s/Bitmain/Core Scientific/

KLM: Creating incentives for the security mechanism to dominate the network growth is just, well, letting the tail wag the dog.

Right, that’s why ProgPoW should be rejected. PoW is a service to the network, not the other way round. ProgPoW is the tail wagging the Ethereum dog.

KLM: This means the first manufacturer of custom hardware naturally has full control of the hashrate

This is already proven wrong by how long it took to bring the Bitmain E3 (and then Inno A10) to market and the lack of competitiveness with GPUs. I did a lot of math around this earlier in this thread.
Even if the ETH coin price would jump to 5,000 USD today, the network would still be secured by the same installed base of over 5 mio GPUs and it would take at least a year or more for ASICs to gain significant hashrate share. Before then even more GPUs would have rushed into the market bringing the difficulty up and slowing down the income of ASICs.
None of this touches any of the software devs’ ability to change anything - protocol, PoW algo, mining rewards within a much shorter timeframe, if they want to.

KLM: By impeding the network (see the empty-block example above), these miners and hardware manufacturers become the attackers by extracting value to the detriment of the network. Worse, their attack on the coin is constant and pervasive — a cancerous element that extends even to blogs and forums outside of the blockchain, where they spread misinformation and fearmonger to hide their motives and damage they do.

Freudian slip.
To be more blunt: That’s the most vivid executive summary anyone could imagine about ProgPoW.

KLM: Specialized ASIC makers and the miners who buy specialized hardware have guided the evolution of Bitcoin into a version of the traditional banking system, where they now hold all the keys.

Double false. First, the author is (today) CTO of a specialized machine mining company, and yet it’s not enough to dominate and profit, so they are trying community infiltration and PoW change instead.

KLM: As GPUs drop off due to loss of profitability, centralization will accrue around specialized hardware creators. Once this happens they can use attacks…

Circular reasoning at its best. How did the GPUs end up where they are today? Why is the “specialized hardware” somewhere else? Who are “they”?
This makes no sense at all. Specialized hardware is a misnomer, Kristy has expressed many times how fond she is of her drive towards specialization, how open minded about ASICs, etc.

KLM: Specialized Defenses: Some would suggest algorithm stacking — found in coins such as RavenCoin, where the algorithms are repeatedly chained in randomized orders. However, Baikal has proven with their hardware (specifically the BK-X) that a bit of silicon area for each algorithm is all that is needed (and a sequencer, to distribute the order)

For RavenCoin, it’s just “a bit of silicon for each algorithm and a sequencer to distribute the order”.
But for ProgPoW, it’s guaranteed to be proof-of-GPU. Really?

KLM: every algorithm that exists today has an optimal ‘design’ in hardware that can’t effectively be surpassed

Obviously false. Is this worth discussing?
You are either designing an algorithm for a chip, or a chip for an algorithm. If you don’t change the algorithm, the latter will always beat the prior thermodynamically.
We wrote a nice 5-step article how we would find a good (the best we can think of) design of a chip for a given algorithm.

KLM: That’s the key to decentralized mining — leverage existing markets which are bigger and already decentralized. When your hardware isn’t specialized, the hardware starts, and stays, distributed.

Doesn’t explain why Nvidia would leave money on the table. Throughout their 25yr history of gaining a 70% market share in GPUs they have demonstrated a ruthless attitude to making money.
Given its history we must assume, and ProgPoW proves, that Nvidia will try to keep mining centralized with them, gamify Ethereum and turn devs into unpaid support staff.

KLM: to adapt the math in infinite and unpredictable patterns

It can’t be that unpredictable, because it has to be verifiable.

KLM: Once you understand how economic incentives help or harm cryptocurrency networks, it’s easy to see how best to keep things truly decentralized

Right. Cost advantage leads to centralization.

More important, the core devs reached consensus back in January to move ahead with progPow absent technical problems being found. An audit is just one way to go looking for those.

3 Likes

That sentiment is largely the same. I think the audit needs to happen, but the lack of transparency around the process is making people nervous. I think everyone in this thread would agree that knowing the status of the audit would be helpful.

2 Likes

How does this make them better able to analyze the incentives at play? They might know some factors that affect incentives that aren’t obvious to people outside of the industry, but after they reveal these factors to Phil and others they’re back on an even playing field in terms of their ability to analyze the incentives.

That is not at all what I’m saying.

GPU coins are more expensive for an external actor to attack to the extent that a higher percentage of the required mining capacity can be rented (even if not enough rental supply is available to get to 51% – any difference in rental supply affects cost to attack).

The thing about GPUs is that it’s not only crypto miners that use GPUs. The fact that you can rent GPUs from AWS and other generic cloud providers reduces the cost of an attack vs. if you couldn’t rent any hash-power. This is true even if all the GPU capacity for rent still isn’t enough to come close to 51% attacking ETH on its own – it still makes the attack cheaper if you can rent some of what you need.

I don’t think so. I certify you as free from having a significant CoI, assuming you disclosed all the relevant info.

I think what makes for piss-poor discussions is people acting defensively whenever a CoI is mentioned, and acting like it’s some sort of assault on their character. CoIs are properties of the situation regardless of how uncorrupted any individuals in question are, and they are very relevant.

I don’t think it’s appropriate for you to use your own insignificant CoI to suggest that it doesn’t matter much that a lot of people in this debate have real and significant CoIs. It’s not a big deal for you, but that doesn’t mean that it’s not a big deal when it comes to others who are pushing for this.

No – everyone has an interest, but people only have a conflict of interest to the extent that their own interest is in conflict with the interest of others.

I have an interest in ETH being valuable, in ETH being widely used for decentralized apps, and in ETH being hard to attack. This isn’t much of a conflict of interest because the broader ETH community generally has the same interests as me with respect to those things.

In contract, the interest of miners do conflict to a higher degree with the interests of the broader community, especially as it relates to ProgPow.

Who is sticking their fingers in their ears? CoIs should be acknowledged and factored into the analysis of the situation. What I see is miners and ProgPow advocates freaking out whenever someone brings up the CoI issue and refusing to acknowledge as legitimate and worth taking into account.

I’ve also been extremely disappointed in how to CoI issue has been handled by the ETH community, but in my case it’s because some people interpret any mention as CoIs as a personal attack and act like any mention of CoIs is out of bounds. I see this as a tactic to dismiss the legitimate relevance of CoIs.

I agree – but what we’ve seen is the core devs not taking CoIs into account at all. I may have missed things because I took a break from ProgPow for a while. If I missed it, where has the extent of the CoIs related to this issue been publicly discussed / acknowledged by the core devs?

GPU hashpower being more available to rent is unproven. AWS, GCS, Azure and alike would not, could not allow an entirety to rent their hardware to commit crimes.

Every attack seen in the last two years with the exception of ETC is thought(known?) to have come from Nicehash. Nicehash is made up of GPU and ASIC. The parties making this hash available is ignorant to the attacks they are enabling.

ETC devs said that they believe the attack on their network came from some kind of specialized hardware and not from a renal service.

I have been told by people that are in the business of creating specialized hardware and software for large farms and VC’s that private software/firmware, ASIC’s, FPGA/Bitstreams and even GPU’s exist.

@epic.henry, nothing I can post specifics about but watch @OhGodAGirl talk at last years Devcon. Yes the SQRL Acorn was a disaster and only one model was going to help older cards on ethash with some extra compute, they and others have better products now and coming.

1 Like

I agree. I wish there was a revisit of the discussion incorporating all of the lessons we have learned in the past year, and working through some of the facts that conflict with what Phil wrote. Phil is a busy guy though.

Nicehash rents both GPUs and ASICs. It’s all about the incentives. Miners of Ethereum have less incentive to rent their hashpower than lower cap coins.

Someone did a calculation and I think renting the entirety of AWS, Azure, and other’s GPU rigs would only give you something like 10-20% of the hashrate. It would also probably set off some alarm bells with these providers because you’d be DoS’ing their other customers. Not to say it isn’t possible, but it’s not as simple as you make it seem.

Because that’s what it leads to! Kristy and a host of other supporters can’t say a lick about ProgPoW without being painted with that scarlet letter. Perhaps you feel I’m being overdramatic, and maybe I am, but I think it’s much more productive to come up with logical reasoning why someone’s facts or opinions are wrong rather than discounting what they have to say because “they have a conflict of interest”. It’s really just a fancy way of saying “What they’re saying sounds okay, but I don’t trust them so I’m skeptical”. I won’t say more about this, but having a CoI is not a substitute for engaging in reasonable discussion.

@elliot_olds

They [Kristy] might know some factors that affect incentives that aren’t obvious to people outside of the industry

You talked about governance. People always speak the truth? Lies don’t exist?
Imagine a discussion between an engineer and a salesman, but the salesman pretends to be an engineer.

The fact that you can rent GPUs from AWS and other generic cloud providers reduces the cost of an attack

Such non-mining GPUs are not built into specialized mining machines and stand no chance to compete with specialized GPU mining machines.

I think what makes for piss-poor discussions is people acting defensively whenever a CoI is mentioned, and acting like it’s some sort of assault on their character.

We live in the Trump era. If someone counter-attacks to a reasonable question, you have to draw your own conclusions from that.

the interest of miners do conflict to a higher degree with the interests of the broader community, especially as it relates to ProgPow

ProgPoW is not in the interest of non-Core Scientific GPU miners.

@fubuloubu

Kristy and a host of other supporters can’t say a lick about ProgPoW without being painted with that scarlet letter.
… it’s much more productive to come up with logical reasoning why someone’s facts or opinions are wrong
… not a substitute for engaging in reasonable discussion.

Well we did a lot of work on that front, but I doubt many read it.
You cannot prove someone wrong who is intentionally lying from the beginning. Can you prove a politician wrong? They are structuring their entire sentences, from first to last word, to be un-disprovable.
You can logically reason about what you hear, and have a reasonable discussion, but eventually you will come to the conclusion that the other side is just lying. Not seeing this possibility is naive, not thinking it applies to Kristy-Leigh Minehan is fair. Everyone will eventually have a few people who believe them.

Let’s do a little more homework, I love this. Yesterday I pointed out some things in the “Problem with PoW” article.
One key argument in the article are the many references to “specialized hardware”.

Here’s what Kristy said about specialized hardware a few weeks ago (June 24, 2019, quotes from the video):
https://coingeek.com/coingeek-toronto-conference-2019-kristy-leigh-minehan-on-bsv-mining-video/

[7:33] Mining + Specialization = $$$

KLM: This is something I uphold very dear to myself.
KLM: Specialized infrastructure has been at war with the home miner.
KLM: So one of the things we do at Core Scientific is we invest heavily in infrastructure, and specifically we invest heavily in specialization.
KLM: The other piece is optimization. So one of the things we also specialize in at Core Scientific is specifically reverse engineering firmware, figuring out how can we get more optimization out of it.

She actually says that she is at war with the home miner! :rofl:
If you ask her, maybe she will tell you it’s all different for GPUs (this talk is about BSV). Of course it’s the same for GPUs!
She will never stop, and it kind of makes sense. Why stop?
You want to avoid that Ethereum will be controlled by nChain and Calvin Ayre/Craig Wright.

Can someone explain me how any responsible audit for GPU based ProgPoW is even possible if any driver update may change the GPU microcode?

AFAIK, tuning the performance/quality ratio for GPU is not so strongly deterministic as required for mining. Dropped points is just a minor quality problem for rendering, but a show stopper bug for mining.

Sorry if I am completely wrong here.

Hi Ethernian,
that’s not completely accurate.
Actually any driver update may tamper with compiled code for any algo whereas there is an GPU implementation. It may happen for ethash too. This is something beyond the design of any algo and, in general, beyond the design of any piece of software when, to function, it relies on third parties components. Being very extreme : if a bug in a Linux kernel had to happen and this had impact on mining programs would you call it an algo flaw ?

ProgPoW rules require a recompile of a portion of the code where operations are randomized (in type and order) from a well defined set which has been distilled from well known available math intrinsics for both major vendors (AMD and NVIDIA). This code is actually recompiled every 50 blocks (10+ minutes). Carrying out tests on ganganam network a former developer of ethminer I was working with discovered what was named “the bogus period” issue affecting only AMD/OpenCL compilers. On such periods GPU kernels produced results which eventually failed double-check by CPU implementation.
For those cases must be underlined that :

  1. GPU binary code was compiled without issues
  2. GPUs “thougth” their solutions were correct so from their perspective the program was ok.
  3. The problem was observed only when “compiler optimizations” were in place. Compiler optimizations are something beyond the design of an algo
  4. The work-around was a simple directive “limiting” compiler optimization.

After work-around has been applied eventually gangnam network (before being withdrawn) sealed 1M blocks without further issues about the validity of solutions found.

Another issue may arise from frequent compilation where on some drivers version for both major vendors you may stumble in the driver itself getting stuck due to memory exhausted. In that case though you won’t have any “bogus” result rather no hashing at all. I consider this latter nothing dramatic as it’s quite common to restart (reboot) GPU miners after some time. However is something workable simply adjusting how CPU code implements mining (eg. periodically un-load and reload driver’s libraries).

4 Likes

Would like to also note that besides the two different vendors of GPU chips, there are multiple versions of software at play here, and mining operations (preferring to have 0 downtime) would test new configurations of software for issues. It has also been suggested we operate a “canary” testnet (which is basically what Ropsten is or could be) to ensure that the community knows beforehand of bumps in the road before they happen. Lastly, mining software just inherently is composed of many different versions and configurations network-wide, so the likelihood of a catastrophic bug stalling mining is fairly low.

On this point I may have doubts. What has been proposed is to have a test-net which offsets main-net by, say, a month or two in advance. This however does not take into account a few problems:

  1. Keeping the advance offset constant may be tricky when testnet is used, say, to trigger or defuse diff bombs; Unless it’s a dedicated testnet … in such case I’d be concerned about the resources needed to mine it and who should pay for those.
  2. It only takes into account number of blocks as a function of periods to recompile. But let’s never forget PP algorithm, like ethash, also a function of mutable data (see header hash). They wouldn’t be the same on the two chains.

Better say there “could” be. At this very moment, to my knowledge, only production ready miner is a fork of ethminer built for BCI with a very old release of progpow. For ProgPoW 0.9.2 there are only the mockup project by ifdefelse (which is not a fully fledged miner) and a branch from miscellanousbits.
Other major miner devs (Claymore, Phoenix) have declared they might implement it but nothing at sight yet.

1 Like

It really should be. I mean, we always have ran a consensus-identical test network in parallel to the mainnet. It definitely seems less work on it, but it’s never 0. The idea is that we try to replicate the mainnet as close as possible.

Yes, there “would” be because these software developers won’t do anything unless they’re incentivized to do so e.g. if ProgPoW is to be implemented they would implement it. I was more making the point that miners don’t all upgrade at the same time, and they upgrade conservatively because downtime is lost profit, so the risk of catastrophic behavior is low because of the heterogeneous nature of software configuration in PoW networks.

1 Like

The problems the offset would address are not the specific values you mine at a block number, which no testnet could replicate. The offset would cause the programatic instructions to match what would be seen a month or three out on mainnet and would have been able to detect the “bogus period” issue you saw two months before that program was due on the mainnet. Hence miners would be incentivized to participate on the testnet because they can set up alerting on one canary miner to get telemetry on what to expect when that program arrives on mainnet.

Miners may be incentivized to participate in development and testing (once again called to sustain expenses) only if they see a clear roadmap. The fog around the audit (for which noone knows a thing) and all the FUD around coi and anger caused by AMD maximalists vs NVIDIA have done their dirty job. I would not expect much support from miners.

I reiterate at cost of getting annoying: ProgPoW is not a favor to GPU miners. It’s a change for ethereum. If its not perceived this way then all this debates are worthless.
GPU miners have programmable devices … they will turn elsewhere when their revenues won’t cover their expenses or when they must reckon a particular chain keeps treating them as 2nd class citizens.

We’ve been working on gangnam test net for months (with great support from miners either occasional or professionals). Net result was a clear and loud “we don’t give a s…” and a total mess of eth governance which is yet unable to say yes or no hiding (now and then) behind a ghost audit.

1 Like