What exactly is a mining program "asking" of pushpool/bitcoind?

[TeraPool]

When I enter ./bitcoind getwork (on testnet), I get this:

Code:

{
    "midstate" : "4a69151b7f5c43b23454a948a82f35b9ab98f5410a576d7af9665b8fcf6e7494",
    "data" : "000000013c29c465f47458e7a635cf9fc2ab2f40b228ec6f099ecfa100220d6c000000008c7bd504d767f50a70505561905f4c673dda265e1802508afdd29f3f674bac654e1f8dbd1c00824f00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
    "hash1" : "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
    "target" : "000000000000000000000000000000000000000000000000004f820000000000"
}

What is that? (Yes, I have read this page!)

I mean... is that exactly what you would get from pushpool as well? Is that all a miner needs to solve a block? Miners take that data, add their timestamp, increment the nonce, hash and repeat? Only asking to "getwork" again once their nonce has overflowed or the target has been met? Is that correct?

So what pushpool does is getwork from bitcoind every second or so and then distributes that work to miners who ask for it and also have the correct mysql credentials?

I am thinking of writing a version of pushpool in node.js which is why I am asking.

Bonus Questions:

What format is "target" in? And what exactly is "hash1"?

[NetTecture]

it is exactly the same. hashing takes a lot of work - many hashes are tried.

A good proxy swill not ask every second, it will ask on demand plus some to keep a small queue ready to be distributed

[drawoc]

From https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list:

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/Difficulty

I 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.

[TeraPool]

From https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list:

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/Difficulty

I 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

[JoelKatz]

Inside the coinbase transaction, the one that pays the generation and transaction fees, is a field called the 'coinbase' (in the block format) or 'ExtraNonce' (in the bitcoin code). This field can contain anything at all as far as the network is concerned, it doesn't matter.

When bitcoind or a pool controller issues work units to miners, each one contains a different value for this field. The issuer must keep track of every work unit issued and the exact set of transactions in it (including the generating transaction and its coinbase). If a miner solves a block, bitcoin combines the solved nonce with the saved set of transactions to publish the block.

Since each work unit generated has a different coinbase, it will also have a different merkle hash for the transactions, resulting in each miner working on different data. The miner tries all 2^32 nonces trying to generate a share.