Questions about how the Bitcoin network really works

Hey, good afternoon everyone, I've been diving into some Bitcoin books covering its philosophy, mechanics, and economic aspects. However, I still have some lingering questions: Lately, I've been pondering how the date and time a block gets mined is determined. It seems to me that when a miner successfully mines a block, the epoch time gets shared with their peers along with the block. But if that was sent outside the block, peers could alter that epoch time, which wouldn't work. So, I guess the epoch time must be included in the block itself. But here's where it gets tricky: if it's inside the block, the miner would need to update the epoch time constantly, which would change the hash. This means the miner would have to reset the nonce to 0 every second, not to mention other elements that could be adjusted to create more combinations, like OP_RETURN. I've also noticed blocks show precise times down to the second, so I can’t see how miners could tweak the epoch time every 20 seconds or so. Plus, if they could, there would need to be a range of accepted epoch times above and below the current one, which complicates things since you’d need to know how long it takes for a block to spread through the network and other related factors. For instance, when I check mempool[.]space for block 893254, it shows it was mined at 13:43:43, and when I run my Bitcoin node to get the hash of block 893254, it gives me the same exact time in epoch.

The timestamp is included in the block header, which is used for hashing to find a valid block. It cannot be modified afterward. The time must be within the average of the last 11 blocks, up to 2 hours in the future. The timestamp does not require an exact time.

But now I have another doubt: Imagine I am a bitcoin miner, I am mining block 22 and I receive block 22 mined. I check everything to verify that it is correct, assuming it is, I build block 23 and put the hash of the whole block 22 in the header of 23, I check what is the timestamp now (just after checking that block 22 is correct) and it gives me that the timestamp is 11:54:19. I put that timestamp in the header of block 23 and I start mining, changing the nonce, the OP_RETURN and other things I can change. After 6 minutes of mining, do I still have 11:54:19 in the header of block 23? If I manage to successfully mine the block, I will be transmitting to the network a block with a timestamp that corresponds to when I finished checking that block 22 was correct. Not approximately when I mined block 23. If I do some thinking to try to solve the problem, I could solve it just by updating the timestamp I'm mining to the current timestamp, every ~30 seconds while I'm mining. That means that if I've been mining block 23 for 6 minutes, that means I've changed the block header timestamp 12 times. So, if I manage to mine a block, I would be transmitting to the network a mined block with a timestamp that says that block was mined max 30 seconds ago. But this is an assumption of mine, I have not yet found how many seconds a miner updates the timestamp to the current one, during the mining process.

Adding to what mcdouglasx have said   The timestamp is typically set by the miner when they create the block which is included in the block header. That's because it was considered valid and falls under the validity rule hence became immutable like other data in the block. Like I have been stated above there's no specific time just a range that the timestamp must be greater than the median timestamp of the previous 11 blocks And less than or equal to the network-adjusted time plus 2 hours So 6 minutes can be  considered valid it and the broadcasted time would still be 11:54:19 as long as you don't update it. Miners typically stick with the start timeframe except for specific reasons like failing to meet the validity rule or miners clock diverging from network time or simple New Block been found.  Logical but too expensive with no benefit.

