Bitcoin Forum

Hi,

Got couple of problems with understanding calculation of hashes:

1. Block hash is generated using version, difficulty, prev. block hash, merkle root, time and nonce - but can anyone explain me:
    a) what happens if someone finds block in same time as other computer?
    b) what nonce is used when all numbers in 32 bit int are used? it over-counts all the time if i mine for example 10gh/s? Is here any special additional nonce for that?

2. I am googling/searching whole forum for information about Shares in pooled mining - how are they calculated? I mean - whats different in calculation for miner that he doesn't calculate same work as other miner? And how is Share confirmed as valid by the pooled mining server?


I appreciate any help, thanks in advance!

1
a) the merkle root includes all transactions including the coinbase.  So two miners (or two mining pools) will essentially never have the same merkle root.  Thus you will never have a situation where same input data results in two miners (or pools) solving block at the same time.  Miners/pools can't solve blocks at roughly the same time.  The miner/pool who propegates the solution to rest of network first is the accepted block. 

b) once nonce range is exausted you simply recalculate the block header.  Any of the other variables changing will result in new hashes for nonce -range

2
share = difficult 1 hash
block solution = current difficulty hash

when you mine in a pool you submit all hashes which are valid for difficulty 1 target.  They are worthless but pool uses them for record keeping to split the reward which only comes from a block solution.  Note: most pools uses difficulty 1 but share difficulty can be anything < block solution difficulty.

1. a) 2 miners will not have SAME block(main transaction is different for every public account), but can find a block in same time - what happens then? what if it's same time (lets say same milisecond so lags in network can't count in, word isn't spread yet) in seconds and both spread the word to like 50% computers? computer A gets new block from miner A and computer B gets block from miner B - what will happen when computer A says to computer B "hey i got new block for you"?

