This is definitely a newbie question. It has probably been answered before, but I can't find it with the searches I've done.
I have come to bitcoin with the slashdot post last week and have tried to educate myself before asking stupid questions. I started bitcoin mining solo and after about a day and a half realized I should join a pool.
I'm using the poclbm client.
As I understand bitcoin mining (in a pool or solo), I am grabbing the hash of the previous block, possibly some transactions, my (or the pool's) address and randomly trying different nonce's to get a hash of all of that smaller than a specified value based on the current difficulty.
But here's where I am confused. My miner (solo or pooled) using my Radeon 5770 card reports around 170 - 175 Mhashes/sec.
The nonce on block 125907 found as I began writing this was 150,035,635 (comma's added for readabilty). If the Mhashes reported by my miner are checking blocks by playing with the nonce, that should have been found in a second.
As I've written this, block 125908 has been found with a nonce of 3,787,138,861. At 170M/s that would have taken just under 22 seconds.
Obviously, I'm missing something. Technically, I do realize that a block hash is the hash of a hash, but still, I do not understand what is being reported as hashes/second when trying to find a block.
Technical discussions over my head are welcome as are pointers to threads where this has already been asked. But, in a nutshell, if the only thing that a miner program is playing with is the nonce, why is the nonce so small compared to the hashes/sec or the time to find a block?
I have come to bitcoin with the slashdot post last week and have tried to educate myself before asking stupid questions. I started bitcoin mining solo and after about a day and a half realized I should join a pool.
I'm using the poclbm client.
As I understand bitcoin mining (in a pool or solo), I am grabbing the hash of the previous block, possibly some transactions, my (or the pool's) address and randomly trying different nonce's to get a hash of all of that smaller than a specified value based on the current difficulty.
But here's where I am confused. My miner (solo or pooled) using my Radeon 5770 card reports around 170 - 175 Mhashes/sec.
The nonce on block 125907 found as I began writing this was 150,035,635 (comma's added for readabilty). If the Mhashes reported by my miner are checking blocks by playing with the nonce, that should have been found in a second.
As I've written this, block 125908 has been found with a nonce of 3,787,138,861. At 170M/s that would have taken just under 22 seconds.
Obviously, I'm missing something. Technically, I do realize that a block hash is the hash of a hash, but still, I do not understand what is being reported as hashes/second when trying to find a block.
Technical discussions over my head are welcome as are pointers to threads where this has already been asked. But, in a nutshell, if the only thing that a miner program is playing with is the nonce, why is the nonce so small compared to the hashes/sec or the time to find a block?
Title: Re: Stupid newbie question about the nonce
Post by: theymos on May 23, 2011, 03:33:53 AM
The nonce is reset from time to time. With pooled mining, you ask the pool for new work when this happens. With solo mining, you modify the coinbase transaction to get a new set of hashes to try.
Title: Re: Stupid newbie question about the nonce
Post by: kjj on May 23, 2011, 03:34:50 AM
There is another one in the Merkle root.
If a miner burns through every possible nonce in the block header without success (which is most of the time), it reports that to the node, which updates the Merkle nonce and hash (it might also reconsider which transactions to include and possibly a new timestamp), and starts over.
If a miner burns through every possible nonce in the block header without success (which is most of the time), it reports that to the node, which updates the Merkle nonce and hash (it might also reconsider which transactions to include and possibly a new timestamp), and starts over.
Title: Re: Stupid newbie question about the nonce
Post by: anewbie on May 23, 2011, 03:43:55 AM
Then what is the upper limit on the nonce? Is there one in the protocol?
On transactions, if I'm solo mining, are those being assigned to my miner, or is it picking them out of the pool of transactions on its own?
On transactions, if I'm solo mining, are those being assigned to my miner, or is it picking them out of the pool of transactions on its own?
Title: Re: Stupid newbie question about the nonce
Post by: theymos on May 23, 2011, 03:47:50 AM
The upper limit is 4294967295, but Bitcoin resets the nonce long before you reach that. The reset is based on time, I believe. Edit: Actually, it looks like the nonce does go right up to the limit before being reset. ExtraNonce is the one that is reset based on time.
Are you talking about transactions in blocks? Solo miners pick them according to their own rules.
On transactions, if I'm solo mining, are those being assigned to my miner, or is it picking them out of the pool of transactions on its own?
Are you talking about transactions in blocks? Solo miners pick them according to their own rules.
Title: Re: Stupid newbie question about the nonce
Post by: anewbie on May 23, 2011, 03:52:30 AM
Thanks to both of you for the quick answers. One final question and I'm done for the night.
Theymos talks about the node resetting the nonce. kjj talks about the node making changes in the merkle root and possibly the timestamp. Are you both talking about the same thing? Merkle root nonces? I thought that a miner was playing with the nonce itself to get a block. Is my inderstanding incorrect.
Thanks again, and I promise I'm done for the night.
I may come back with more newbie questions tomorrow, though.
Theymos talks about the node resetting the nonce. kjj talks about the node making changes in the merkle root and possibly the timestamp. Are you both talking about the same thing? Merkle root nonces? I thought that a miner was playing with the nonce itself to get a block. Is my inderstanding incorrect.
Thanks again, and I promise I'm done for the night.
I may come back with more newbie questions tomorrow, though.
Title: Re: Stupid newbie question about the nonce
Post by: Meni Rosenfeld on May 23, 2011, 04:26:32 AM
Thanks to both of you for the quick answers. One final question and I'm done for the night.
Theymos talks about the node resetting the nonce. kjj talks about the node making changes in the merkle root and possibly the timestamp. Are you both talking about the same thing? Merkle root nonces? I thought that a miner was playing with the nonce itself to get a block. Is my inderstanding incorrect.
Thanks again, and I promise I'm done for the night.
I may come back with more newbie questions tomorrow, though.
The miner plays with the nonce to get a block, up to a point. Since nonce is a 32-bit integer which only allows for 4B values, eventually it will need to ask the server (whether locally or on a pool) for a new merkle root to work on (where things like the extra nonce have been changed).Theymos talks about the node resetting the nonce. kjj talks about the node making changes in the merkle root and possibly the timestamp. Are you both talking about the same thing? Merkle root nonces? I thought that a miner was playing with the nonce itself to get a block. Is my inderstanding incorrect.
Thanks again, and I promise I'm done for the night.
I may come back with more newbie questions tomorrow, though.
Title: Re: Stupid newbie question about the nonce
Post by: theymos on May 23, 2011, 04:33:41 AM
A solo miner increments Nonce until it overflows. Then it increments extraNonce and resets Nonce. extraNonce is located in the coinbase transaction, so changing it alters the Merkle root. extraNonce is reset based on the time.
Title: Re: Stupid newbie question about the nonce
Post by: kjj on May 23, 2011, 04:51:56 AM
I think that a lot of the confusion comes from thinking that there is just the one true next block and everyone is trying to find the one.
That isn't how it works. There are many blocks that could be the next one. The difficult part is finding one out of the much huger number of blocks that aren't difficult enough.
Each node builds up a list of pending transactions, and they pick some or all of them to go into the new block. Once they have their list of accepted transaction, they calculate the hash of a Merkle tree for that list. One of these transactions is unique to that node too, because it is the generation transaction, and everyone gets to pick their own account for the reward. So, even if everyone had the same rules for picking and ordering transactions, they would all be starting from different places anyway.
For many potential blocks, there is no value of the nonce that will give a hash less than the target. When that happens, the node must alter something in the block header and try again. The timestamp is a good candidate, since it usually takes some time to try all 2^32 nonces. New transactions may have come in across the network that can be added to the tree too.
I could have sworn there was also a nonce in the Merkle tree calculations, but I can't find any references to it now. Ahh, theymos found it while I was typing. It is in the generation transaction, which changes the Merkle hash.
In a pool, the pool server will hand out unique headers to each worker/request, by using the extraNonce and rehashing the tree, to prevent duplication of work and get better odds of finding a valid block.
That isn't how it works. There are many blocks that could be the next one. The difficult part is finding one out of the much huger number of blocks that aren't difficult enough.
Each node builds up a list of pending transactions, and they pick some or all of them to go into the new block. Once they have their list of accepted transaction, they calculate the hash of a Merkle tree for that list. One of these transactions is unique to that node too, because it is the generation transaction, and everyone gets to pick their own account for the reward. So, even if everyone had the same rules for picking and ordering transactions, they would all be starting from different places anyway.
For many potential blocks, there is no value of the nonce that will give a hash less than the target. When that happens, the node must alter something in the block header and try again. The timestamp is a good candidate, since it usually takes some time to try all 2^32 nonces. New transactions may have come in across the network that can be added to the tree too.
I could have sworn there was also a nonce in the Merkle tree calculations, but I can't find any references to it now. Ahh, theymos found it while I was typing. It is in the generation transaction, which changes the Merkle hash.
In a pool, the pool server will hand out unique headers to each worker/request, by using the extraNonce and rehashing the tree, to prevent duplication of work and get better odds of finding a valid block.
Title: Re: Stupid newbie question about the nonce
Post by: thedrs on May 23, 2011, 09:26:38 PM
Thanks KJJ that was very helpful for understanding how it works.
Many of the newbie tutorials explain the system in a more simple manner which makes you assume there is 1 true next block that everyone is working on.
Now, after reading you post it is clear why everyone is actually working on a different one.
Now I have to go find some info on what a Merkle tree is .... :P
Many of the newbie tutorials explain the system in a more simple manner which makes you assume there is 1 true next block that everyone is working on.
Now, after reading you post it is clear why everyone is actually working on a different one.
Now I have to go find some info on what a Merkle tree is .... :P
No comments :
Post a Comment