Mining fraud?

[pesci]

Person A connects a $15,000 mining rig to his computer and starts churning out many terahashes per second, in the form of "shares".
Person B connects nothing to his computer, but instead modifies cgminer to pretend that it is communicating with a $15,000 mining rig and generates the exact same number of terahashes per second, however they are all faked random nonsense. When the pool finally finds a valid PoW, Person B gets a share of the proceeds despite not submitting valid shares.
What is there to prevent person B from doing this?
Or to put it another way, what is the process by which a share is actually verified to have been performed on real hardware, since (AFAIK) a share typically does not include a successful PoW that results in new coins?

[1715569154]

1715569154

[1715569154]

1715569154

[Upgrade00]

Or to put it another way, what is the process by which a share is actually verified to have been performed on real hardware,

Creating a valid block involves solving the cryptographic puzzle which is unique for that particular block following the Bitcoin hashing algorithm - https://en.bitcoin.it/wiki/Block_hashing_algorithm.

It's sort of a puzzle, because there are lots of possibilities which need to be tried out, pretty quickly, before a valid one, unique to that block is discovered. To do this one needs lots of computing power as there is a lot of competition, and simply pretending to have such would not be enough

since (AFAIK) a share typically does not include a successful PoW that results in new coins?

You would need to explain a bit further what you mean by a 'share' and the other parts of the text.

[avikz]

Person A connects a $15,000 mining rig to his computer and starts churning out many terahashes per second, in the form of "shares".
Person B connects nothing to his computer, but instead modifies cgminer to pretend that it is communicating with a $15,000 mining rig and generates the exact same number of terahashes per second, however they are all faked random nonsense. When the pool finally finds a valid PoW, Person B gets a share of the proceeds despite not submitting valid shares.
What is there to prevent person B from doing this?
Or to put it another way, what is the process by which a share is actually verified to have been performed on real hardware, since (AFAIK) a share typically does not include a successful PoW that results in new coins?

Lol! The shares are validated itself during the mining process. In every shares found, there are two options - accepted or rejected. So the algorithm would tag the shares of person B as rejected while the shares of person A will be accepted.

If the process of peraon B could get him some valid shares, then no one would be buying mining rigs. Instead all will use fake mining programs to mine and make money out of it.

If someone has approached you with such proposal, stay out of that!

[ranochigo]

Or to put it another way, what is the process by which a share is actually verified to have been performed on real hardware, since (AFAIK) a share typically does not include a successful PoW that results in new coins?

The pool validates each and every share submitted by the miners. Each of the shares have a certain difficulty and thus a certain weightage pegged to it; an ASIC submitting a share with a larger difficulty (ie. 50) would earn the same amount as one that submits 50 shares with 1 difficulty. The work done for both are proportional and thus the compensation would be proportional to the shares and the difficulty of it being submitted as well. PoW makes it such that it is expensive to find a share of sufficient difficulty but quite trivial for a hardware to actually validate them. It isn't a problem for pools to validate each share that the users submit, by the fact that pools often implemented PPLNS or that of sorts, it discourages miners from intentionally holding shares that meets the actual target as this lowers their remunerations.

Tl;dr: Pools do check for the validity of the shares and the shares represents their contribution to the pool; lesser effort = lesser rewards and zero effort = no rewards.

[NotFuzzyWarm]

@OP This is pretty exactly the same thing you asked about in this thread. The answer is the same as what was posted there: The Network checks your work and your fraudulent block will be rejected.

Do you honestly think that in the nearly 11 year history of Bitcoin no one has tried your simple ways of trying to game the system much less far more advanced ones?

[pesci]

The Network checks your work and your fraudulent block will be rejected.

Let's say my ASIC makes 1 billion attempts at finding a PoW value starting with 62 zeroes, and this is represented by 100 shares, and all of these attempts fail to find the PoW hence I don't win the new Bitcoins. How does the pool differentiate between my ASIC-generated PoW values, which are randomly generated, and an entirely random PoW that was never checked by an ASIC? So far I don't see anyone offering a cogent explanation.

[pesci]

Pools do check for the validity of the shares and the shares represents their contribution to the pool; lesser effort = lesser rewards and zero effort = no rewards.

If a share doesn't include a single PoW that solves the block however, but only attempts to solve the block, what is the precise mechanism for proving the PoW value is not just an unchecked random number? I have an idea, but I'd prefer to hear someone who is in the know explain it. This might be a bit of a "hard question".

[ranochigo]

Let's say my ASIC makes 1 billion attempts at finding a PoW value starting with 62 zeroes, and this is represented by 100 shares, and all of these attempts fail to find the PoW hence I don't win the new Bitcoins. How does the pool differentiate between my ASIC-generated PoW values, which are randomly generated, and an entirely random PoW that was never checked by an ASIC? So far I don't see anyone offering a cogent explanation.

Okay. When you submit a share, you submit the job ID, nonce, timestamp and every data needed to reconstruct your hash. The pool reconstructs your hash and checks if it is a valid share > X difficulty as specified by your client or your pool. PoW is a hash and you don't need an ASIC to generate a hash... Your hash is always rebuilt and validated by the pool, you cannot just submit random values because the pool checks it.

Just to contextualize it; when your ASIC takes 1 billion attempts at finding a block, it'll probably hit one hash that fits the difficulty (ie. 1) as specified by the pool. That is a valid share, even if the current difficulty is 10,000, because your pool specifies a much lower difficulty than the current PoW to validate that you are infact attempting to find a block. By submitting several valid shares, you are proving to the pool that you are contributing to the effort. You will probably understand this better if you can look at how pools actually work, perhaps starting with how the stratum protocol does the communication between the pool and the miner.

