Strange Timestamp Argument

[xmready]

I found someone trying to argue there is a timestamp vulnerability in Bitcoin. The post seemed off to me, but I don't have the technical vocabulary or experience to formulate a rebuttal. Can a dev or someone with intimate knowledge please address this in detail? Here is the post:

The idea of Bitcoin is that anyone who has knowledge of the protocol can log on and determine the correct state of the ledger trustlessly. I ask my peers for the current blockchain and choose the one that is both valid and has the most work.

However, this ideal is not entirely achieved. A block is only valid if its timestamp is close enough to the actual time. This means that malicious miners can confirm blocks with erroneous timestamps, and there would be no way for someone logging on for the first time to detect that this has happened. This is in stark contrast to the case of malicious miners confirming blocks with erroneous transactions, for these erroneous transactions can be detected using only the information internal to the blockchain.

Malicious miners can validate a block with an erroneous timestamp. If they are in the majority, their chain will have the most work. Anyone logging onto the network for the first time will not be able to detect that the time stamps are erroneous. There may be nodes running with no downtime who claim that the time stamps are indeed erroneous, but there is no way to confirm who is telling the truth.

The implication is precisely that the timestamps may have been forged and there is no way to detect this trustlessly. People talk as if blockchains can function as trustless clocks, but this is simply not the case.

[1714608249]

1714608249

[1714608249]

1714608249

[1714608249]

1714608249

[gmaxwell]

Bitcoin's requirement for accurate time is *extremely* loose.  A sundial and an almanac is pretty much sufficient.

People talk as if blockchains can function as trustless clocks, but this is simply not the case.

It's likely that the person you're quoting is confusing multiple different uses of the word 'clock'.

Bitcoin only has a timestamp in it at all to keep the inflation schedule on track and make the infrequently used time-relative locktimes work.  If we didn't care about those features it could just exclude the timestamp entirely-- and it would still be a clock, one that just ticks in the form of blocks.

[xmready]

Bitcoin's requirement for accurate time is *extremely* loose.  A sundial and an almanac is pretty much sufficient.

People talk as if blockchains can function as trustless clocks, but this is simply not the case.

It's likely that the person you're quoting is confusing multiple different uses of the word 'clock'.

Bitcoin only has a timestamp in it at all to keep the inflation schedule on track and make the infrequently used time-relative locktimes work.  If we didn't care about those features it could just exclude the timestamp entirely-- and it would still be a clock, one that just ticks in the form of blocks.

I see, thank you for that insight. But you haven't denied whether these "erroneous" timestamps are possible. So let me ask you directly:

Is it possible for miners to include erroneous timestamps, regardless of how important they are?

If yes, can these timestamps have a negative effect on the inflation schedule or locktimes?

[gmaxwell]

What do you mean by erroneous?

The protocol requires that timestamps be greater than the median of the last 11 blocks and less then 2 hours into the future from your own perspective.  If you get a block more than 2 hours in the future you won't accept it until its within 2 hours.  Any timestamp that passes these criteria is valid, anything else will be ignored.

If yes, can these timestamps have a negative effect on the inflation schedule or locktimes?

Time based locktimes aren't based on the time on the current block anymore, but instead are based on the median of the last 11 blocks (the lowest timestamp the block could have).

The allowed 2 hour difference on the blocks timestamp allows a one time 2hr/2week = 0.5% difference in inflation, -- utterly irrelevant and well below the noise.

[xmready]

What do you mean by erroneous?

The protocol requires that timestamps be greater than the median of the last 11 blocks and less then 2 hours into the future from your own perspective.  If you get a block more than 2 hours in the future you won't accept it until its within 2 hours.  Any timestamp that passes these criteria is valid, anything else will be ignored.

If yes, can these timestamps have a negative effect on the inflation schedule or locktimes?

Time based locktimes aren't based on the time on the current block anymore, but instead are based on the median of the last 11 blocks (the lowest timestamp the block could have).

The allowed 2 hour difference on the blocks timestamp allows a one time 2hr/2week = 0.5% difference in inflation, -- utterly irrelevant and well below the noise.

Once again I have learned something. Happy days, thank you.

[kaggie]

I see, thank you for that insight. But you haven't denied whether these "erroneous" timestamps are possible. So let me ask you directly:

Is it possible for miners to include erroneous timestamps, regardless of how important they are?

If yes, can these timestamps have a negative effect on the inflation schedule or locktimes?

If I remember correctly, the time stamp of a block comes from the average of all of the miners.
If there were only two miners, they could use any forward time stamp that they'd want.
And as gmaxwell said, assuming the average of the miners is correct, the block numbers becomes a near indisputable time stamp for
the transactions that come on chain.. with enough miners and within a small error.

Block chain is one of the few things that can give a near indisputable time stamp.

[ranochigo]

If I remember correctly, the time stamp of a block comes from the average of all of the miners.
If there were only two miners, they could use any forward time stamp that they'd want.
And as gmaxwell said, assuming the average of the miners is correct, the block numbers becomes a near indisputable time stamp for
the transactions that come on chain.. with enough miners and within a small error.

