The miner can simply change the order of the transactions or extra nonce to change the witness commitment and the merkle root.
Changing the order of transactions in a block that has a segwit transaction is actually hard, as the miner would have to recompute the witness transaction IDs stored in the Coinbase transaction 
Topic: question on finding nonce (Read 263 times)
That's right, but I heard in a lecture on Bitcoin mining that in case a miner can't guess the needed nonce for too long it includes more transactions in the block(or excludes some of them) to change the Merkle root and to start guessing nonces for the new one. Is that info correct? And if yes then that's what I was asking about.
That's correct. Nonce are pretty limited since they are only essentially numbers that has a max limit of 4 bytes.However, I suspect that it won't be the first data that they would change when the nonce is exhausted. The block header consists of merkle root, hash of last block, target, time stamp, version and nonce. Of them, the merkle root, timestamp and nonce are pretty variable. The miner would likely change the timestamp and the nonce first before trying to change the merkle root. The miners aren't fond of changing the merkle root first as it takes additional computing power.
Changing the merkle root doesn't mean that they will include/exclude any transactions. The miner can simply change the order of the transactions or extra nonce to change the witness commitment and the merkle root.
What if it would be more efficient to make each miner to try to find nonces for different sets of transactions rather than finding nonces for the same set?
The nonce is iterated to find a block hash lower than the target.Before you start trying nonces you must have a candidate block already (complete with transactions)
That's right, but I heard in a lecture on Bitcoin mining that in case a miner can't guess the needed nonce for too long it includes more transactions in the block(or excludes some of them) to change the Merkle root and to start guessing nonces for the new one. Is that info correct? And if yes then that's what I was asking about.
Also the reply by DannyHamilton is pretty much about the same thing:
when miner divide the work to each gpu,
does it divide in a way that they won't overlap?
does it divide in a way that they won't overlap?
In most cases, I would expect that the mining software would simply build completely different blocks for each, rather than trying to split up nonce range.
And one more thing. I think that there are so many variants of possible nonces that being picked randomly they almost never overlap.
when miner divide the work to each gpu,
does it divide in a way that they won't overlap?
does it divide in a way that they won't overlap?
In most cases, I would expect that the mining software would simply build completely different blocks for each, rather than trying to split up nonce range.
What if it would be more efficient to make each miner to try to find nonces for different sets of transactions rather than finding nonces for the same set?
The nonce is iterated to find a block hash lower than the target.Before you start trying nonces you must have a candidate block already (complete with transactions)
This is a very interesting topic to me because I'm doing my best in trying to understand how Bitcoin mining really works.
I've never thought of the possibility of assigning different tasks to different miners and I'm not sure about if that even possible, taking into account that S9, for example, does 14 tera hashes per second, but here's what I think. What if it would be more efficient to make each miner to try to find nonces for different sets of transactions rather than finding nonces for the same set?
I've never thought of the possibility of assigning different tasks to different miners and I'm not sure about if that even possible, taking into account that S9, for example, does 14 tera hashes per second, but here's what I think. What if it would be more efficient to make each miner to try to find nonces for different sets of transactions rather than finding nonces for the same set?
Agree, as the nonce is like randomly located between 0 to unit32_max.
when miner divide the work to each gpu,
does it divide in a way that they won't overlap?
when miner divide the work to each gpu,
does it divide in a way that they won't overlap?
Most likely. What the point of computing twice the same thing by the way?
I have a gpu miner with mixed gpu. 1080, 1060 6GB and 1060 3GB.
if miner divide the nonce evenly to each gpu, the chance of finding the nonce will be also the same for each gpu.
however, i can see 1080 finds more share than 1060. as 1080 is much faster.
I suspect each thread are trying the nonce randomly.
Those are mining hardware, what software do you use? The allocation of the work is done by the mining software. I believe an intelligent mining software will use each GPU's capacity as a hint on how much work they are assigned to. Infact, it's a process of feedback and adjust constantly. The miner will measure each chip's hashrate and decide whether to increase or decrease the work.
Agree, as the nonce is like randomly located between 0 to unit32_max.
when miner divide the work to each gpu,
does it divide in a way that they won't overlap?
when miner divide the work to each gpu,
does it divide in a way that they won't overlap?
Most likely. What the point of computing twice the same thing by the way?
I have a gpu miner with mixed gpu. 1080, 1060 6GB and 1060 3GB.
if miner divide the nonce evenly to each gpu, the chance of finding the nonce will be also the same for each gpu.
however, i can see 1080 finds more share than 1060. as 1080 is much faster.
I suspect each thread are trying the nonce randomly.
Agree, as the nonce is like randomly located between 0 to unit32_max.
when miner divide the work to each gpu,
does it divide in a way that they won't overlap?
when miner divide the work to each gpu,
does it divide in a way that they won't overlap?
Most likely. What the point of computing twice the same thing by the way?
First, yes, mining is running the nonce from 0 to uint32_max, to find the value that the resulted block hash is less than the target.
It's not random because it won't help anything, you still have to "randomly" try every possible nonce value.
For multiple GPU, it's just like multithreaded processing, the miner software will divide the work to smaller tasks and distribute to each gpu.
It's not random because it won't help anything, you still have to "randomly" try every possible nonce value.
For multiple GPU, it's just like multithreaded processing, the miner software will divide the work to smaller tasks and distribute to each gpu.
Thanks Hushan!
Agree, as the nonce is like randomly located between 0 to unit32_max.
when miner divide the work to each gpu,
does it divide in a way that they won't overlap?
First, yes, mining is running the nonce from 0 to uint32_max, to find the value that the resulted block hash is less than the target.
It's not random because it won't help anything, you still have to "randomly" try every possible nonce value.
For multiple GPU, it's just like multithreaded processing, the miner software will divide the work to smaller tasks and distribute to each gpu.
It's not random because it won't help anything, you still have to "randomly" try every possible nonce value.
For multiple GPU, it's just like multithreaded processing, the miner software will divide the work to smaller tasks and distribute to each gpu.
Hi Guru,
I have a 7 gpu miner. I don't have money to invest in more hardware but would like to improve the miner software.
As I know each gpu is finding the nonce to meet a block difficult. A nonce is a 32 bits number.
gpu sequential loop through the 32 bits numbers + block items -> hash?
or it randoms pick a number to do the hash?
When there are multiple GPU, how miner coordinate the GPUs to find a nonce effectively?
I have a 7 gpu miner. I don't have money to invest in more hardware but would like to improve the miner software.
As I know each gpu is finding the nonce to meet a block difficult. A nonce is a 32 bits number.
gpu sequential loop through the 32 bits numbers + block items -> hash?
or it randoms pick a number to do the hash?
When there are multiple GPU, how miner coordinate the GPUs to find a nonce effectively?
Jump to: