If [data] is not specified, returns formatted hash data to work on:
"midstate" : precomputed hash state after hashing the first half of the data
"data" : block data
"hash1" : formatted hash buffer for second hash
"target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful.
Pushpool takes this, and raises the target (lowers the difficulty). This way, you don't have to actually solve a block to get a share.
The target is just a hex number (Little Endian!!) that the block's hash has to be under. More on this here: https://en.bitcoin.it/wiki/DifficultyI think that pushpool modifies the nonce somehow so that different miners aren't doing the same hashes. (Not sure how)
As for the interface between pushpool and bitcoind here's a thread with more details:https://forum.bitcoin.org/index.php?topic=22585.0
I don't have the slightest clue what hash1 is.
Thanks for that explanation.
So yes it seems fairly innocent in it's implementation. Pushpool is acting as a cacheing proxy between bitcoind and the miners.
This line has me perplexed however: I think that pushpool modifies the nonce somehow so that different miners aren't doing the same hashes.
On the block hashing algorithm page it reads...
Given just those fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win. However, it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of your unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network.
But when mining for a pool, the bitcoin payout address is unique only to the pool, so indeed the fastest miner would always "win" in a sense, would it not?
Now I am even more confused