Bitcoin Forum

Hi,

as I understand it, the miner goes through up to 2^32 values of the nonce field (which the fourth word in the message), calculates sha(sha(message)), and submits the proof-of-work to the pool if the last word in the hashing result equals to 0. Good.

Now the questions.
1 What other fields can we change in the message when mining, other than the nonce?
2 Where is the extraNonce located?
3 Where is the time (and can we change it as we see fit while mining, or are we required to keep it in a certain range)?

I've been reading through the protocol specs on wiki, but couldn't really figure it out.... Thanks!

-B

The timestamp, the coinbase transaction, the list of transacations included in the block.
My recollection is that the 'extraNonce' is the coinbase. See here where its put into the input of the coinbase transaction:

    pblock->vtx[0].vin[0].scriptSig = CScript() << pblock->nBits << CBigNum(nExtraNonce);
    pblock->hashMerkleRoot = pblock->BuildMerkleTree();

The time is in the header, but it must be kept in a sensible range.

Good answers. I was just gonna say work with 6 other dwarfs and capitalize on woman work.

Thanks, Joel!

So, my understanding is that if we change any of these
1 then we have to rehash all previous parts of the message (i.e. the block), thus changing the first three words in the share on which a miner is working, and
2 this is what a pool does when all valid values of the nonce have been tried.

Correct? Is there anything other than w[3] (that all kernels are currently changing) that we can change on the client side without having to change w[0] through w[2]?

(Joel - I'll send you a whole 1 BTC when you answer this, even if the answer is a no :) thank you very much!)

That's correct. Changing the timestamp or coinbase gives you a whole universe of new nonces to try.

Most pools, to my knowledge, use the bitcoind client's logic to generate work units. With the fix from Luke Dash Jr., the logic looks like this:

void IncrementExtraNonce(CBlock* pblock, CBlockIndex* pindexPrev, unsigned int& nExtraNonce, int64& nPrevTime)
{ // Fix from Luke Dash Jr
    static uint256 hashPrevBlock;
    if (hashPrevBlock != pblock->hashPrevBlock)
    {
        nExtraNonce = 0;
        hashPrevBlock = pblock->hashPrevBlock;
    }
    ++nExtraNonce;   
    pblock->vtx[0].vin[0].scriptSig = CScript() << pblock->nBits << CBigNum(nExtraNonce);
    pblock->hashMerkleRoot = pblock->BuildMerkleTree();
}

So the extra nonce (coinbase) goes to zero with each new block found on the network. Then increments in each work unit given to a client.

I'm not 100% sure I understand what you're asking. Are you trying to be able to have miners generate their own new work units without having to go back to the pool? If so, it's a bit tricky because if they succeed in mining a block, you have to be able to assemble the correct block or you can't get paid.

If you're trying to have something other than the bitcoind program generate the work units (maybe you're trying to minimize the interactions between the pool manager and bitcoind) you're better off with the patches to speed it up. But in that case, you're best off replicating this same logic of increment the coinbase for each work unit, IMO.

You can't ever run out of things to try because by the time you ran through every combination of nonce and coinbase, the time would have changed. If you really want to, you can also change the payout address(es) in the coinbase transaction or drop/add a transaction.

Thanks. I appreciate it. If I misunderstood your question, let me know.

This was the best answer I've ever read on any of the forums.

1 BTC sent.

Thank you!