Can someone explain to me how is "block withholding attack" different from the "false negative" type of hardware fault? I mean in the observable symptoms, not in the intent.
The last time I looked into the miners source codes (late FPGA era,early bitfuries) I've only seen the "false positives" counted as "hardware errors": nonce comes up as gold, but software re-check shows that it isn't.
I haven't seen any published source code that does the opposite check for "false negatives": chip should find a golden nonce but hadn't.
From the skimming of the available hardware documentation I see that only Spondoolies has a BIST operation that allows to cheaply test for false negative. By "cheaply" I mean "cheaper than doing a regular, full scan".
Obviously this test has to be hardware specific, because e.g. bitfuries only test 768/1024 of the available nonce space. This would have to be even more complex to account for failed sub-engines in the multi-engine chips.
I think that Stratum Mining protocol can be extended to allow the client to send to the pool server the maps of the "blind spots" in the nonce space. Then the pool can sensibly proctor the tests meant to discover withholding attacks.
You are correct that there isn't any observable difference between the 2 types of problems. And in practice, I think it's extremely unlikely that someone with hardware that has catastrophic levels of false negative errors is unaware of the issue, so the intent is likely equivalent as well. When you have people of very questionable competence designing silicon on crash schedules it's inevitable that serious hardware defects are going to be in play. And with the money involved, if there is a way to externalize the cost of failure to pool participants people are going to choose that over eating the loss themselves. I think it's an absolute must that stratum allow pools to send test jobs to validate hardware integrity in a blind way that allows detection of malicious withholding as well. Without that, I expect the days of public pools are numbered, and with them all hope of even modest decentralization will go as well. |
|
|
|
so you guys think this is a good deal?
I think Cointerra's position is that warranties are not transferable. So you either need a warranty from the seller, or high confidence that the machines will operate without problems for the 6 months you'll need to break even. It's a decent price given the current market, but I'm not really excited about buying mining gear right now so I wouldn't take it myself. |
|
|
|
they will be in a warehouse with free electricity and the temp is always around 45 F
Not after you plug those beasts in. |
|
|
|
|
How much do you pay for electricity? (remember to include taxes!)
Where are you going to keep them? Do you have 10 KW of plugs available or will you need to pay an electrician? How is the noise going to affect you?
How will you cool them? 8kW will overload the A/C system of a normal house.
If you can answer all those questions and you want to invest the total amount needed (including electrician and new A/C) in Bitcoin, then go ahead.
|
|
|
|
I don't think the user owes anyone anything or is liable if it was an honest mistake. The only way they would be liable financially is if they knowingly stole from or sabotaged the pool, which is unlikely considering the fact that they were also hurt financially.
This must have been a very large farm in order to hurt BtcGuild by 10 to 15%, so it's very unlikely that they would also want to reduce their own earnings by that amount on purpose.
eleuthria, is there any reliable way to flag and deal with this type of issue sooner in the future? I assume it must be fairly obvious for very large farms.
The probability this was an honest mistake is zero. You have a group with more than a petahash that suddenly decided to pool mine and they solve no blocks for a month. A petahash is not brought online overnight. There were certainly mining solo before this, and discovered problems with solo mining. There is absolutely no reason for such a large operation to pay pool fees. Further, Michael since you are listening now, you should realize that cockroaches never appear alone. Dig deeper and you will find more problems. We pulled out of your pool over a month ago because the bad luck was statistically unbelievable then. This is not the only cheater in play. |
|
|
|
There are still a lot of countries where electricity is super cheap: china, egypt, philippines...
Centralisation has started to kick in, but this will take at least another 3 years to complete I think.
New more efficient miners are being released and there are also people that don't mine for the money, just for fun.
Whatever gave you the impression that electricity is cheap in China? The average rate in Shanghai is $0.22 / KWh |
|
|
|
First and even second generation asics had no diff support within the chips whatsoever so they just produced a hash and it was up to the software to decide what to do with the result so it cannot be the hardware in the case of avalon 1/2, bfl etc. 3rd generation hardware almost all has diff support on chip or in firmware and that's the only place that the hardware itself could be responsible.
Not necessarily. If there is a bug in the hashing engine itself it could be possible. Think about the shift operations in SHA-256. You could have an incorrect implementation that produced good hashes in the last 32 bits (all that is tested in 1st gen approaches) up until you roll into hashes with zeros all the way up to 64 plus bits. Then think about what chips were famous for generating invalids at outrageous rates. :-) If something like this is going on the actual details of how it happens is likely to be vastly more complicated that what I am saying. But with hardware implementations anything is possible. No sorry you don't understand sha256. It's a 32 bit operation on a fixed length string in mining and has NO concept of difficulty or zeroes. Your failure to understand me doesn't mean I don't understand SHA-256. I've implemented it in both software and hardware and my comments are based upon failure modes I worried about in the hardware implementation. Let's just sit back and see what the next few days reveal. |
|
|
|
First and even second generation asics had no diff support within the chips whatsoever so they just produced a hash and it was up to the software to decide what to do with the result so it cannot be the hardware in the case of avalon 1/2, bfl etc. 3rd generation hardware almost all has diff support on chip or in firmware and that's the only place that the hardware itself could be responsible.
Not necessarily. If there is a bug in the hashing engine itself it could be possible. Think about the shift operations in SHA-256. You could have an incorrect implementation that produced good hashes in the last 32 bits (all that is tested in 1st gen approaches) up until you roll into hashes with zeros all the way up to 64 plus bits. Then think about what chips were famous for generating invalids at outrageous rates. :-) If something like this is going on the actual details of how it happens is likely to be vastly more complicated that what I am saying. But with hardware implementations anything is possible. |
|
|
|
Someone (meni or was it gmaxwell) proposed a solution to this any many other attacks against pools. Going from memory (and likely butchering it) it involved sending blinded work to the miner such that the miner would know if a hash produced a valid share but not if it produced a valid block. The pool using information kept from the miner could check all returned work and confirm which ones produced valid blocks. Thus there would be no withholding attack possible (not even against PPS). It would require a hard fork but I could see it spun as a security measure to prevent disruption of the vital proof of work component. Maybe I can find the paper. Found the paper (annoyingly it doesn't support copying, so I can't quote the relevant section). https://bitcoil.co.il/pool_analysis.pdfSee Section 6.3.2 Oblivious SharesA hard fork is definitely a bridge too far - there would be too many competing options to ever develop consensus on a solution that requires a hard fork. I do think stratum is broken if it isn't possible for a pool to verify that the hardware it is connected to is functional and operating honestly. Given what has been said today, I am thinking a certain first generation design known for having many bugs may be broken by current difficulty. If so, the large users of that hardware had to be aware of the issue and choose to cheat others rather than deal with the problem. They would have seen a degradation in solo-mining performance as the cliff approached since the probability of a share >1B is dramatically larger than the probability of finding a share between 1B and 4.2B. |
|
|
|
Well, if we want to entertain the idea of faulty hardware having some bearing on the overall results, we need to identify recent release's. I follow a number of the Antminer threads and see a significant number of miners struggling to keep the S2's up and running. Also see a significant number of S2 miners posting screen shots with concerns over large numbers of Hardware Errors and Rejects. Some one will do a little math and say...Mheee...that's not too bad. My point though is that is 1TH/s equipment and those rejects and errors accumulated in 2-3hrs exceed my accepts for a given time period. AND knock-off miners with slightly less advertised total hash speed from Bit-Mine seem to have a slightly higher error rate/hour as well. Just seems too me like these units are a bit off, maybe they are putting out some bad vibe static.......
If the problem is related to the difficulty going above the limits of a 32-bit variable, it may not have anything to do with *recent* hardware releases. It could be OLD hardware. It would likely be firmware or software in the controller for the hardware. (See edit for more info). This would explain why these accounts were not noted the last time I did a pass. I was looking for active withholding previously. Accounts with significantly low block submissions vs shares submitted. Last night's pass was specifically targetting shares vs blocks over the last 6 weeks, eliminating the chance of past luck making up for recent shortfalls. EDIT/CLARIFICATION: The hardware itself has no reason to actually know the result of its hashing outside of diff>=1 (or >=1024 in some newer hardware I believe). It's probably not in the software since *most* ASICs do not use custom software, they use cgminer or bfgminer. So the point in the middle that handles communication between the hardware and the software is the most likely culprit. It could also be in the silicon. You could have a fully unrolled hasher with a perverse error that corrupts the last 32 bits of the hash value under circumstances that includes the second 32 bits hashing to 0 (diff >4.2B). The silicon could then find plenty of golden nonces but none (or a significant % lost) over 4.2B. I was quite unhappy about the closed nature of many of the recently released products specifically because I wanted to run a test suite of known solutions against the hardware and was unable to do so. The hardware we have online have solved ~150% more blocks than we have collected reward on, so I do have indirect confidence about the systems we own.Can you elaborate on the test in bold? Are you speaking of your own farm? Yes. Before we pulled everything off BTCguild about a month ago, we had solved blocks worth around 150% of the payments collected. |
|
|
|
Well, if we want to entertain the idea of faulty hardware having some bearing on the overall results, we need to identify recent release's. I follow a number of the Antminer threads and see a significant number of miners struggling to keep the S2's up and running. Also see a significant number of S2 miners posting screen shots with concerns over large numbers of Hardware Errors and Rejects. Some one will do a little math and say...Mheee...that's not too bad. My point though is that is 1TH/s equipment and those rejects and errors accumulated in 2-3hrs exceed my accepts for a given time period. AND knock-off miners with slightly less advertised total hash speed from Bit-Mine seem to have a slightly higher error rate/hour as well. Just seems too me like these units are a bit off, maybe they are putting out some bad vibe static.......
If the problem is related to the difficulty going above the limits of a 32-bit variable, it may not have anything to do with *recent* hardware releases. It could be OLD hardware. It would likely be firmware or software in the controller for the hardware. (See edit for more info). This would explain why these accounts were not noted the last time I did a pass. I was looking for active withholding previously. Accounts with significantly low block submissions vs shares submitted. Last night's pass was specifically targetting shares vs blocks over the last 6 weeks, eliminating the chance of past luck making up for recent shortfalls. EDIT/CLARIFICATION: The hardware itself has no reason to actually know the result of its hashing outside of diff>=1 (or >=1024 in some newer hardware I believe). It's probably not in the software since *most* ASICs do not use custom software, they use cgminer or bfgminer. So the point in the middle that handles communication between the hardware and the software is the most likely culprit. It could also be in the silicon. You could have a fully unrolled hasher with a perverse error that corrupts the last 32 bits of the hash value under circumstances that includes the second 32 bits hashing to 0 (diff >4.2B). The silicon could then find plenty of golden nonces but none (or a significant % lost) over 4.2B. I was quite unhappy about the closed nature of many of the recently released products specifically because I wanted to run a test suite of known solutions against the hardware and was unable to do so. The hardware we have online have solved ~150% more blocks than we have collected reward on, so I do have indirect confidence about the systems we own. |
|
|
|
We have a couple of lottery winners that want to get into mining. Since they are so lucky, should they start their own pool? I heard luck is contagious. Would these lottery winners have the luckiest pool in the planet. They plan to call themselves luckypool.
Most studies show lottery winners blow through all the money within 1-2 years. Buying mining gear now is a great way to accomplish that result. |
|
|
|
Yes, fascinating that I deleted the posts that contributed nothing constructive, and decided to imply that I simply don't care, or am too lazy to do anything, and also include a dollar figure for income that was pulled directly out of your ass as well. What you describe is not dissimilar to what I just said. However: First identify your 'unluckiest' participants. Step one biggest problem already. Your miners need to have had more than 1 diff's change worth of shares to even begin calling them unlucky. So they need to submit 8 billion diff1 equivalent shares. The miners would need to be hundreds of terrahash before you even accumulate any significant data to even make this call, and then if they split their mining into multiple workers, you will never get 8billion shares like I said. This. Additionally, you can't send a "prove you're not evil" work packet to miners in stratum. Every miner has a unique ExtraNonce1, so they will never overlap their hash results. So what have you done to verify the pool isn't being exploited? Doing nothing is pretty much the definition of not caring wouldn't you say? On a more serious note, if you are unable to actively detect miners performing a block withholding attack on the pool, then Con is right, the era of public pools is over. Unscrupulous commercial miners will destroy the public pools to eliminate competition from small players. |
|
|
|
I received a HashFast refund in a timely manner, VMC sent and unsigned Check first of all then asked me to send it back and since then I have heard nothing.
LMAO they sent you an unsigned Check,how does that even happen It's a very old con man trick from the 1970s. Sending a bad check is fraud. Sending an unsigned check buys you a few weeks for an 'honest mistake' |
|
|
|
Yes, fascinating that I deleted the posts that contributed nothing constructive, and decided to imply that I simply don't care, or am too lazy to do anything, and also include a dollar figure for income that was pulled directly out of your ass as well. What you describe is not dissimilar to what I just said. However: First identify your 'unluckiest' participants. Step one biggest problem already. Your miners need to have had more than 1 diff's change worth of shares to even begin calling them unlucky. So they need to submit 8 billion diff1 equivalent shares. The miners would need to be hundreds of terrahash before you even accumulate any significant data to even make this call, and then if they split their mining into multiple workers, you will never get 8billion shares like I said. This. Additionally, you can't send a "prove you're not evil" work packet to miners in stratum. Every miner has a unique ExtraNonce1, so they will never overlap their hash results. So what have you done to verify the pool isn't being exploited? |
|
|
|
What you describe is not dissimilar to what I just said. However: First identify your 'unluckiest' participants. Step one biggest problem already. Your miners need to have had more than 1 diff's change worth of shares to even begin calling them unlucky. So they need to submit 8 billion diff1 equivalent shares. The miners would need to be hundreds of terrahash before you even accumulate any significant data to even make this call, and then if they split their mining into multiple workers, you will never get 8billion shares like I said. This is true. But wouldn't hundreds of users coming from the same IP block raise it's own set of flags? I would expect that existing DDOS defenses would ban somebody trying that approach right away. A pool might have a few IPs like that due to hosting providers but a few phone calls would validate those. |
|
|
|
|
I would think you could detect someone performing a block withholding attack on the pool through a simple test:
First identify your 'unluckiest' participants. Then when a block is solved, immediately send the work unit for the block to those miners. If they consistently fail to return the winning solution you know they are ripping you off.
There are a number of other attacks that could be detected with similar approaches.
What's troubling to me is the massive asymmetry of risks right now. The miners on BTCguild have over $50M in hardware investments that is depreciating at 25% / month . I'd be shocked if Micheal has $50k in total in hardware to run the pool.
My personal theory has been mentioned already:
<Tin foil hat on>
Startup 42e1 spends $2M on design and masks to build out their $5M 2Ph/s mine only to discover that the design has a flaw that prevents it from finding nonces with difficulties over 4.2 billion. It still hashes lots of results below that level, so instead of scrapping things they move all their machines off the internal pool to a big public pool.
<tin foil hat off>
There are many, many other reasons someone could be maliciously attacking a pool, and the stakes keep getting larger. If you're operating a public pool and not actively developing defenses, you will be burned.
And personally if I was clearing $250k / month off my pool, I wouldn't care what little people think either, but I would pay somebody to care.
|
|
|
|
I thought these were pretty neutral points but apparently Michael has something to hide. DPoS, I appreciate that you are genuinely concerned about this, but variance happens.
If you have any evidence beyond the de facto luck of the pool, I'd personally be delighted to see it, but claiming to be the only guy who can see the conspiracy while the math nerds politely nod and smile...
I say this without malice, but it reminds me of the scores of (to a person, bad) poker players I've met over the years who talk about how dealers screw them, how winners are just lucky, how they usually win when they sit in their lucky seat, how they never win with pocket aces, and a gillion other things that all come down to the reality that variance happens.
They don't understand it, and so the game must be rigged.
It's funny you mention poker. I remember a friendly game once where I never seemed to get hands breaking the way you would expect from the odds. So when the deal came around to me, I counted the deck. There were only 46 cards in it! Sometimes bad luck is bad luck. But it never hurts to check. Michael rakes ~$250k per month from this little game. And his participants have been losing out on over $1.5M / month for the last 3+ months. That calls for a LOT more diligence than a little hand waving about variance. Bitcoin is a dirty business, with cheats and thieves always looking for a weakness to exploit. I can think of half a dozen ways Michael could be testing for exploits that would explain the pools recent performance. But he seems more interesting in collecting his rake and insulting anyone who asks reasonable questions. It reminds me of how Deepbit disappeared from the pools list. Tycho was too busy with hookers and blow to respond to his users, and in a year he went from the biggest pool, to non-existence. [/quote] It reminds me of how Deepbit disappeared from the pools list.
It's no wonder [Tycho], and others, have disappeared from these forums. Let's accuse everyone else, with NO evidence, of malfeasance as well so that we have no responsible people left in the community. Great idea. No evidence of malfeasance? Why use a $3 word when a 5 cent one will work? Allowing your pool to leak $1.5M / month and disrespecting people who ask reasonable questions about the possibility that some actors could be cheating other participants in the pool isn't exactly malfeasance - it's simply a lack of diligence. And I've seen no trend of losing responsible people in Bitcoin. Tycho made his fortune and moved on, because he didn't care any more. Michael seems quite happy taking in $250k per month and not addressing this issue. If I were in his shoes I would be madly coding performance tests until I was 100% certain my pool wasn't being abused. That would be the responsible thing to do. [/quote] |
|
|
|
Well eveyrone who is willing to buy a cointerra machine just stop...
No replies no nothing... they promised refunds... and again nothing...
Scamming People.. not even afraid of lawsuits... Something big is behind it..
Do you have any facts to support this, or are you just trying to disrupt Cointerra's business? |
|
|
|
I paid in USD. Have wire transaction records, e-mails from Hashfast confirming receipt and that the order is okay, etc. Can't imagine how they could DQ me. The evidence is irrefutable.
Then again, if their shipping update posts are to be believed, they are on the verge of actually filling the remaining Batch 2 upgrade card orders, which would remove me from this action....
I think you just answered your own question. My guess as to what will happen is that once they have the list of people who are making claims they will prioritize shipment to those people first paying them off with now nearly worthless hardware and also use procedures to delay any court proceeding to the greatest extent possible in order to give them the maximum amount of time to ship and nullify as many individual claims as possible. If they do this after the bankruptcy filing, I believe it would have no impact on receivership. They would still need to demonstrate that the company is solvent to continue operations. |
|
|
|
|
Show Posts