It is simply picked by the miner. There are some consensus rules, that the time of the block has to be strictly greater, than the Median Time Past (MTP) of the last 11 blocks. And there are some non-consensus de-facto standard rules, like "the timestamp of the block cannot be more than 2 hours in the future". And in practice, you can see, how miners can potentially abuse these rules, when they mine blocks with future timestamps in test networks like testnet3 and testnet4. This is one of the reasons, why timestamps are accepted in a given range, around the current timestamp. In theory, rules could be more strict, and require a shorter range of timestamps, but then, mining would be more centralized, if by the time you submit a valid block, it would fall in the range of invalid timestamps. It is much faster in practice, to modify some bits in the block version number, and tweak timestamps a little bit, than modify anything inside merkle root, and recompute its value. This is also the reason, why you can see blocks from the past, or from the future, and some weird version numbers in block headers: just because changing it is faster, than changing for example something inside OP_RETURN, or in the coinbase input. Why not? If we would have precision to a single millisecond or nanosecond, would you think, that miners have to change their headers that fast? In practice, when you have some mining pool, then requesting a new block template every 20 seconds is a normal thing. And then, these "20 seconds" is not how fast miners change timestamps, but it is how fast they change their merkle roots, and update their set of transactions (of course, they can also tweak their coinbase transaction a little bit, but it depends on their mining power, how often they have to use their extra nonce inside coinbase input). No. After 6 minutes of ASIC mining, you would quickly run out of all 2^32 nonces in milliseconds (or maybe seconds, if you have a slower device), then you will tweak some bits in block version, and you will also tweak the block timestamp forward or backward. Also, if you have a huge hashing power, you would probably use some values in your extra nonce, inside your coinbase transaction input. And during 6 minutes, you would probably request a new merkle root every 20 seconds or something around that, so you will check at least 18 different block headers (6 minutes = 360 seconds, 360/20=18). Yes. Every 20, 30, maybe even 15 seconds if you want to, not only you should update your timestamps, but you should also update your merkle root, just to get more transaction fees, because people are sending transactions in the meantime, and if you mine constantly on the first seen block template, after you receive the next block, and grind only on top of that, then your block's health wouldn't be 100%, but maybe 90%, 80%, or even less of what is seen by other nodes. It should be adjusted to your mining power. When you have commands like "generatetoaddress", then you have to specify, how many hashes you want to check. And you should experimentally pick something, which would cause block templates to be updated every 20-30 seconds. If it will be too fast, then you will waste resources on updating your merkle root constantly, and you will mine less blocks, than you potentially could. But if it will be too slow, then your set of transactions will be updated too slowly, so you will lose some transaction fees, by missing some recent transactions. And I think 20 seconds is a reasonable default, and usually I am trying to configure it around that value.

Ahhhh, okay thank you. I thought the timestamp was more precise in relation to when the block was mined, so that we could have the difficulty adjustment more in line with the network's mining power. I didn't think it was taken as another data you could put whatever you wanted (within a specified range) However, I had always assumed that in bitcoin mining there existed a method of choosing the correct order of combinations, which was particularly efficient and widely used by all miners. I thought that these settings were rarely altered. I have a Bitaxe gamma and it did not allow me for changes to that types of configurations.

Well, in theory, nodes could accept timestamps in a more strict way, but still: it won't work for historical data. If you have a block from the past, then it has some timestamp, and you cannot be sure, if it was really mined at that point in time, or was the timestamp tweaked in any way. If your node was part of the network at that time, then you can read some logs. But if you weren't there, then you can only trust other nodes, and their data. For example: when you start a new regtest node, you can see unix timestamp equal to 1296688602, which means "Wed Feb 02 23:16:42 2011 UTC". If you use the default mining code, then you will mine a new block, at height one, with some timestamp from 2025. However, if you configure your miner to use something from March 2011, then it will still be compatible, and your node will happily accept all of your blocks, with fake timestamps, because they still meet the consensus rules for regtest. Which means that in theory, if the hashrate majority would use some timestamps from the past, or from the future, then they could manipulate the difficulty as they please. However, the default implementation can enforce some rules, relative to the system's clock (and can show some warnings, if the time of the network is significantly different). And also, users have their clocks and calendars, and they know, that we are now in 2025, and they will be alarmed, if they will see a chain from 2035, with artificially lowered difficulty. Which means, that even if you can produce a valid chain with fake timestamps, then you still need to convince users, that we have a different time and date, which is hard to do on a wider scale. Usually, miners work on data you send to them. Which means, that if your device uses getblocktemplate or stratum, there is somewhere a field called "timestamp", and your device will mine on top of what you will put there.