Help a newbie; why is hashing not done once but twice during Bitcoin transaction

[odolvlobo]

Adding timestamp to transaction require soft/hard fork, so you need to convince Bitcoin community instead. Although it's different case if it's opt-in where you simply utilize OP_RETURN.

But you can stuff anything you want to in OP_RETURN. Including fake timestamp.

Even if a transaction had a timestamp, you could fake that, too. There is nothing that could ensure that a block's and transaction's timestamps are accurate. Remember that it can take days for a transaction to be included in a block, it can take minutes for a block to propagate, and node times are not synchronized.

[1715097579]

1715097579

[1715097579]

1715097579

[1715097579]

1715097579

[1715097579]

1715097579

[kaggie]

Secondly why is hashing not done once but twice in Bitcoin?

That is a good question. It turns out that it has to do with the so-called length extension attack. I have never seen this been discussed back in the early days, though, so there may be another reason.

Oooo.
You hit the nail on the head there.
I'm going to guess that it wasn't discussed when Satoshi was around for two reasons: 1) It was implicit. Satoshi didn't explain a lot of what he did unless questioned on it. Length extension attack would have been an obvious vector if he had played with it. Besides, questioning all potential flaws publicly in a developing system might cause people to try to break it before you can secure it, when you prefer to keep testing its resilience privately. 2) Either the users were still developing and didn't have enough understanding of the code and mathematics to question it, or understood your reason as the reason. There was nothing to question for the last group.

Thus, it never came up.

[pooya87]

I'm going to guess that it wasn't discussed when Satoshi was around for two reasons: 1) It was implicit. Satoshi didn't explain a lot of what he did unless questioned on it. Length extension attack would have been an obvious vector if he had played with it. Besides, questioning all potential flaws publicly in a developing system might cause people to try to break it before you can secure it, when you prefer to keep testing its resilience privately. 2) Either the users were still developing and didn't have enough understanding of the code and mathematics to question it, or understood your reason as the reason. There was nothing to question for the last group.

Or just that length extension attacks and protection against them using double hashing was already a well know thing that nobody bothered asking about it! For example in chapter 6.3.1 of the book Practical Cryptography published in 2003 (Bitcoin was released in 2008) it explains that a countermeasure against such attacks is to compute SHA-X(SHA-X(m)) where X is 1, 256, 384 or 512.
HMACSHA functions also use the same principle to solve the length extension attacks which is a problem in MACs not so much in simple hashes.

[o_e_l_e_o]

i thought thats what the nonce was for.

The nonce is only 4 bytes, meaning a total of 4.3 billion possibilities. Miners can exhaust this search space in under a second. They need to be able to change other things in the block in addition to the nonce. The timestamp is one such option for them, alongside extraNonce, which transactions they include, and the order of those transactions.

I don't know. I just thought they were.

Blockchain.com is not a reputable company. I would not even use their products, let alone attach any degree of authority to them.

Without an accurate timestamp on your transaction how do you properly convince a tax authority exactly when a transaction occurred?

But this becomes trivial to fake, since a signed transaction can be not broadcasted for any length of time. I could easy sign and broadcast a transaction with a timestamp of 5 years ago to gain beneficial tax treatment. As far as most governments are concerned, the transaction occurs when it was confirmed. Usually the time between a transaction being broadcast and being confirmed is a few hours at most, so irrelevant from a tax point of view.

[kaggie]

Or just that length extension attacks and protection against them using double hashing was already a well know thing that nobody bothered asking about it! For example in chapter 6.3.1 of the book Practical Cryptography published in 2003 (Bitcoin was released in 2008) it explains that a countermeasure against such attacks is to compute SHA-X(SHA-X(m)) where X is 1, 256, 384 or 512.
HMACSHA functions also use the same principle to solve the length extension attacks which is a problem in MACs not so much in simple hashes.

Agreed.  

I think it's fair enough to question though.
With any hashing function, you lose information and risk an increased number of collisions. If you hash twice, you risk more collisions from what I understand. This is a risk - but we agree that this is an acceptable risk so that we can sign transactions, as long as we start off with enough random information.