If a share doesn't include a single PoW that solves the block however, but only attempts to solve the block, what is the precise mechanism for proving the PoW value is not just an unchecked random number? I have an idea, but I'd prefer to hear someone who is in the know explain it.

A share does include a PoW. If you were to mine in a pool, you'll realize that your client finds and submits shares of X difficulty. The precise mechanism is as follows:

1. Pools sends the data required to construct a block and the difficulty for which it expects before a share is submitted to the client. A share doesn't necessarily have to meet the target, it is just something to determine if a miner is in fact contributing to the pool.
2. With the data given, the user hashes to find a hash that meets the difficulty as specified by the pool.
3. Once they find a hash greater than the specified difficulty by the pool, they send it to the pool, together with the information necessary to reconstruct it. If the pool cannot reconstruct it to form a hash that meets a specific target, then it is invalid. It is futile to send any shares that don't meet the specified difficulty because they won't be considered by the pool.

I think you have a fundamental misunderstanding of Bitcoin, rather than how pool works. PoW is not a random number, PoW in Bitcoin is defined with the hash that is difficult to find, ie. your leading zeros in simplified terms.

[Ali771samir]

I think it's better to post this in the bitcoin mining section, and you should concentrate more so as not to disrupt the forum, but I agree with you.

[pesci]

I think you have a fundamental misunderstanding of Bitcoin, rather than how pool works. PoW is not a random number, PoW in Bitcoin is defined with the hash that is difficult to find, ie. your leading zeros in simplified terms.

No, I understand that. It's a terminology problem. I've been using PoW to refer to the hash whether it is valid or not. I see now that PoW is defined as only the hash that has the number of leading zero bits.

I'm not sure I understand the difference between leading zeroes and difficulty though. People throw around the term difficulty rather loosely as though it is a euphemism. I prefer concrete terms.

[ranochigo]

No, I understand that. It's a terminology problem. I've been using PoW to refer to the hash whether it is valid or not. I see now that PoW is defined as only the hash that has the number of leading zero bits.

Well, yeah. Technically the greatest possible target, or a difficulty of 1 is a hash that is smaller than 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF. PoW is a concept whereby we measure the estimated work done to do something, where in this case would be a hash that meets the specific requirement.

I'm not sure I understand the difference between leading zeroes and difficulty though. People throw around the term difficulty rather loosely as though it is a euphemism. I prefer concrete terms.

Actually, difficulty is just a representation of the target. It is far easier to say a number than to actually say the target. I find it easier to describe target with the number of zeros, because a the maximum target (and lowest difficulty) has 8 zeros and loads of people have no idea what it means when I talk about target. Leading zeros is a dumb down concept that is easier to describe to most people. The more correct method of describing a target is to compare the hash to a 256bit number, and it's validity is determined by comparing the hash and the target, where the hash has to be smaller than the target to be valid.

I didn't really refer to your terminology but your understanding of how a pool function. If you can understand how a pool works, either through looking at stratum documentation or a pool's code, then it shouldn't be difficult to understand what's going on.

[pesci]

I think it's better to post this in the bitcoin mining section, and you should concentrate more so as not to disrupt the forum, but I agree with you.

Only by discussing and debating do people form true understanding. Only by questioning are assumptions checked and sometimes found to be wrong.

[pesci]

The more correct method of describing a target is to compare the hash to a 256bit number, and it's validity is determined by comparing the hash and the target, where the hash has to be smaller than the target to be valid.

From a coding perspective, if I were writing a CPU miner, I could see why the "less than" test is used-- at the machine language level, it's faster to perform four 64-bit subtractions and then check the carry flag to implement one 256-bit subtraction than to try to scan a 256-bit value for the first 1 bit. But subtraction is also misleading it's just an implementation detail and originally the leading zeroes are what mattered.

[NotFuzzyWarm]

Only by discussing and debating do people form true understanding.

When trying to learn, correct. Then again, everything you are questioning has many existing documentations. As background for discussion & better explanations, fine but the documentation eliminates the need for debate. DYOR and read up on what you are trying to question and point out flaws in.

Only by questioning are assumptions checked and sometimes found to be wrong.

Correct - regarding assumptions you may have. The basis of Bitcoin operations however have long ago been debated, tested, and attacked countless times. Early on, yes flaws were found - and quickly corrected. Again, the fundamentals of the mining process no longer have reason for debate regarding how one might possibly break them. These days debate is all about enhancements such as Segwit, Taproot, StratumV2, etc.

That all said, any new coin and especially any new algo MUST be rigorously examined and debated to make sure that its rules cannot be violated.

A pool and more correctly a stratum server, knows what work was sent to a miner to be processed. Results submitted back must match that work. So far no one has found a way to forge results in the manners you suggest.

Perhaps look through Kano's Help files for his pool starting here to help wrap yer brain around what folks have been saying here.

[DannyHamilton]

originally the leading zeroes are what mattered.

A hash is just a 256 bit integer.
The POW target is also a 256 bit integer.

It is NOT the leading zeros that matter. It is the comparison between the hash and the target.

For example, if the share target is:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00001110

Then a block that hashes to this value is a valid share:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00001101

And a block that hashes to this value is NOT a valid share:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00001111

EVEN THOUGH THEY BOTH HAVE THE EXACT SAME NUMBER OF LEADING ZEROS.