|
|
|
|
|
|
|
TalkImg was created especially for hosting images on bitcointalk.org: try it next time you want to post an image
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
gmaxwell
Moderator
Legendary
 Offline
Activity: 4158
Merit: 8382
|
 |
July 08, 2014, 04:56:58 PM |
|
There is absolute no random number generation in mining. There is no performance sensitive random number generation anywhere in the bitcoin system. |
|
|
|
|
jonald_fyookball
Legendary
Offline
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
|
|
July 08, 2014, 05:06:07 PM |
|
How do the miners choose which nonce to start with when trying to solve a block?
Surely they don't all start with "1" ?
|
|
|
|
|
Anders (OP)
|
|
July 08, 2014, 05:15:39 PM |
|
There is absolute no random number generation in mining. There is no performance sensitive random number generation anywhere in the bitcoin system. But isn't there usually a brute force approach to finding a hash with enough leading zeros? And that would require guessing randomly since the search space is so astronomically huge. Or are there algorithms for finding such leading zeros without using any random or pseudorandom generator? |
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3388
Merit: 4615
|
|
July 08, 2014, 05:15:51 PM |
|
How do the miners choose which nonce to start with when trying to solve a block?
Surely they don't all start with "1" ?
Why not? |
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1075
Ian Knowles - CIYAM Lead Developer
|
|
July 08, 2014, 05:17:14 PM |
|
My guess is that mining pools probably allocate a different starting *nonce* to each miner (but I haven't looked into it).
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8382
|
|
July 08, 2014, 05:18:23 PM |
|
My guess is that mining pools probably allocate a different starting *nonce* to each miner (but I haven't looked into it).
They all start at zero (or any other number) it doesn't matter as they're all working on work which is merkle root distinct. |
|
|
|
|
jonald_fyookball
Legendary
Offline
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
|
|
July 08, 2014, 05:19:27 PM |
|
How do the miners choose which nonce to start with when trying to solve a block?
Surely they don't all start with "1" ?
Why not? Because if your set of transactions chosen for the block is the same as another miner, you will lose assuming they are bigger than you. Oh I get what you're saying.... can be the same transactions but different sequencing gives it different merkle root? but then how do they choose the sequence? |
|
|
|
|
infested999
|
|
July 08, 2014, 05:19:37 PM |
|
There is absolute no random number generation in mining. There is no performance sensitive random number generation anywhere in the bitcoin system. Move your mouse around the screen. |
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1075
Ian Knowles - CIYAM Lead Developer
|
|
July 08, 2014, 05:19:58 PM |
|
They all start at zero (or any other number) it doesn't matter as they're all working on work which is merkle root distinct.
Wouldn't they be *repeating the same work* if they started with the same nonce? |
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8382
|
|
July 08, 2014, 05:20:30 PM |
|
They all start at zero (or any other number) it doesn't matter as they're all working on work which is merkle root distinct.
Wouldn't they be *repeating the same work* if they started with the same nonce? Absolutely not. They are working on block headers which have a different merkel root, always. Existing mining protocols do not even have a facility to set the nonce position/range. |
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3388
Merit: 4615
|
|
July 08, 2014, 05:20:45 PM |
|
But isn't there usually a brute force approach to finding a hash with enough leading zeros?
Yes. And that would require guessing randomly since the search space is so astronomically huge.
No. Or are there algorithms for finding such leading zeros without using any random or pseudorandom generator?
Yes. - Start with a nonce of 0.
- Compute sha256(sha256(header))
- Is the hash value lower than the target?
- If so, hurray, you're done.
- If not, is the nonce equal to the maximum nonce?
- If not, increment the nonce, and return to the "Compute sha256(sha256(header))" step.
- If so, modify some other part of the block (for example extranonce, or the transaction list), and return to the "Start with a nonce of 0." step
|
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1075
Ian Knowles - CIYAM Lead Developer
|
|
July 08, 2014, 05:22:29 PM |
|
Absolutely not. They are working on block headers which have a different merkel root, always. Existing mining protocols do not even have a facility to set the nonce position/range.
I guess I still don't understand the details of this part - is that due to them using different txs? Perhaps you could explain that a little clearer for someone like me that doesn't quite understand it. |
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8382
|
|
July 08, 2014, 05:25:47 PM |
|
I guess I still don't understand the details of this part - is that due to them using different txs?
Perhaps you could explain that a little clearer for someone like me that doesn't quite understand it.
Well one transaction in particular is always distinct: the coinbase. Every miner will be paying their winnings to a different address. In the case of pooling, pools usually put a worker-distinguisher in the coinbase field of coinbase transaction to keep the work of the hashers they are paying distinct. |
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1075
Ian Knowles - CIYAM Lead Developer
|
|
July 08, 2014, 05:27:53 PM |
|
Well one transaction in particular is always distinct: the coinbase. Every miner will be paying their winnings to a different address. In the case of pooling, pools usually put a worker-distinguisher in the coinbase field of coinbase transaction to keep the work of the hashers they are paying distinct.
Of course - silly that I didn't see that - thanks for the clarification (now it makes sense why starting at 0 for the nonce is what you'd do - although I guess if you were running multiple threads as a hasher then you might have them each start with a different nonce). |
|
|
|
jonald_fyookball
Legendary
Offline
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
|
|
July 08, 2014, 05:31:15 PM |
|
I guess I still don't understand the details of this part - is that due to them using different txs?
Perhaps you could explain that a little clearer for someone like me that doesn't quite understand it.
Well one transaction in particular is always distinct: the coinbase. Every miner will be paying their winnings to a different address. In the case of pooling, pools usually put a worker-distinguisher in the coinbase field of coinbase transaction to keep the work of the hashers they are paying distinct. Ahh..makes sense. And I suppose there's no reason to believe a higher starting number than 0 would be any more effective. |
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3388
Merit: 4615
|
|
July 08, 2014, 05:32:42 PM |
|
There are a variety of areas where data differs between different pools and/or different hashers even when they are using the same nonce. Some of them are: - block timestamp
- transaction inclusion
- transaction order
As gmaxwell has pointed out, even when all of these are the same, the coinbase transaction is modified to make the merkle root unique. Think about how fast the fastest ASIC machines are, and it becomes obvious that they are running through all 4,294,967,296 (about 4 gigahash) nonce possibilities in less than a second. Clearly the nonce isn't the main source of variation in block solving. |
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3388
Merit: 4615
|
|
July 08, 2014, 05:34:10 PM |
|
And I suppose there's no reason to believe
a higher starting number than 0 would be
any more effective.
Nope. As a matter of fact, by skipping the lower numbers you could very well be missing a potential solution entirely (unless you rolled back around to 0 after you reached max nonce). |
|
|
|
|
|
Anders (OP)
|
|
July 08, 2014, 05:34:41 PM |
|
But isn't there usually a brute force approach to finding a hash with enough leading zeros?
Yes. And that would require guessing randomly since the search space is so astronomically huge.
No. Or are there algorithms for finding such leading zeros without using any random or pseudorandom generator?
Yes. - Start with a nonce of 0.
- Compute sha256(sha256(header))
- Is the hash value lower than the target?
- If so, hurray, you're done.
- If not, is the nonce equal to the maximum nonce?
- If not, increment the nonce, and return to the "Compute sha256(sha256(header))" step.
- If so, modify some other part of the block (for example extranonce, or the transaction list), and return to the "Start with a nonce of 0." step
Ok, but couldn't the use of a random generator produce a correct nonce faster than the above approach? Of course, the random generator would have to be very fast to be useful. |
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3388
Merit: 4615
|
|
July 08, 2014, 05:37:22 PM |
|
Ok, but couldn't the use of a random generator produce a correct nonce faster than the above approach? Of course, the random generator would have to be very fast to be useful.
Why would it be any faster to search through nonce values in a different order? If the correct nonce for a solution is 1 and you search in the order: 5,8,3,9,2,4,0,3,8,2,7,4,3,9,7,0,6,1 Why would that find the solution any faster than if you searched in the order: 0,1,2,3,4,5,6,7,8,9  |
|
|
|
|
|