The risk that Satoshi really played with here though is the long term building of a currency based off of this.
I mean, fair enough, if you want to use methods like this for your one off encrypted projects, your personal project, your messenger services, or even your large corporations. Most of these are personal and don't require long term security that a currency needs - which has to be resilient to both change and attacks. Most of these don't involve multi-billion dollar risks if it's broken, or have the ability to adapt over time to changing technology. Bitcoin needs to be set as a protocol and have long term resilience unless you want to force everyone to transact their entire life savings frequently (which you don't). I think it was a risk for Satoshi to have played with the double hash due to this need for longevity, although that risk was clearly much less by the larger risk of a single hash. (Risks everywhere? The benefit of hindsight..) That the double hash has worked for 20 years generally (edit: I guess longer, actually!) and 13 years in bitcoin is a credit to it, but, man, the difference between a few years isn't that much for something hoped to last decades or longer. The longevity of the double hash was still an unknown, even if it was better in theory. There are several other things that have been broken and fixed over time in bitcoin that I'm surprised as a novice at how resilient the double hash has been.

I was responding more to why it wasn't discussed in the early forum. You had varying degrees of understanding. The first few forum members still seemed to be wrapping their head about the basics without going into detail about much more complicated topics. The very few people who had been working with Satoshi pre-forum and later more serious developers like Andresen had probably already thought about it or looked things like that up quickly. So I agree with you, they didn't need to discuss it. I also think things may not always have been openly discussed when they present possible flaws, because you have groups that want to patch before exploitation or to use those exploits for their own greed - the double hash might have been caught up into a phenomenon like that even if it never had that weakness. So there are several reasons why it wasn't discussed.

[larry_vw_1955]

 If the signer can set the timestamp, which doesn't make sense, you can't know if it's faked.

Can't you just let the network put a timestamp on it? It seem like such a simple thing to know what time each transaction occurred at least accurate to the second. But then you run into the problem of how do you put a timestamp on to a transaction, at exactly what point do you stamp it? I guess when it is first submitted to the network, first seen. The block timestamp would be the secondary timestamp to let you how long it took from submission to confirmation.

True, but your option is quite limited when the community don't wish for such feature.

Right. People doesn't always realize why they need a particular feature until they can see some of the applications of it. But I think we could agree that if every transaction had a meaningul timestamp, that would make bitcoin more powerful.

With any hashing function, you lose information and risk an increased number of collisions. If you hash twice, you risk more collisions from what I understand.

that's correct. it essentially doubles the risk of a collision.

[BlackHatCoiner]

With any hashing function, you lose information and risk an increased number of collisions. If you hash twice, you risk more collisions from what I understand.

More hashes are calculated so it's reasonable to make this conclusion, but it's actually the opposite when it comes to the effort. It doesn't matter if you've hashed the transaction a million times; only the last hash is the one that's taken into the database. But, those who'll try to find collision will have to go through the previous hashes, which means more effort for the same result.

So, I'd say the more the hashes, the more the odds to find a collision for a random hash, but the less the incentive to do so.

Can't you just let the network put a timestamp on it?

Essentially, it does. The timestamp server is the ledger and users rely on proof of work instead of the signer or in any authority.

The block timestamp would be the secondary timestamp to let you how long it took from submission to confirmation.

As said, there's no way to ensure the time during the submission without introducing trust.

[o_e_l_e_o]

Can't you just let the network put a timestamp on it?

"The network" is not a single entity. It is a collection of nodes. Let's say I put a timestamp on a transaction and broadcast it to you. How can you trust my timestamp? How do you know I didn't just timestamp it 10 minutes in the past? It is trivial to fake.

People doesn't always realize why they need a particular feature until they can see some of the applications of it.

If a feature has no applications, then it is not worth the extra bloat it will bring.

But I think we could agree that if every transaction had a meaningul timestamp, that would make bitcoin more powerful.

Why? Transactions are confirmed in blocks, and blocks are ordered right back to the genesis block. Timestamps are irrelevant.

[kaggie]

that's correct. it essentially doubles the risk of a collision.

With any hashing function, you lose information and risk an increased number of collisions. If you hash twice, you risk more collisions from what I understand.

More hashes are calculated so it's reasonable to make this conclusion, but it's actually the opposite when it comes to the effort. It doesn't matter if you've hashed the transaction a million times; only the last hash is the one that's taken into the database. But, those who'll try to find collision will have to go through the previous hashes, which means more effort for the same result.

So, I'd say the more the hashes, the more the odds to find a collision for a random hash, but the less the incentive to do so.

It sounds like I wasn't too far off with disagreements already here.