b) block header is calculated from almost same data except (SOMETIMES) changing transactions (which changes merkle root), timestamp and ofc nonce(i dont count it in as it's over-counting so it is like static after couple of seconds, and on fast machines even less than a second, so timestamp have no chance to change calculated hashes from previous nonce-pack). I found this on wiki: "Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root." - isnt hash for transaction calculated once? or they given the main transaction (mining one) a special additional nonce? - found that da*n coinbase main parameters and now i know :)

2. so i calculate hashes for 1 diff, and i send proper hash for pool and he just checks it? That looks reasonable and good, but here again(from work side) - how is work distributed to  don't get same work as other miner? As i assume we are mining for same 'account' (key), so even main transaction is same for calculation - that will get nonce over-counted in like miliseconds with big pool. Even giving different extraNonces for every miner will give small amount of work to every worker. How workers get different work?

What is coinbase ?

Protocol specification mentions it a bit, but it's a bit vague:

https://en.bitcoin.it/wiki/Protocol_specification

In what ways is it special, does it have a special format ? hmm..

"coinbase" almost sounds like a special field or something... ?!? but so far seems to be the name/term for a special transaction ?

Let's say the last block is #157596, and all miners are trying to find block #157597. Two miners find a block at the same time, one with hash a651a9... and one with hash f6498d... . Each broadcasts it to everyone it knows, until 50% of the network knows of block a651a9... and 50% knows of block f6498d... . If computer A offers to deliver block a651a9... to computer B which already has f6498d..., it will basically say "No thanks, I already have a block for position #157597". (Maybe it will download it and store it, but not recognize it as correct.) The network will be in a disagreement about what the last block is (this is known as a chain fork), and each miner builds block #157598 based on what he recognizes as block #157597. When block #157598 is found, let's say its hash is b66848..., computer B will eventually be informed of it, and since this is a longer chain than what he knows, he will take a651a9... and b66848..., and recognize them as valid blocks instead of f6498d... (this is a chain reorganization).

Every different block header gives the miner 4 billion new hashes to try. Changing the extranonce changes the Merkle root and thus the block header. When a miner finishes his work he gets a new header with a different extranonce.

It's the transaction that gives the miner the 50 BTC (or whatever it is) block reward (or alternatively, the input of that transaction).

Only a coinbase transaction can have a coinbase input, and coinbase input is the only kind of input that does not correspond to an earlier output.

Then the network is split.  It happens occasionally.  Once a computer has a valid "newest block" it ignores others blocks submitted.  Both parts of the network will work on different chains.  Once one part of the network finds the NEXT block it will have the undisputed longest chain and the other chain will be orphaned.

So for example:
current block is #123
mining pool A solves next block = #124 (we will call it #124A to keep it simple)
mining pool B solves next block = #124 (we will call this one #124B)

Each mining pool broadcasts their block to the network.  So at this point in time some of the network has #124A and some has #124B as the latest block.

The network is split but don't worry both parts of the network are working on block #125.  Which ever part solves the #125 block for THEIR chain becomes the dominant chain.  So say a miner which has #124A solves the next block #125.  When he broadcasts it to the network all clients will accept it.  Even those w/ #124B because #124A, #125 is longer than their chain.

The bad news is the pool which mined #124B will get notification that their block is stale/invalid.   :(  No reward coins for them.

Bitcoin has  10 minute block and very fast block propogation time.  For mining pools to be competitive they need a large number of links to the network (to become aware of block changes & to push out their blocks fast) so chain splits are rather rare.



That is the job of the pool.  Miners sent GETWORK requests the pool makes sure they all have different "extra nonce" values in the coinbase to ensure they are working on unique solutions.  As far as the pool "just checking it". Yup.  Remember verifying one hash is very easy.  It takes a millionth of a second or less for a modern CPU. So every share you submit the pool takes the same raw data computes the hash, compares it to your "answer" and makes sure it is smaller than a  difficulty 1 share. 

If it is and the share isn't stale (no longer valid because a block change has occured) the pool increments your share count by one.  For every 1 GH in hashing power the pool will need to receive and verify ~15 shares per minute.  So Deepbit w/ 3000GH verifies about 42,000 shares a minute.

Both Meni R. and Death A.T. are 100% correct in their description of network splits.

There is additional wrinke when block_number mod 2016 == 2015. This situation is called "retarget". In those situations the blocks differ not only by the "previous hash" field but also by the "difficulty" field.

The global network will still converge to a dominant, longest chain; just that the convergence could potentially take much longer. But the difference in difficulty creates interesting problems both from the control-theory point of view as well as from the game-theoretical point of view.

For example the dominant mining pools were DDoS-ed just before a retarget, probably in the hope of creating a longer-lasting network split and mutual mistrust between the pools.

Everything seems clear in technical way now, though i am just a bit confused about this whole coinbase thing - are here any examples how it is exactly generated? I know there comes goldenNonce or extraNonce, however blocks generated have quite different coinbase(in length and the way they are built) on blockexplorer. Looks like there is one static part showing up in most of the blocks:

Block 158480: "0468860e1a020277522cfabe6d6d8b49cd63aebdb9536d0f880e41271e1a9c58269162b950e0c4e5f3b48081d1 1f0100000000000000"
Block 158479: "07456c69676975730284362c4d4d3d3d17bf49f82f631b1ecc798ccd3ac96c38d577c77ce72b035 f118d17de626c647b0100000000000000074f505f4556414c"
Block 157478: "0468860e1a015c" -> here 15c looks like a extraNonce
(next 5 blocks contain this 'almost static' too)

but still why one is like 10-20 hex long while others are extra long? what are other parts making it so long?

Thank you for all responses! They explained almost all :)

Because it is just used for entropy and as such you can put anything you want in it.  Different pools have different methods to load coinbase transaction to ensure unique work distribution to each miner.  One pool even puts "messages" in there.   If for a given set of data (time, prior block hash, set on transaction, and all nonces) you find no solution for the block (and you won't 999,999 times out of a million) then you need to "try again".  Obviously hashing same data will result in the same no-solution so you need to change the data.  Bitcoin's solution for changing the block header arbitrarily and thus the block header hash randomly is the coinbase field.

 Now with merged mining the coinbase will also contain the hash of the dependent blockchains last block.

The coinbase must be between 2 and 100 bytes long and must be valid when deserialized as a "CScript" (https://en.bitcoin.it/wiki/Script), but may contain arbitrary data.

Block 158479 looks like it is doing merged mining.
The '07456c6967697573' at the start is the string 'Eligius'.
The stuff in the middle looks like hashes for other block chains.
And the '074f505f4556414c' at the endis is the string 'OP_EVAL'.