Fascinating what Michael Deletes [BTCguild 90% luck and dropping]

[os2sam]

well then the game is over for public pool mining with no innovation here..  if there was already a solution there wouldn't be a problem

There is a very good solution but it will require a hard fork.

It seems to me that the solution you recommended earlier in this thread would allow a pool to withhold vital information about the hash's that a miner submits.  The miner wouldn't know if he really found a block or not or even know what difficulty of the share was.  So a miner would have no way to verify if a pool was above board or not or even know how much he was getting paid for his hash's.

The miner would know enough to know how many shares they submitted.  They would not know enough to know if they solved a block though.

Sooo... if you don't know if you've solved a block then you wouldn't know what the difficulty of the share you submitted is so you wouldn't know if you were getting paid correctly.

If you could tell what your share diff is without the pool telling you then you would know if its a block solver or not

[1714922320]

1714922320

[1714922320]

1714922320

[1714922320]

1714922320

[1714922320]

1714922320

[1714922320]

1714922320

[1714922320]

1714922320

[os2sam]

well then the game is over for public pool mining with no innovation here..  if there was already a solution there wouldn't be a problem

There is a very good solution but it will require a hard fork.

It seems to me that the solution you recommended earlier in this thread would allow a pool to withhold vital information about the hash's that a miner submits.  The miner wouldn't know if he really found a block or not or even know what difficulty of the share was.  So a miner would have no way to verify if a pool was above board or not or even know how much he was getting paid for his hash's.

That is not correct.  The miner would know the exact difficulty of the share just not if the share solves a block or not.

Checking a share difficulty IS checking if it meets or exceeds current difficulty.  I don't see how you could separate one from the other.  It would have to be same operation.

[DeathAndTaxes]

The other question of course:  Would that proposed solution even work with existing ASICs, since you're changing the block header fields that are going to be hashed?

Probably or it could be revised to fit.  The actual ASICs really have no concept of what they are hashing just that they are hashing a blob of data and checking the output of the hashed blob.  So the size of the blob (and the fact that the trailing 32 bits are the incrementing nonce) can't change but the header can be extended in 256 bit increments by making the midstate the result of two blocks (hashing definition not bitcoin definition) of inputs instead of one.

As far as will people support a hard fork?  I don't know but if convinced it is a legit threat non-miners may see little downside in supporting it and potential devaluation of their bitcoins if they don't.   If nothing else I find it interesting because "if" this ends up being the Bitcoin killer, well there is already a solution for the altcoin that replaces bitcoin.

[DeathAndTaxes]

well then the game is over for public pool mining with no innovation here..  if there was already a solution there wouldn't be a problem

There is a very good solution but it will require a hard fork.

It seems to me that the solution you recommended earlier in this thread would allow a pool to withhold vital information about the hash's that a miner submits.  The miner wouldn't know if he really found a block or not or even know what difficulty of the share was.  So a miner would have no way to verify if a pool was above board or not or even know how much he was getting paid for his hash's.

That is not correct.  The miner would know the exact difficulty of the share just not if the share solves a block or not.

Checking a share difficulty IS checking if it meets or exceeds current difficulty.  I don't see how you could separate one from the other.  It would have to be same operation.

How about reading the linked proposal that meni spent a lot of time developing and writing up?  Without a hard fork you are right there is no way to separate it, that is why a hard fork would be needed to support a method that prevents a miner from knowing if the hash solves a block.  It would change the blockheader such that a valid block is based on two different hash values and the miner only knows one.   The miner can compute the share difficulty, the pool can compute if it meets the difficulty for solving a block.  The pool withholds the second value from the miner which prevents the miner from knowing what the pool knows.

[os2sam]

How about reading the linked proposal that meni spent a lot of time developing and writing up?

I was kind of trying to avoid that.

  Without a hard fork you are right there is no way to separate it, that is why a hard fork would be needed to support a method that prevents a miner from knowing if the hash solves a block.  It would change the blockheader such that a valid block is based on two different hash values and the miner only knows one.   The miner can compute the share difficulty, the pool can compute if it meets the difficulty for solving a block.  The pool withholds the second value from the miner which prevents the miner from knowing what the pool knows.

But I read the section you recommended, dyslexically, and with your above explanation I think I comprehend it now.

