You said you are in Europe. John Wong said Grinder Pro has same problem as him and mentioned ITAR. I think this means the FPGA they are using is considered a dual use technolgy and has export controls. This must be why Grinder Pro wants a US citizen as a partner.
That would be as inefficient as using host RAM + GPU. Most FPGA only have 1 or 2 external memory channels. GPU will out compete that easily. In order for FPGA to win you either donât need RAM or you use HBM. 4 and 8 GB HBM FPGA are somewhat attainable, but that wont allow you to grind, only farm compressed plots.
And if you try to combine multiple FPGA via inter-connect, youâre back to external RAM speeds. There simply isnât enough high bandwidth external pins. Not to mention the electrical design challenge of making that work in the first place.
The only known trick to improve grinding are to find plot ids that pass 2 or 3 signage points in a row. But that only gives you a 2 or 3x gain. Weâre talking about a 1000x gain here.
FPGAs are commonly used for rocket guidance and such, no surprise there.
Most likely Virtex⢠UltraScale+⢠HBM series with 4 or 8 GB HBM.
1 Like
Could they be doing some sort of replay attack but not actually taking over? There is no economic incentive to show their hand if this was the case.
Is there a way to share HBM memory? Have you tried using a FPGA for compression?
The NoSSD connection is complete speculation. These accounts are less than 2 days old with no claim or mention of being NoSSD⌠Only one unrelated person saying âI suspectâŚâ and another following up with âI betâŚâ Now there is a thread running on reddit claiming this is NoSSD⌠big game of âtelephoneâ chia edition⌠smh
This doesnât make any sense to me, I canât think of any hardware that can achieve these numbers per watt unless this is a design flaw/vulnerability with the initial plot and PoST design.
Iâm not buying it but whoever GrinderPro and JohnWong is, they both just joined and type like they are the same person.
Too fishy for me. Both are 100% trolls imo.
I just read through the doc you sent and canât grasp how it relates to this. care to explain?
EDIT: since you edited your post, you are describing plot grinding which we all know about, this is what the whole compression thing is about, but how can they achieve these numbers?
So are you telling me it is something CNI knows about?
Care to elaborate? Weâre all poking in the dark here.
Thatâs what grinding is yes, but itâs highly inefficient, due to large (~256 GB) high-bandwidth RAM requirement. A single k32 phase 1 takes around 1000 GB of bandwidth.
If it was 100x more efficient we would all be doing it right now.
As a reference I did phase 1 on 16x A100 in about 1 sec before, maybe now I could do 0.5 sec with optimized kernels. But thatâs almost 10 kW of power draw, just to spoof 450 TiB. In other words 0.045 TiB per Watt, about 4500 times less efficient than what is claimed here.
So again, if the claim was 203 TiB per 1000 Watt, then itâs totally believable, for FPGAs to be 5x more energy efficient. Thereâs a missing factor of 1000.
2 Likes
Gotta love
âŚsomething to keep you awake a night 
2 Likes
All this FPGAs talk is keeping Max away from making 12.8 
3 Likes
This must be really easy for them to prove? Show us a wallet, spec output from the server or something. Just sayinâ it should be really easy.
You have a money hack exploit then why even come here and post? Go ask Gene for a bug bounty. Iâm sure he can cash out another million in presale and pay you guys off.
If we assume NoSSD is also FPGA grinding then worst case only 6 EiB is controlled by these guys and they canât currently get their hands on any more FPGA (probably because China sellling weapons to Russia for Ukraine).
Chia Network is still secure and we have time to fix. Letâs wait until the post-mortem. We were already going to have to replot anyways. This is not the end.
1 Like
The most interesting thing is that Max admitted to having a FPGA to do plot compression. And that he has used A100s to plot grind. Kinda fishy this is all coming out now. You got to wonder what a team with more resources could do.
Iâm guessing you really donât need a FPGA to plot grind efficiently and that was state of the art 2 years ago or whatever. If 200 TiB per watt is true with FPGA then even 20 TiB per watt would be good with GPU
MMX is in late stage testnet (hopefully) right now w/potential to have solved (at least) some of this and done so w/efficiency of HW and running cost. Not being mainnet gives him flexibility CNI canât even dream about.
With Chia on a price death spiral, âhaving to replot anywayâ is not a certainty for farmers, but rather an opportunity to replot with HW at hand⌠and escape this drama.
Doesnât MMX use the same PoST consensus? Without knowing what the exploit is both MMX and the new Chia plot format are likely vulnerable. The grinders can just update the code for the new formats.
This is probably why Max is saying it is impossible on one hand while having working implentation of plot grinding on the other.
Not an expert, but 16X this GPU for grinding doesnât sound cost effective for a coin pegged to ~1$. No idea what an FPGA costs, but still.
Though you never knowâŚ
I agree. There has to be more to the story. Chia employees are not telling us something. If you takes Maxâs calculation of Tib/w with the A100s then there was never any reason for Chia to reduce the plot filter! So why did they do it? Even the H200 can not grind profitably. There was no reason to reduce the plot filter unless there is something they arenât telling us about plot grinding.
I never finished the FPGA code. The 16x A100 setup was used for plotting really fast, at about 100 GBit/s at the time, uncompressed plots. Grinding wont make you any money.
Iâm not aware of any setup that can even remotely break even at plot grinding. Apart from the crazy claims being made here.
No I heavily modified the format for MMX.
I donât, itâs pointless.
Thereâs sill a 2-3x gain to be had by grinding for plot ids that pass multiple signage points in a row. But it still wont make it profitable.
I think they just did it to be safe, and to combat compression in general.
MMX has a plot filter of 16 btw, but the HDD plot format is optimized for sequential access so itâs not a real problem. Itâs extremely inefficient to grind, also due to heavy table 1 compute, 9 tables in total and a much larger table entry size (more RAM bandwidth needed).
Sound like you heavily modified the plot format but are still using PoST consensus? Do you still use a timelord?