Block chain is one of the few things that can give a near indisputable time stamp.

It doesn't. We consider the median timestamp of the last 11 blocks, and not all of the miners.

There is also the point about network adjusted time, which prevents the timestamp from drifting uncontrollably; nodes wouldn't accept your block if your timestamp deviates too far from the network adjusted time. Even if there were two miners, it doesn't mean that they can set their timestamp arbitrarily. The blockchain doesn't necessarily provides for an indisputable or concrete "timestamp" but rather it provides an environment where you are required to expend far more to re organize the blocks.

[kaggie]

It doesn't. We consider the median timestamp of the last 11 blocks, and not all of the miners.

Cheers

There is also the point about network adjusted time, which prevents the timestamp from drifting uncontrollably; nodes wouldn't accept your block if your timestamp deviates too far from the network adjusted time. Even if there were two miners, it doesn't mean that they can set their timestamp arbitrarily. The blockchain doesn't necessarily provides for an indisputable or concrete "timestamp" but rather it provides an environment where you are required to expend far more to re organize the blocks.

If I understood Maxwell's comment correctly, let's give the hypothetical that there were only two miners on the network, and that they published blocks two years into the future:

Nodes would then wait two years before updating their own records, after their own clocks matched the published blocks, and only if there weren't conflicting blocks published before then. So, there is incentive for miners to be reasonably accurate.

Would that be correct? I've not looked into the code enough yet to know myself.

[pooya87]

If I understood Maxwell's comment correctly, let's give the hypothetical that there were only two miners on the network, and that they published blocks two years into the future:

Nodes would then wait two years before updating their own records, after their own clocks matched the published blocks, and only if there weren't conflicting blocks published before then. So, there is incentive for miners to be reasonably accurate.

Would that be correct? I've not looked into the code enough yet to know myself.

The full node software uses the system clock and will not change it. If it receives a block that is 2 years in the future it will simply reject it as invalid and waits for a valid block without updating anything.
If the computer clock is wrong then the user has to manually fix it before they can continue syncing. If the miners are creating wrong blocks there will always be a miner that won't and the chain will continue to grow with valid blocks.

[BlackHatCoiner]

What happens if you broadcast a signed a transaction at 19:00 using your system's clock, then once is confirmed, broadcast a signed transaction that spends an output from the previous once, but at 18:00. In other words, if you tease your system's clock and any node can confirm that you have, does that make the second transaction invalid?

[kaggie]

What happens if you broadcast a signed a transaction at 19:00 using your system's clock, then once is confirmed, broadcast a signed transaction that spends an output from the previous once, but at 18:00. In other words, if you tease your system's clock and any node can confirm that you have, does that make the second transaction invalid?

Broadcasting a transaction has zero dependency on your computer's system time.
So, no, the later transaction would not overwrite the earlier one, assuming the fee and hashrate was the same.

There is a locktime argument that can be pushed, but that doesn't depend on any user/node clock, but on the blockchain time stamps noted above.
https://hedgetrade.com/what-is-locktime/

Core has interesting behaviors related to your system clock, but that's different than broadcasting a transaction.

If you get a block more than 2 hours in the future you won't accept it until its within 2 hours.  Any timestamp that passes these criteria is valid, anything else will be ignored.

[BlackHatCoiner]

Broadcasting a transaction has zero dependency on your computer's system time.

I didn't said that it has. You can obviously sign whatever you want from scratch. I was just wondering why the second transaction should be considered valid after every node observed that the user is cheating the system.

Could the user also enter an arbitrary time like 01-01-1970? He should, if the timestamp isn't somehow verified.

[kaggie]

Broadcasting a transaction has zero dependency on your computer's system time.

I didn't said that it has. You can obviously sign whatever you want from scratch. I was just wondering why the second transaction should be considered valid after every node observed that the user is cheating the system.

Could the user also enter an arbitrary time like 01-01-1970? He should, if the timestamp isn't somehow verified.

There isn't a time stamp in a transaction broadcast, so it's irrelevant.

The second won't be considered valid because it arrived or was confirmed later.
Once the first transaction is confirmed, the second one will be rejected due to unavailable funds.
This is the double spend problem, right?

https://99bitcoins.com/double-spending/

A transaction broadcast may look like this [note the lack of a timestamp]