How would that impact solo mining?  I guess the bitcoind/qt would have to be reworked as well anyway.

Enough of my uninformed rambling.
Thanks,
Sam

[DeathAndTaxes]

Well yes a hard fork would imply that all nodes would need to update not just for mining but for validating the new block version as well.   Solo miners wouldn't be affected.  There would still be two values in the new block header but they would know both.  No need to hide info from yourself.

[cloverme]

Mining doesn't lend itself to solo mining unless you have mega hashpower, but the larger a pool is the more risk you expose yourself and the bitcoin network to. P2pool is the obvious next step, but if that gets large enough then it's not much different to solo mining at lower diff. Clusters of smaller p2pools that feed into larger p2pool like set ups are the next obvious step.

However the number of miners is diminishing, and the amount of hashpower with each mining group (like KnC's farms) gets larger by the minute, and they'll probably all just run their own solo operations with time. Pooled mining as we currently know it may end up just being an interesting blip on the history of bitcoin mining.

100% in agreement... Mining will collapse at the feet of the large farms unless the community pulls together as a large diversified pool or pools withing a large pool. Until then, we'll see large pools like BTCguild collapse.

[2112]

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.

[Entropy-uc]

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.

[DeathAndTaxes]

It isn't a hardware fault or error.

If nonce 728937289 solves the block for a given unit of work and a particular hardware for a variety of reasons doesn't check nonce 728937289 it is not going to find a solution.  It is that simple.  I assume you are confused because you believe that hardware normally checks all nonces all the time.  Nothing could be further from the truth.  There are dozens of reasons why a nonce wouldn't be checked and no software is going to report that as an error.  HW errors as reported by cgminer and the like are the result of the hardware reporting that work A + nonce B produces a hash of particular difficulty and it doesn't.

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.

It isn't a static range.  Say you have an ASIC with 64 cores the designer may decide to take the nonce range (2^32) and break it into 64 chunks.  It does this by assinging an offset to each core.  So all the cores get the same work, each one starts at a difference nonce value and they all increment 2^26.  However due to yields not all chips will have all 64 cores operating.  The seller may have designed it around 60 cores being "good enough" to achieve the hashrate.   So if 4 cores are "off" then that means millions of nonces will never even be attempted.  Most ASICs also work on dynamic load so as the hardware error rate and/or temp rise it shuts off the cores.   So the same nonces won't be covered all the time.

Still it goes way beyond just which nonces are checked.  Both the ASICs and the mining software queue work.  So what happens when a miner has 30 seconds worth of work queued up and you send him the "test work".  Are you going to hold the block for 30 seconds which would mean a >7% orphan rate?  What happens if due to latency the miner returns the proper solution but only after you have broadcast the block?  If he cheating or just slow or just had a lot queued up, or poor connectivity?   How are you going to avoid the attacker just sharing info between workers to detect the "test work" and always return those with 100% success?  

Also don't take this is as exhaustive I just don't feel like covering every possible scenario.  The only way to prevent these types of attacks is for the pool to know something the miner doesn't.  The current block hashing protocol doesn't make that possible.

[DeathAndTaxes]

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.

It has nothing to do with hardware errors (although they are another minor source of false positives). 

Simple version:
If nonce 728937289 solves the block for a given unit of work and a particular hardware for a variety of reasons doesn't check nonce 728937289 it is not going to find a solution.

If a user doesn't return a solution is it because he is cheating or is it because his hardware didn't check that nonce with that work?  The answer is there is absolutely no way to know.

[2112]

I assume you are confused because you believe that hardware normally checks all nonces all the time.

Dude! I have to assume that you've again went into the mode where you can't read with comprehension and started arguing with the voices in your head. I normally agree with over 90% what you say, except when you start ranting like when you've claimed that Apple Computer doesn't take money orders. Please chill out or maybe switch to decaf?

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.

Anyway, I think that the problem is solvable. Maybe a Bloom filter of "hashing blind spots". It certainly would require a cooperation from the ASIC vendors with the developers of the miner and the pool software. As most of the things in Bitcoin mining it will be some sort of probabilistic solution, not a mathematical proof of failure.

The first person posting on this forum about false negatives in mining was hardcore-fs with his XUPV5 FPGA miner, but I don't think that he published his results nor code.

Likewise Spondoolies made promises of their ASIC designer to start posting on the forum after Passover, but apparently they haven't had time to do this yet.

In general, I'm optimistic that problem will be solved. Nowadays, who remembers when the long-polls were the major problems for mining pools? From my experience in the electronic and software industry: one person's problem is other person's opportunity. For example: NTSC started as "Never Twice the Same Color" and ended up where even the cheapest TV set receiver chipsets have been precisely calibrating themselves 29.97 times per second (using Vertical Interval Reference and Ghost Canceling Reference). And that was done quite effectively over all-analog broadcast retransmission networks including satellite links, where the end-users were completely oblivious to the problems in the transmission channel. All it took was to build a reasonable model of the distortion and run the tests frequently enough.

Quoting below just for future reference:

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.

It has nothing to do with hardware errors (although they are another minor source of false positives). 

Simple version:
If nonce 728937289 solves the block for a given unit of work and a particular hardware for a variety of reasons doesn't check nonce 728937289 it is not going to find a solution.

If a user doesn't return a solution is it because he is cheating or is it because his hardware didn't check that nonce with that work?  The answer is there is absolutely no way to know.

It isn't a hardware fault or error.

If nonce 728937289 solves the block for a given unit of work and a particular hardware for a variety of reasons doesn't check nonce 728937289 it is not going to find a solution.  It is that simple.  I assume you are confused because you believe that hardware normally checks all nonces all the time.  Nothing could be further from the truth.  There are dozens of reasons why a nonce wouldn't be checked and no software is going to report that as an error.  HW errors as reported by cgminer and the like are the result of the hardware reporting that work A + nonce B produces a hash of particular difficulty and it doesn't.

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.

It isn't a static range.  Say you have an ASIC with 64 cores the designer may decide to take the nonce range (2^32) and break it into 64 chunks.  It does this by assinging an offset to each core.  So all the cores get the same work, each one starts at a difference nonce value and they all increment 2^26.  However due to yields not all chips will have all 64 cores operating.  The seller may have designed it around 60 cores being "good enough" to achieve the hashrate.   So if 4 cores are "off" then that means millions of nonces will never even be attempted.  Most ASICs also work on dynamic load so as the hardware error rate and/or temp rise it shuts off the cores.   So the same nonces won't be covered all the time.

Still it goes way beyond just which nonces are checked.  Both the ASICs and the mining software queue work.  So what happens when a miner has 30 seconds worth of work queued up and you send him the "test work".  Are you going to hold the block for 30 seconds which would mean a >7% orphan rate?  What happens if due to latency the miner returns the proper solution but only after you have broadcast the block?  If he cheating or just slow or just had a lot queued up?   How are you going to avoid the attacker just sharing info between workers?  Say you send the test work to 10% of workers and wait 30 seconds.  You probably will end up with hundreds maybe thousands of false positives AND 7%+ orphan rate (on top of whatever you are losing to attacks).  If the attacker had say 30 accounts there is a less than 3% chance that 1 and only one would be given the test work and end up withholding it.  So 3% of the time you will catch the worker, due to false positives lets say you don't boot someone until they fail 3 times.  That means on average the attacker will pass 99 blocks before failing out.  However you are only testing him 10% of the time so you MIGHT (I doubt it) catch him after he withholds or attempts to withhold 990 blocks.

Of course even your legit users are going to start working against you (or just flee to where they aren't attacked by the pool).  Those who want to stay will probably design a work relay system so they can identify your test works if for no other reason than to be falsely kicked out (especially if you confiscate the work completed).  The attacker could join those relay networks and all but guarantee he would pass all tests.

Also don't take this is exhaustive I just don't feel like covering every possible scenario.  These issues are just the tip of the iceberg.  The only way to prevent these types of attacks is for the pool to know something the miner doesn't.  The current block hashing protocol doesn't make that possible.

[tl121]

A man in the middle attack can accomplish the same effect as bad hardware.  This might be more than a spiteful attack, it could even be profitable if the cost of being a MITM can be made low enough. The attacker would mine solo or on other pools that he is not attacking.  The payoff would come in a lower difficulty.  There are various ways that this attack can be detected if miners are looking for it.

[2112]

OK, D&T again went into the mode where he posts some strawman arguments then deletes them. I'll have to paraphrase:

Mining ASICs are nearly 100% deterministic, more precisely (100% - allowable fault rate). The problem we are facing is that thus far only "false positive" faults were measured by the mining software. Maybe the threat of the block withholding attacks will force everyone to cooperate on the measurement of the "false negative" fault rate.

Hopefully vendors will cease to obfuscate like this:

It won't work. Our miners for example don't check all nonce range, and a lot of cgminer generated jobs get dropped. Also we use ntime-rolling differently from other pools. It's impossible to know what the miner will generate from stratum template.

or like eldentyrell did with the timebomb in his Tricone Mining bitstream for Xilinx Spartans.

[2112]

A man in the middle attack can accomplish the same effect as bad hardware.  This might be more than a spiteful attack, it could even be profitable if the cost of being a MITM can be made low enough. The attacker would mine solo or on other pools that he is not attacking.  The payoff would come in a lower difficulty.  There are various ways that this attack can be detected if miners are looking for it.

Nowadays the cost of the defense against MITM is also extremely low: IPsec. AH is sufficient, more complex ESP is not required. No software changes are required either, only some additional configuration on the routers. I've discussed this already with Slush in the original "Stratum" thread, not the later "Stratum Mining" thread.

[DeathAndTaxes]

Oining ASICs are nearly 100% deterministic, more precisely (100% - allowable fault rate).

On the off chance you aren't trolling, lets imagine the "easiest" possible scenario for detecting a cheater.  

Lets assume all miners use "perfect" hardware.  Once they start a unit of work, they always check all nonce values (0% unchecked nonces), they always increment ntime rolling by one second and one second only (0% unchecked seconds), and they never have any errors have any hardware errors (either reported or not reported). 

Your pool sends test work to 10% of your users and waits 6 seconds (roughly 1% increase in orphan rate) for a response and then broadcast the block.

The miner in question:
a) returns the test work prior to broadcasting the block.
b) returns the test work but after you had broadcast the block.
c) does not return the test work.