The assumption comes from the reduction from the range of bitcoin addresses where the space of 2^256 bitcoin keys available  hash into 2^160ish addresses, increasing collision chances - though not enough to care. (If we mapped a space of 2^256 keys to a space of 2^256 addresses, then it's better called encrypting and not hashing.) MD5 is the other counter-example where hashing causes flaws, but I guess we should leave bad hashes out of this discussion!

Point taken though, I had not thought of key strengthening by adding computational steps against rainbow table/dictionary attacks by stringing multiple hashes together, particularly ones that cause hash lengthening. I found this useful article on it: https://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once/17396367#17396367

Multiple hashing would add security against a dictionary, but not against all brute-force. A brute-forced preimage only depends on the last hash step when there is no key lengthening (or if its input has a larger/equal range than the outputs). If the last step breaks then, it doesn't matter what hashes were done before in a brute-force attack.

This article was useful to me:
https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad

This person suggests that the double hash prevents length extension, although the next person vehemently disagrees that the double hash benefits at all!
https://bitcoin.stackexchange.com/a/9203

[larry_vw_1955]

The nonce is only 4 bytes, meaning a total of 4.3 billion possibilities. Miners can exhaust this search space in under a second. They need to be able to change other things in the block in addition to the nonce. The timestamp is one such option for them, alongside extraNonce, which transactions they include, and the order of those transactions.

Then whats the purpose of the nonce in the first place if it's not sufficient in size to be able to generate a hash lower than the difficulty? Don't you think that if bitcoin was designed properly, it could fulfill that role without having to spill over and start modifying things whose purpose has nothing to do with the nonce.

Blockchain.com is not a reputable company. I would not even use their products, let alone attach any degree of authority to them.

I've heard of people having issues with their online wallet but that's about the only negative thing i heard about them. But that has zero to do with their blockchain product which used to be called blockchain.info i think it was one of the first block explorers for bitcoin that appeared online.

"The network" is not a single entity. It is a collection of nodes. Let's say I put a timestamp on a transaction and broadcast it to you. How can you trust my timestamp? How do you know I didn't just timestamp it 10 minutes in the past? It is trivial to fake.

Well that's a naive question given the framework of bitcoin. It's like asking "suppose I give you a transaction but suppose there is no blockchain to looks things up, how do you know it's valid? you could have just made it up".

If a feature has no applications, then it is not worth the extra bloat it will bring.

time is a fundamental quantity of physics. it is natural to measure things using time. but yeah bitcoin cant do that. i agree.

Why? Transactions are confirmed in blocks, and blocks are ordered right back to the genesis block. Timestamps are irrelevant.

blocks serve as a rough timestamp for transactions but that's all. if you want to know anymore than that, you can't. but it seems like timestamps are not so irrelevant. for example say you are a daytrader trading in the stock market. your trades are timestamped down to the millisecond i bet. so if there is any discrepancies, they can research the transaction. without knowing when it occured exactly they can't understand what happened. and then there is the possibility for fraud.

[o_e_l_e_o]

Then whats the purpose of the nonce in the first place if it's not sufficient in size to be able to generate a hash lower than the difficulty? Don't you think that if bitcoin was designed properly, it could fulfill that role without having to spill over and start modifying things whose purpose has nothing to do with the nonce.

Because it doesn't need to be any bigger. Every time you change anything about the block, then you change the block header and reset the nonce field. Why have a 32 byte nonce when you could only search a tiny fraction of it before incrementing the timestamp by 1 second and starting again? It's just more unnecessary bloat.

I've heard of people having issues with their online wallet but that's about the only negative thing i heard about them. But that has zero to do with their blockchain product which used to be called blockchain.info i think it was one of the first block explorers for bitcoin that appeared online.

I mean, not just issues, but critical vulnerabilities such as reusing k values and resulting in people losing their coins. Their block explorer also took literally years to start recognizing segwit addresses, and again spent years incorrectly reporting fees in sats per raw byte, when the network had long moved on. They are insecure and outdated.

time is a fundamental quantity of physics. it is natural to measure things using time. but yeah bitcoin cant do that. i agree.

Bitcoin measures things based on a cryptographic order. This cannot be spoofed, cannot be faked, cannot go out of sync. Timestamps are not accurate in a distributed database.

for example say you are a daytrader trading in the stock market. your trades are timestamped down to the millisecond i bet.

And if you trade on a centralized exchange then you'll get that. It's still irrelevant for the network, though.

[kaggie]

Can't you just let the network put a timestamp on it? It seem like such a simple thing to know what time each transaction occurred at least accurate to the second. But then you run into the problem of how do you put a timestamp on to a transaction, at exactly what point do you stamp it? I guess when it is first submitted to the network, first seen. The block timestamp would be the secondary timestamp to let you how long it took from submission to confirmation.

Why would you want a timestamp? You can't trust it completely. What happens if a node decides to change its computers time to a few minutes in the future or past to argue that its transactions came first, or never happened in time? Using a timestamp beyond the locktime already there only creates confusion.

There's already locktime if a transaction wants to include that.
The various miners agree on an average time and accept only blocks within a limit of that time.


It's best to leave a timestamp out for when a transaction first hits a node as it would lead to an inaccurate understanding, possibly cause fingerprinting, and then cause gaming of the system if ever used for anything important. The whole point of bitcoin is that it solves the byzantine problem, which is that you can't trust what any single node is saying about something as silly as a timestamp. You might even begin to reject transactions that are submitted to certain nodes that had latency issues that day, which would be unstable for users.

Let's say you use a timestamp for anything important. How would you game it?
Even if all computers had exactly the right time, corrected for network/speed of communication differences. You could submit the same transaction at two different nodes with vastly different latency, like in different parts of the world. Now what are you going to do with the timestamp? If you argue one came before the other, perhaps to cause a lawsuit about ownership, then you could never prove that fully, and you've now confused a non-technical jury.  

[larry_vw_1955]

Because it doesn't need to be any bigger. Every time you change anything about the block, then you change the block header and reset the nonce field. Why have a 32 byte nonce when you could only search a tiny fraction of it before incrementing the timestamp by 1 second and starting again? It's just more unnecessary bloat.

Yeah I can see the reason for allowing the timestamp to increment by 1 second. But it shouldn't be allowed to go up by 2 hours into the future. that wouldn't make any sense why that would be necessary.

I mean, not just issues, but critical vulnerabilities such as reusing k values and resulting in people losing their coins.

well there's always a cost for convenience. in this case, for having an online bitcoin wallet you expose yourself to that type of issue. not sure what to tell someone that would put alot of money into an online wallet like that.

Their block explorer also took literally years to start recognizing segwit addresses, and again spent years incorrectly reporting fees in sats per raw byte, when the network had long moved on. They are insecure and outdated.

Even now? to be fair, alot of bitcoin wallets never supported segwit to begin with and many of them took a long time to add that support in. probably some of them still only support legacy addresses. Vendors were slow to adopt changes to bitcoin. I think that's a recurring theme.

Bitcoin measures things based on a cryptographic order. This cannot be spoofed, cannot be faked, cannot go out of sync. Timestamps are not accurate in a distributed database.

ok but what about this then: https://timegov.boulder.nist.gov/
why do you think services like that exist? so that computers can coordinate their clock and agree on an official time.

Why would you want a timestamp?

Why would you not want one? One of the most basic things you can ask about something is when it happened. When did it get submitted. When did it get confirmed. Maybe I want to know all of that.

What happens if a node decides to change its computers time to a few minutes in the future or past to argue that its transactions came first, or never happened in time?

Need a way to ensure compliance. There has to be a way to force everyones clock to be in agreement. But no one seems to have any idea.

[kaggie]

Yeah I can see the reason for allowing the timestamp to increment by 1 second. But it shouldn't be allowed to go up by 2 hours into the future. that wouldn't make any sense why that would be necessary.

Part of this may be historical in that Satoshi didn't know whether computers would be connected continuously to start. But another part is this:

Why would you not want one? One of the most basic things you can ask about something is when it happened. When did it get submitted. When did it get confirmed. Maybe I want to know all of that.

Enforced timestamps from those transacting, nodes, and miners would require extra space in the blockchain on all transactions. Those timestamps may not be trustworthy. And privacy would disappear due to all sorts of fingerprinting. Is it safe to assume that you would want it for analytics of some sort?

Also, how many nodes' timestamps should you include? Just the first one, or all that a transaction reaches before being mined? How do you put those in the blockchain so that people can access them? How can a node know whether it had reached another computer first? What if a malicious node started to modify these after the previous node? If it was enforced to timestamp on first node entry, this would enable targeting of specific nodes through spam transactions, and possibly allow methods to target processor speed, location, user hours, and more. It just seems like bad mojo and would enable identifying people, and would further enable the targeting of those individuals.

Need a way to ensure compliance. There has to be a way to force everyones clock to be in agreement. But no one seems to have any idea.

I'm sure there are ways, but whether those would be peer to peer currencies or people would be willing to invest in them is another matter. I'd bet that there are blockchains that do this.

ok but what about this then: https://timegov.boulder.nist.gov/

As Loyce points out below just now, enforcing this would be another problem. Imagine if your DNS or ISP forces you to use a different time stamp server unbeknownst to you, thereby kicking you off from processing transactions. If bitcoin increases globally, that would be a major vector to stop users from being able to mine because they couldn't be within a stringent time stamp protocol. Sure, we have time services like this now, and it's unlikely that such a service would go down within the next 50 years, but what if it did? What if the country that offers a time service ends up being sanctioned, and everything else goes down because of it?
-
e: Like what oleo below wrote: If you really want it, you could keep of when all transactions are submitted now. Just capture and timestamp everything in the mempool. For more accuracy, you will have to run enough nodes that can capture transmitted transactions from all other nodes in time, and then timestamp and store when these transactions occur.
e2: Also, there is already a timestamp of whenever transactions occur, just not within a fast temporal resolution, but still an impressive feat for a continuous 13 year period that anyone can verify.

[LoyceV]

Yeah I can see the reason for allowing the timestamp to increment by 1 second. But it shouldn't be allowed to go up by 2 hours into the future. that wouldn't make any sense why that would be necessary.
~
ok but what about this then: https://timegov.boulder.nist.gov/
why do you think services like that exist? so that computers can coordinate their clock and agree on an official time.

That would add terrible centralization to the Bitcoin protocol! Satoshi's implementation of "2 hours" has worked fine so far, and given the fact that some miners use a different time stamp: it is needed! By basing the time on previous blocks, it becomes a more or less decentralized average of the time used by other miners. All miners can know for sure from the previous blocks that their time is correct to be accepted. If only a one second difference would be allowed, you'll get the situation in which some miners think it's okay, while others reject the block.

[o_e_l_e_o]

Yeah I can see the reason for allowing the timestamp to increment by 1 second. But it shouldn't be allowed to go up by 2 hours into the future. that wouldn't make any sense why that would be necessary.

Because, again, the timestamp does not determine order. It needs to be roughly accurate to allow difficulty retargeting, that's all. If you enforce a limit of 1 second, then you are going to end up with a huge number of rejected blocks due to network latency, syncing issues, verification time, etc.

ok but what about this then: https://timegov.boulder.nist.gov/
why do you think services like that exist? so that computers can coordinate their clock and agree on an official time.

And if the whole network depends on that one website, then bitcoin is now centralized and can be shutdown by a single person taking that site offline.

Why would you not want one? One of the most basic things you can ask about something is when it happened. When did it get submitted. When did it get confirmed. Maybe I want to know all of that.

Then run your own node and keep a database of whenever you first see every transaction and every block. Your timings will be unique when compared to every other node. It doesn't make sense to take about when a transaction was first seen in a decentralized network, since every node will see it at a different time.

[larry_vw_1955]

Yeah I can see the reason for allowing the timestamp to increment by 1 second. But it shouldn't be allowed to go up by 2 hours into the future. that wouldn't make any sense why that would be necessary.

Part of this may be historical in that Satoshi didn't know whether computers would be connected continuously to start.

Maybe but maybe Satoshi wasn't sure how many megahash some hardware might eventually get up to. Thus, it might burn through nonces and timestamps much faster than "real time". So it might need to go out to 2 hours in the future to get a valid hash, if the difficulty was high enough.

Enforced timestamps from those transacting, nodes, and miners would require extra space in the blockchain on all transactions. Those timestamps may not be trustworthy. And privacy would disappear due to all sorts of fingerprinting. Is it safe to assume that you would want it for analytics of some sort?

no particular analytics but i just thought it's nice if the network can agree on when a transaction was first seen and put that as the timestamp of the transaction inside the block.

Also, how many nodes' timestamps should you include?

Just the node that first received the transaction once it had been submitted to the network. Is all I was thinking. Whether it takes 1 minute or 1 week to get mined is another story but there could be a second timestamp for that perhaps. And that's it.

How can a node know whether it had reached another computer first?

Yeah I don't know about that. They would need a consensus mechanism to agree on something like that.

What if a malicious node started to modify these after the previous node?

There would have to be some type of cryptographic protocol to validate timestamps.

I'm sure there are ways, but whether those would be peer to peer currencies or people would be willing to invest in them is another matter. I'd bet that there are blockchains that do this.

not sure if there are. maybe solana but i'm not sure.

e2: Also, there is already a timestamp of whenever transactions occur, just not within a fast temporal resolution, but still an impressive feat for a continuous 13 year period that anyone can verify.

it is impressive.

Then run your own node and keep a database of whenever you first see every transaction and every block. Your timings will be unique when compared to every other node. It doesn't make sense to take about when a transaction was first seen in a decentralized network, since every node will see it at a different time.

So you're saying it is impossible to make "when a transaction was first seen" be a well defined concept in a decentralized network such as bitcoin that uses proof of work. without a major overhaul i think i would have to agree.

[o_e_l_e_o]

Maybe but maybe Satoshi wasn't sure how many megahash some hardware might eventually get up to. Thus, it might burn through nonces and timestamps much faster than "real time". So it might need to go out to 2 hours in the future to get a valid hash, if the difficulty was high enough.

But changing anything about the block allows you to reset the nonce (and effectively also the timestamp, giving you another 2+ hours to work through). There is the entire extraNonce field that miners can change, but also even something a simple as changing the order of the transactions they include (never mind including different transactions), will let you reset the nonce. In a block with 1000 transactions, there are 1000! different ways to order them, which is something in the order of 2⁸⁵²⁹ possibilities, far in excess of anything that will ever be needed. In reality, most miners use the extraNonce field and don't bother adjusting the timestamp at all.

Just the node that first received the transaction once it had been submitted to the network. Is all I was thinking. Whether it takes 1 minute or 1 week to get mined is another story but there could be a second timestamp for that perhaps. And that's it.

Which makes it trivial to fake. "Oh hey, I saw this transaction two weeks ago but my node has been offline since then."

There would have to be some type of cryptographic protocol to validate timestamps.

You are now adding additional size to every transaction, thereby increasing fees, decreasing block space, and increase transaction time, as well as adding additional verification requirements for every transaction at every node, which will again slow things down, delay propagation, increase stale blocks, and so on. There are a lot of downsides to doing this. There would need to be a very good reason or major benefit to such a feature.

[kaggie]

Just the node that first received the transaction once it had been submitted to the network. Is all I was thinking. Whether it takes 1 minute or 1 week to get mined is another story but there could be a second timestamp for that perhaps. And that's it.

Which makes it trivial to fake. "Oh hey, I saw this transaction two weeks ago but my node has been offline since then."

There would have to be some type of cryptographic protocol to validate timestamps.

You are now adding additional size to every transaction, thereby increasing fees, decreasing block space, and increase transaction time, as well as adding additional verification requirements for every transaction at every node, which will again slow things down, delay propagation, increase stale blocks, and so on. There are a lot of downsides to doing this. There would need to be a very good reason or major benefit to such a feature.

The irony is that adding a timestamp on first transaction would make your knowledge of transaction timestamps LESS reliable by slowing down propagation to all nodes.

I guarantee that if a timestamp was added on first node that there would be services that popped up to delay transactions. You could try to sign a transaction with something from a dedicated time server, but even then, there's nothing that would stop a transaction from being signed very early but sent later.

You have to run your own node to capture this information as accurately as possible. You might even get a group of nodes to coordinate to timestamp things better. (What's the difference? ::shrug:: )

[Cricktor]

Maybe but maybe Satoshi wasn't sure how many megahash some hardware might eventually get up to. Thus, it might burn through nonces and timestamps much faster than "real time". So it might need to go out to 2 hours in the future to get a valid hash, if the difficulty was high enough.

But changing anything about the block allows you to reset the nonce (and effectively also the timestamp, giving you another 2+ hours to work through). There is the entire extraNonce field that miners can change, but also even something a simple as changing the order of the transactions they include (never mind including different transactions), will let you reset the nonce. In a block with 1000 transactions, there are 1000! different ways to order them, which is something in the order of 2⁸⁵²⁹ possibilities, far in excess of anything that will ever be needed. In reality, most miners use the extraNonce field and don't bother adjusting the timestamp at all.

Changing the order of transactions in a block could be computationaly "expensive" for miners, because you need to recompute the merkle tree hashes to some amount, depending on the position of the changed transactions in the merkle tree, where the merkle tree hash contributes to the block header. Miners very likely choose the least expensive way to reset the nonce for further needed hash crunching.


In the timestamp discussion one should also keep in mind what user/miner supplied data you can trust. Bitcoin is trustless by design, it doesn't make sense to expect data from users or nodes like transaction timestamps whoes trust level is unknown or nonexistant. It's a good and wise decission to leave out details which you can't trust or where it complicates things to unknown extend to make the data trustworthy. Keep it simple...