Misunderstanding the nonce

[numbskull]

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

[1714659816]

1714659816

[1714659816]

1714659816

[1714659816]

1714659816

[BlackHatCoiner]

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

Not sure, but when you mine, nonce isn't the only thing changing. As far as I know, every second, the timestamp changes. I believe that once the program changes the timestamp, it sets nonce = 0 and starts all over again.

Generally, there isn't a nonce bigger than ~4.2 billion because nonce is a 32 bits int (again AFAIK). The miner must change other values too to not produce the same hash.

[bitmover]

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

You are not fully misunderstanding. There are extra nonces, as BlackHatCoiner mentioned. However, timestamp is not enough anymore, and miners also added coinbase transaction as an extra nonce.

I was able to find something about it in Mastering Bitcoin book.

https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html

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.

As mentioned in the above text, miners will be able to create even more variables as "extra nonce" as difficult increases in the coinbase script.


I made a quick summary on PoW here

[ranochigo]

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.

[garlonicon]

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

The best extra nonce I found (and the most difficult to see) is simply incrementing public key in the coinbase transaction. Exhausting all nonces in this case is almost impossible and there is no need for any extra bytes in this case.

[numbskull]

Thanks all - it makes sense now.

My misunderstanding was thinking that you are guaranteed to find a PoW hash by cycling through all values of that single Nonce.  But you aren't of course (given is a 4 byte integer) - so you have to be able to tweak the block in other ways.

[NotATether]

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 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.

[ranochigo]

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.

Yes, actually. The position of the nonce is defined in the block header, specifically the last 4 bytes of it. That isn't changed, no matter how the miner decides to change the parameter. Miners have to change the timestamp from time to time, or at least another parameter else the nonce will overflow.

Note that changing a parameter within the block header doesn't make that a nonce. It is just a way for the miner to vary the block header in order to produce a different hash.

[Shymaa-Arafat]

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???
.
2- Since u r probably aiming at the security strength of Bitcoin when discussing the length of the Nonce, have u heard this talk?
https://t.co/Ee6B94w9XW?amp=1
It's mostly about Ethereum but it discusses in mins 29-32 the hash rate price and the power law of Bitcoin
Is it true that the economic cost of 1 tera hash is 50$, and the space is 200m tera hash~about 10 billion $ economic security, when divided by the money worth of Bitcoin ~ 1 trillion $ gives 100
Is there any facts/numbers twisting or misleading argument here?

[NotATether]

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???

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.

In those cases where the timestamp is being used as the extra nonce, it may be possible to guess with machine learning which blocks have the nonce stored this way (as info about who mined the block is not included inside it), so that you can "fix" the timestamp value.

[Shymaa-Arafat]

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.

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.
.
I should put a copy of this observation in the Transaction Graph Analysis topic thread

[achow101]

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.

There is somewhat of a defacto standard in that the extra nonce is usually part of the coinbase script. This comes about because the vast majority of mining pools use the stratum v1 protocol which requires that the miners put the extra nonce in a specific place in the coinbase transaction that the mining pool has allocated for them. As such, it almost always is part of the coinbase script because that is an area where the individual miner can modify without affecting other consensus parts of the transaction or the payout address. However the actual format within the coinbase script itself can vary as those are determined by the mining pool. Some pools may use an OP_PUSHBYTES, some may have extra nonces of different lengths, etc.

[Shymaa-Arafat]

What is a zero UTXO in a coinbase Transaction means??
https://blockstream.info/testnet/block/000000000000066f8c1ff21317b32cd8732022cb938a268a9e0a8177a8f9bc7e
aren't these supposed to be the reward transaction? what's the point of zero? and is the reward now 0.09-0.14 Btc? or is this a divided reward by some mining pool?
Most 2021 coinbase TXs r like this
.
(If this Q better suited elsewhere u may move it to the right place)

[BlackHatCoiner]

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

In the coinbase transaction you linked, it's just an OP_RETURN. Here's a stackexchange thread explanation: Explanation of what an OP_RETURN transaction looks like

aren't these supposed to be the reward transaction?

It does reward the miner. It created two outputs. The one with 0.09765625 tBTC and the other (OP_RETURN) with 0 tBTC.

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

No, these testnet bitcoins aren't distributed. It's a block reward, pretty obvious from the coinbase label, and it rewards only one address which means, one miner. The thing that may confused you is the amount of rewarded bitcoins. Halving occurs faster than in mainnet, since every block isn't being generated every 10 minutes.

We're right now on block 1,976,241 which means 9th halving. Each block generates 0.09765625 tBTC.

[ranochigo]

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

The coinbase transaction doesn't require any reference to any UTXO, simply because there is nothing you have to reference.

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

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.

[Shymaa-Arafat]

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.

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???

[ranochigo]

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???

Yes. That is the block rewards, if an UTXO is not created for that, then you're not able to spend it at all. The value can be less than the block rewards + TX fees but can never exceed it.

[NotATether]

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.

Well given that the majority of miners store the extra nonce this way I doubt that there is a correlation between coinbase rewards of blocks mined by miners who put the extraNonce in the coinbase and Time To Spend.

Though as you mentioned, coinbase UTXOs do tend to last longer considering that there's a minimum #blocks before you can spend it and also since miners are the ones who have them and not normal bitcoiners they might wait until the best time to spend it.