Array
(
    [txid] => e3a865d391af57193e4faad75080f3c8178cb696910cc19ea75877f06b9a3598
    [hash] => e3a865d391af57193e4faad75080f3c8178cb696910cc19ea75877f06b9a3598
    [version] => 2
    [size] => 85
    [vsize] => 85
    [weight] => 340
    [locktime] => 0
    [vin] => Array
        (
            

• => Array

               (
                    [txid] => 24e4ccbe8faedc59fa16465e787a0943d5b1b780ab58d00a15a7d7e2390c0edc
                    [vout] => 1
                    [scriptSig] => Array
                        (
                            [asm] =>
                            [hex] =>
                        )

                    [sequence] => 4294967295
                )

        )

    [vout] => Array
        (
            

• => Array

               (
                    [value] => 0.045
                    [n] => 0
                    [scriptPubKey] => Array
                        (
                            [asm] => OP_DUP OP_HASH160 043ea5736aa3a48ebdd5034309b590505d8bdd90 OP_EQUALVERIFY OP_CHECKSIG
                            [hex] => 76a914043ea5736aa3a48ebdd5034309b590505d8bdd9088ac
                            [reqSigs] => 1
                            [type] => pubkeyhash
                            [addresses] => Array
                                (
                                    

• => 1PSkWTzac8K8QGCq17ff27gPw1eHw3gTC

                               )

                        )

                )

        )

)

But you don't need a node to broadcast a transaction..

You need an accurate system time for your node though, or your node won't update properly, which is probably the most common tool for broadcasting transactions.
"To connect to a peer, you send a version message containing your version number, block count, and current time."
https://en.bitcoin.it/wiki/Network

The double spender isn't necessarily trying to cheat the system. There could be several reasons why it happens, such as the replace-by-fee being increased.

[BlackHatCoiner]

...

You probably didn't understand my query, but that's okay, I'll just make it clearer.

• You enter a timestamp that represents the present. (e.g 19:00)
• You sign that transaction and then broadcast it.
• The transaction is successfully included into a block.
• Then you create another transaction with a timestamp that represents a time prior the one that is signed in the previous transaction. (e.g 18:00)
• For that very transaction, you select an output of the first transaction.
• You then sign the second transaction and broadcast it.

My question is:  Should the second transaction be considered valid if everyone can confirm that one of those transactions contains a false timestamp?

[kaggie]

You probably didn't understand my query, but that's okay, I'll just make it clearer.
..
My question is:  Should the second transaction be considered valid if everyone can confirm that one of those transactions contains a false timestamp?

Sorry, I still don't get it.

But no, the second transaction would be shown already as spent and ignored by the miners.
If it didn't behave this way, then the system would be abusable as your hypothetical puts it.

-
Check my edits as I've added more information that might clarify.

There is no time stamp in the sent transaction.
There are timestamps in miner blocks and connecting nodes, but these are not transactions, nor required for an individual to have for making a transaction.
Specific to the transaction, a lock time is not a time stamp, even if it might be used as such.
Specific to the miner, a miner has the incentive to have a near matching time stamp to other miners so that ze can get transaction fees without rejection.

[ranochigo]

My question is:  Should the second transaction be considered valid if everyone can confirm that one of those transactions contains a false timestamp?

No. The timestamp is to be matched with the block that it is in. If your block includes a CLTV with a unix time after that, then it would be valid, if it isn't then it won't be. The validity of the block is also dependent on the deviation from the network adjusted time as well, if it isn't synchronized within the limits, then it would be invalid as well until the time limit reaches. Nodes do not independently decide to invalidate any transactions.

BIP113 introduced MTP for locktime quite a while ago which utilizes the median as compared to the actual block timestamp.

[gmaxwell]

Transactions don't have any timestamp at all.  They may, however, have an nLocktime.

nLocktime can be time based or height based.

If nLocktime is time based it is not based on the current time, it is based on the blockchain's median time past.

A transaction with a time based lock won't be relayed until it can be included in the next block coming up.

[kaggie]

Transactions don't have any timestamp at all.  They may, however, have an nLocktime.

nLocktime can be time based or height based.

If nLocktime is time based it is not based on the current time, it is based on the blockchain's median time past.

A transaction with a time based lock won't be relayed until it can be included in the next block coming up.

Is there anything that prevents a future nLocktime transaction from being used early?

For example, if nLocktime were to be set for 6 months in the future, but a miner wanted to process the transaction now --
then could they republish the transaction with an nLocktime of now or the past?

The hypothetical scenarios would be a donor who wanted to donate significant funds say 10 years after they thought they would be dead,
or an employer that wanted to set the payout to an individual to be on a particular each month for the next 6 months.
They benefit to the donor or employer is that they could change their mind by transacting at an earlier nLocktime.

[DannyHamilton]

Is there anything that prevents a future nLocktime transaction from being used early?

For example, if nLocktime were to be set for 6 months in the future, but a miner wanted to process the transaction now --
then could they republish the transaction with an nLocktime of now or the past?

If you change the transaction, then the signature on the transaction will no longer be valid.  This prevents anyone from changing anything about the transaction (including the amount being paid, the address it's being paid to, and/or the locktime.

[kaggie]

If you change the transaction, then the signature on the transaction will no longer be valid.  This prevents anyone from changing anything about the transaction (including the amount being paid, the address it's being paid to, and/or the locktime.

Thanks. Of course!

Is there a theoretical most distant future locktime that a transaction can have?

I imagine the fee would have to be quite large for miners to want to keep it in the mempool for that amount of time, and then it might become a race to see who could publish it the soonest after the benchmarked time.