In each scenario is the miner cheating or not?

I think you would agree that this scenario is about as simplistic as possible.   Right?  The real world is far more chaotic but this simplistic scenario takes ASIC complexity out of the picture.  The reality is you can not conclusively say if the miner is or is not cheating in any of those three scenarios.

[tl121]

Nowadays the cost of the defense against MITM is also extremely low: IPsec. AH is sufficient, more complex ESP is not required. No software changes are required either, only some additional configuration on the routers. I've discussed this already with Slush in the original "Stratum" thread, not the later "Stratum Mining" thread.

It's more than "additional configuration" if one's router doesn't support IPSEC.  Plus, and this is more to the point, if the pool doesn't support securing the other end this won't even be an option.

Of course this will protect only up to the pool boundary, but I'm not going to go there... 

[2112]

It's more than "additional configuration" if one's router doesn't support IPSEC.  Plus, and this is more to the point, if the pool doesn't support securing the other end this won't even be an option.

Of course this will protect only up to the pool boundary, but I'm not going to go there... 

In my experience these days even the cheapest "ADSL modem & WiFi gateway router" (that are practically given away by ISPs) do support IPsec. And even if they don't support IPsec directly they support passthrough of IPsec tunneled in UDP. It really is a matter of expending some effort to configure the endpoints, be they routers or the hosts. All the well-known OSes support IPsec for about a decade now.

Also in my experience the reluctance to enable IPsec on somebody's behalf typically points to other problems:

1) generally lousy network infrastructure with high BER
2) inside jobs at vendors/clients who then try to blame MITM or bitsquatting or whatever esoteric enough
3) generally incompetent operations/sysop/sysadmin staff
4) some other "layer 8" political/religious problems in the organizations

In my experience cost was never a problem. In addition to the above doing a "show crypto ipsec" (in Cisco IOS or equivalents in other routers) was the surest way to get the problem escalated to the appropriate personnel at the ISP, NOC, DC, etc. in the rare cases that there was an actual problem somewhere in the infrastructure.

[RoadStress]

The reality is you can not conclusively say if the miner is or is not cheating in any of those three scenarios.

So are we back to square one?

[mdude77]

The reality is you can not conclusively say if the miner is or is not cheating in any of those three scenarios.

So are we back to square one?

It seems everyone is assuming there's a withholding attack going on?

M