pool diff

[FabioCarpi]

There is a question that still can not understand
say that the difficulty of the network is 2
as if two shares of diff 1 comes at the right value?

exemple

diff 1: 00000000 ffff0000 00000000 00000000 00000000 00000000 00000000 00000000
diff 2: 00000000 6fffff00 00000000 00000000 00000000 00000000 00000000 00000000

share 1: 00000000 1a3099ec 4bfd6d85 75ab5a6b 23e937db 51b51b29 c3683a61 948cd06e
share 2: 00000000 145c8f44 84d89086 6193b602 727b081a 62c290ed 2747d9e2 56db9d2d

[hexafraction]

No, two diff-1 shares do not constitute a diff-2 share. Reaching the diff target is all-or-nothing. Mining pools remove the all-or-nothing effect by making the miner solve a bunch of smaller diffs in larger quantities.

[FabioCarpi]

ok, but how solve small diff solves the biggest diff?

[hexafraction]

ok, but how solve small diff solves the biggest diff?

Solving small diffs doesn't solve the big diff. By solving small diffs (aka shares), the miners are proving to the mining pool that they are participating in mining, and how much power they are contributing to mining. Then, when a nonce is found that solves the big network diff, the pool receives the 50 BTC, and distributes it to the miners based on the proof-of-work they submitted (their small diffs).

[FabioCarpi]

ok
but how the server found the nonce with that shares?

[DannyHamilton]

Shares are not used by a server to find a nonce.  You have that backwards.

Miners use a nonce to find shares.  They then supply those shares to prove that they are hashing.

Eventually a miner will stumble across a nonce that results in a hash that is not only lower than the share difficulty, but also lower than the network difficulty.  When he does, he supplies that nonce to the server.  The server verifies that the nonce is correct, and then broadcasts the completed block to the network.

The server keeps track of all the shares so that it knows how much hashing each miner has been doing, that way it can distribute the bitcoins fairly.

[FabioCarpi]

Eventually a miner will stumble across a nonce that results in a hash that is not only lower than the share difficulty, but also lower than the network difficulty.

got it

[hhanh00]

Eventually a miner will stumble across a nonce that results in a hash that is not only lower than the share difficulty, but also lower than the network difficulty.

got it

I wonder what prevents a miner from noticing that and claiming the full reward for himself as if he was solo mining. In other words, claim shares through the pool but if you find a block, submit it directly.

Edit: I guess it's difficult to find the list of transactions that the pool used to calculate the merkle root.

[achow101_alt]

Eventually a miner will stumble across a nonce that results in a hash that is not only lower than the share difficulty, but also lower than the network difficulty.

got it

I wonder what prevents a miner from noticing that and claiming the full reward for himself as if he was solo mining. In other words, claim shares through the pool but if you find a block, submit it directly.

I don't think that that is possible because the merkle root for that miner would be different than the one from the pool because the coinbase transaction would be different. Otherwise, the Miner would be broadcasting the block, but the reward would still go to the pool.

[hhanh00]

Yeah, you're right.

[FabioCarpi]

another question
what are the calculations that the pool sends to the miners?
because they are many shares ...
what changes?
I can not explain my doubts...

[DannyHamilton]

another question
what are the calculations that the pool sends to the miners?
because they are many shares ...
what changes?
I can not explain my doubts...

The "hash" that is used in bitcoin's proof-of-work is actually 2 full computations of SHA256 on the block header.  The nonce is at the bottom of that header.

Therefore, the pool can get half way through the first computation of SHA256 on the block header on it's own (this is called a "midstate").

The pool then provides the midstate to the miner.

The miner completes the SHA256 calculation on the rest of the header for each nonce that it tries, and then completes the second SHA256 hash on each of those results.  If any of those final hashes are lower than the share difficulty, then the miner has completed a share and sends it to the pool to prove that he is computing the necessary hashes.  If none of the final hashes are low enough, and the miner runs out of nonces to try (there are 4294967296 possible nonces to try for each midstate) then the miner requests a new midstate from the pool.

The pool computes MANY midstates for the block (changing the extranonce, or timestamp, or merkle root so that each midstate is different).  Therefore the pool can give a different set of midstates to each miner.

[FabioCarpi]

The pool computes MANY midstates for the block (changing the extranonce, or timestamp, or merkle root so that each midstate is different).  Therefore the pool can give a different set of midstates to each miner.

got it
ty

[FabioCarpi]

came a question...
you guys said that the server makes the first header hash (Midstate) and the miner makes the second ...
but how changes in the nonce Midstate?

[DannyHamilton]

came a question...
you guys said that the server makes the first header hash (Midstate) and the miner makes the second ...
but how changes in the nonce Midstate?

Check again.  I did not say that the midstate was the complete first hash...

- snip -
half way through the first computation of SHA256 on the block header on it's own (this is called a "midstate").
- snip -

Pool only makes the first half of the first hash.  The nonce is in the second half of the block.

Miner adjusts the nonce and finishes the second half of the first hash as well as computing the second hash.