Quote from: DannyHamilton on May 07, 2015, 06:51:02 PM

Quote from: valiron on May 07, 2015, 06:20:55 PM

- snip -
for solving the block you change other fields.

There aren't very many other fields to change. That's why the block has a nonce in the first place. There's nothing special or magical about changing the nonce, it's just 4 bytes added to the header specifically for the purpose of being very fast and easy to change.

The other fields of the block header are:

The block version number. This 4 byte field cannot be changed without invalidating the block you are mining.
The hash of the previous block in the chain. This 32 byte field cannot be changed without invalidating the block you are mining.
The merkle root of the transaction list. This 32 byte field cannot be changed without modifying or rearranging the transactions in your transaction list. This would be a MUCH slower and more complicated thing to change than the nonce. However, a pool will create MANY different merkle roots (by modifying the extranonce in the coinbase transaction) so that they can give a different block header to each miner. This allows each individual miner to only need to deal with the nonce (and timestamp) and not need to recompute the entire merkle root. It is also possible for the pool to provide enough information for individual miners to modify the extranonce themselves along with the nonce. Keep in mind though that modfying the extranonce increases the time and effort involved, so it makes more sense to exhaust the nonce range available to the equipment before making any effort to move on to a new extranonce.
The timestamp. This is a 4 byte field that some miners change after they've run out of nonces. It essentially becomes a secondary nonce. However, it is very limited on allowable ranges. Since the miner would need to test to make sure a value is within the allowable range before hashing the block, it very slightly increases the effort as compared to simply using the usual nonce. If someone chooses to modify this instead of the nonce (or while keeping the nonce in a tight range), then this field BECOMES a nonce. There is no benefit of manipulating these 4 bytes instead of the other 4 bytes.
The current difficulty (represented as "bits"). This 4 byte field cannot be changed without invalidating the block you are mining.
The nonce. This 4 byte field exists solely so that is is fast and easy to modify the header before hashing it again. It serves no other purpose, and has no restrictions on its value. This is also the field that you are saying NOT to change when "you change other fields".

That's 4 bytes + 32 bytes + 32 bytes + 4 bytes + 4 bytes + 4 bytes = 80 bytes.

That's it. There's the 80 bytes that are hashed during mining. I'm very curious to know which of those fields you think might be better to change instead of the nonce?

Those in red cannot be changed without invalidating the block. Those in green are already manipulated as part of the typical mining process, and the typical mining process already manipulates them in the most efficient order. If there is a benefit to manipulating the timestamp or merkle root INSTEAD of the nonce, I'd be very curious to know what you think that benefit might be.

I'm not certain, but I don't think you can adjust the merkle root without needing to recompute the midstate as well?

The intention of my comment was that if mining in a classical way with repetitive trials it doesn't make sense to not change the nonce for that purpose.

What I was observing is that if we find evidence of someone fast mining without changing much the nonce, it probably means that he is mining in a non-classical way. As pointed out the version number can be changed quite freely, but be safe, gmaxwell will fork if this happens, you can find a discusion of header malleability here: https://bitcointalk.org/index.php?topic=563913.0