I don't really see how a chip that can calculate SHA-256 hashes would be able to have a flaw like this. AIUI, the ASIC doesn't know about difficulty, it just hashes difficulty 1 shares. ASICs don't actually assemble the block, the pool does that work. The mining software just grabs whatever hashes it finds that are above the share difficulty from the ASIC and submits them to the pool..
Someone with a better understanding of this might be able to correct me but AFAIK, it would have to either work or not work.
In the case of the April-May block withholding, the error, as I was told, was due to the software not the hardware. The software was checking the difficulty of results the hardware returned, and was having an error when the representation of the difficulty was > uint32 for the share, causing it to be discarded even though it was still a valid result.
At the *hardware* level, I'm doubtful this is possible without being explicitly designed to do so. ASICs are very dumb, as you pointed out. They should only care about diff >= 1, and report the result back to the software for further checking and submission.
So you are giving the best reason yet for a major pool to run a solo fork for miners. A large 2000th mining op burns massive power to do 2000th ,
but if software can never make a block happen as you say your were told that was the case in april + may.
BTW I mined 1th at that pool from APRIL 20th until today so I had bad luck for 40 plus days. Your pools could be sued by miners that were affected. I could argue in a courtroom your pool failed to safeguard it's hash rate from 'bad software'.
If you had offered miners the easy option to use a solo-fork our problem would be of our own choice to not use your solo fork. Without that offer every major pool could have this happen:
Someone trashes the luck with shit software for a month or two causing 80 percent luck vs 96-102 percent luck.
The cat is out of the bag that 'bad' software 'bad' chip 'bad' pcb board 'bad' gear and does not matter what the reason it only matters that a false hashrate can be done to a pool…
This is true. So all pool operators need to protect miners and themselves from false hashrate happening. (FACT not BS)
A solo fork option is one method of protection .
So once again I ask for the bigger pools to offer it.
This issue is not going to leave BTC.
I am giving a method of protection that would work against a high hash rate rig that never makes a block.
Okay how about the big guy cex.io he decides to give any large pool shit luck shoots 300th of shit gear at the pool for a month and the pool has terrible luck. why not cex.io could do this to bit minter in a heartbeat…… make 50 miners up with 1 to 10 th each .
they never hit a block we abandon bitminter and go to cex.io ..
Fact of the matter this is doable ,but if bitminter had a solo fork sending a stack of shit miners against that does nothing. Zip only person hurt is the guy sending the bad gear.
Tell me I am not correct if I am not. Fact is I am correct.
