Topic: Misunderstanding the nonce (Read 257 times)

I was talking about the end date, ie the time till it gets spent. I observed from the test net, coinbase block reward UTXOs lifetime could reach +35000 block with min 366 thru fast scan. So, it might be misleading to put all UTXOs in one bucket and say they follow a power law distribution with alpha bet 1-2.

OK, that's explain the use of the OP_return and the zero value in coinbase TXs after say 2014, but still the other value bet 0.09-.0.14 most of the time must be stored as an UTXO?Right???

OP_return is a kind of output that isn't stored inside the UTXO set of nodes and it allows the value to be 0. In most of the block generation transaction, the OP_return is mostly used to specify the merkle root of the witness tree.

What is a zero UTXO in a coinbase Transaction means??

aren't these supposed to be the reward transaction? what's the point of zero?

What is a zero UTXO in a coinbase Transaction means??

aren't these supposed to be the reward transaction?

and is the reward now 0.09-0.14 Btc? or is this a divided reward by some mining pool?

I wonder if there is a standard way for storing the nonce values since it sounds like that there are pools that are using nonce+timestamp or nonce+coinbase script, or nonce+version bit (or maybe even a combination of these), and having different formats for storing the nonce used at the same time will cause a headache for people trying to scrape the nonce information.

Nope. I suspect that there's just an OP_PUSHBYTES involved for storing the extra nonce, so the UTXO should still have the same creation date.

1-May I ask, aside from the topic, does using the coinbase Transaction this way as a part of Nonce affects the life length of its UTXO???

I wonder if there is a standard way for storing the nonce values since it sounds like that there are pools that are using nonce+timestamp and nonce+coinbase script (or maybe even all three), and having different formats for storing the nonce used at the same time will cause a headache for people trying to scrape the nonce information.

There are a lot of variables which can be changed within the block for a completely new block hash. Look at your block header, if you can change anything within that, you're able to hash a completely new string and thus counts as an attempt to get the block header that meets the target.

Other than nonce, timestamp, miners can also choose to rearrange the transactions within the block, changing something within your Coinbase scriptsig, etc. As long as the way you change your block header doesn't invalidate the entire block. Overt ASICBoost uses the versionbit and thus that is why some blocks has a strange version bit, also a way to change the block header but this is an optimization for certain ASICs.

I believe miners will be able to create even more variables as "extra nonce" as difficult increases.

In this block https://www.blockchain.com/btc/block/000000000000000000024b00ee235c122bde60104462bb41396428af892bf9ac

the Nonce is 3,564,549,738 which isn't a very large number.

I thought proof of work required miners to find a nonce that when added to the block data, produced a block hash of something beginning with a string of zeros.

If I started with a nonce of 1 and tried hashing 1,2,3,5...3,564,549,738 - that would not take much work at all.

Obviously I am completely misunderstanding something, as all the nonces on recent blocks are fairly small

In the genesis block, for example, Satoshi Nakamoto added the text “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks” in the coinbase data, using it as a proof of the date and to convey a message. Currently, miners use the coinbase data to include extra nonce values and strings identifying the mining pool, as we will see in the following sections.
...
The next few hexadecimal digits (03858402062) are used to encode an extra nonce (see The Extra Nonce Solution), or random value, used to find a suitable proof of work solution.

...

The Extra Nonce Solution
Since 2012, bitcoin mining has evolved to resolve a fundamental limitation in the structure of the block header. In the early days of bitcoin, a miner could find a block by iterating through the nonce until the resulting hash was below the target. As difficulty increased, miners often cycled through all 4 billion values of the nonce without finding a block. However, this was easily resolved by updating the block timestamp to account for the elapsed time. Because the timestamp is part of the header, the change would allow miners to iterate through the values of the nonce again with different results. Once mining hardware exceeded 4 GH/sec, however, this approach became increasingly difficult because the nonce values were exhausted in less than a second. As ASIC mining equipment started pushing and then exceeding the TH/sec hash rate, the mining software needed more space for nonce values in order to find valid blocks. The timestamp could be stretched a bit, but moving it too far into the future would cause the block to become invalid. A new source of “change” was needed in the block header. The solution was to use the coinbase transaction as a source of extra nonce values. Because the coinbase script can store between 2 and 100 bytes of data, miners started using that space as extra nonce space, allowing them to explore a much larger range of block header values to find valid blocks. The coinbase transaction is included in the merkle tree, which means that any change in the coinbase script causes the merkle root to change. Eight bytes of extra nonce, plus the 4 bytes of “standard” nonce allow miners to explore a total 296 (8 followed by 28 zeros) possibilities per second without having to modify the timestamp. If, in the future, miners could run through all these possibilities, they could then modify the timestamp. There is also more space in the coinbase script for future expansion of the extra nonce space.

Obviously I am completely misunderstanding something, as all the nonces on recent blocks are fairly small