Topic: Can the irregularities in timestamp causes double spending attack (Read 274 times)

Nothing will happen to a timestamp of an unconfirmed transaction because it doesn't contain any timestamps in the first place. Your node may timestamp a transaction as soon as it receives information about the transaction's existence, but this timestamp will be relevant only for your node and in no way affects the actual transaction.

No. But we can safely affirm that transactions written in block 1 occurred before transactions in block 2, regardless of the timestamps put by miners in both of the said blocks.

P.S. If you think of the bitcoin blockchain as a big clock that ticks every ten minutes on average, then you may say that all transactions that constitute a particular tick share a common timestamp. But we only care about the order of these "ticks," not precise timings.

Transactions do not have timestamps. They have a field called nLockTime which dictates the earliest point that transaction can be broadcast and mined, but it is not a timestamp. I can sign a transaction today with an nLockTime of 5 years ago, and I could have signed a transaction 5 years ago with an nLockTime of today.

You can apply the timestamp of a block to all the transactions within that block to tell you the time that those transactions received their first confirmation, accepting of course the caveat we have discussed above that the block timestamp has a range of several hours which it can fall within and still be valid.

So does what happens to the timestamp of an unconfirmed transaction?
And does the timestamp of a block means that each transaction in it are automatically timestamp?

Well, it's just that users don't use the locktime field. And for all practical use cases, knowing that "this transaction was broadcasted at this time or later" is good enough. Of course it is possible to create or broadcast it earlier, but then it will be rejected by default. So, if users put zero in the locktime, it is just that they don't use it, because then such transaction can be included "after block number zero or later".

Both cases are possible in locktime, it is just users can use zero (or any timestamp that is earlier than now) and it will be always included.

In this way, I can conclude that the additions of timestamps are but a mere convenience to the end user. The actual timing from the node's point of view in terms of blocks since the Genesis block, not seconds since the epoch.

The chief aim of presenting consensus in decentralized systems is to agree on the state of the network at any point in time, which in turn constitutes the correct timing and order of transactions. The only working way to achieve such consensus while also maintaining a decent level of decentralization is through competition between miners who are trying to earn the right to add their version of "timing and ordering" to the blockchain. Miners spend energy to find a correct solution to a puzzle they themselves constructed, and, if the solution is successfully found, miners exchange for reward their block with nodes verifying every piece of data they receive. It is these successful miners who will decide which transaction goes after which, but they pay a big price for being able to be a "temporary" decision-maker. Therefore, adding correct timestamps into blockchain is a very expensive business in which you have to actively compete with others in order to stay. If the security of blockchain relied solely on people correctly putting timestamps in their transactions, the blockchain would have already been destroyed because mere adding of timestamps costs virtually nothing to users. Nothing would stop an attacker from adding millions of transactions with the same timestamp, and we would have no way to determine which of them are correct or which of them to add to a block.

Similarly, difficulty adjustments occur every 2,016 blocks rather than every two weeks.

It would be incorrect to say that the inflation rate is time stamp independent, because bitcoin are created at rates based on the difficulty adjustments that use time stamp dependencies.

But I take your point, the inflation rate is explicitly changed every 210,000 blocks, which vary in exact timings, and stating it how I originally did could cause confusion.

Specifically, the block halfing is performed every 210,000 blocks. This may look like 4 years, but  it is actually not, for a variety of reasons. For one thing, if there is a sharp drop in the miners, a majority of them, that is not recovered later, one epoch could take much longer than two weeks and thus the "half-period" will last some weeks longer than 4 years.

I don't think this is true.

The inflation rate (supply inflation) is a function of the current amount of bitcoin in existence and the current block subsidy.

The timestamp has no effect on either the current amount of bitcoin in existence OR the current block subsidy.

Bitcoin's timestamp is used for several purposes:
1) Difficulty retargeting every two weeks.
2) To determine the inflation rate every four years.
3) To ignore miners who are more than two hours out of timestamp sync.
4) To process transactions that have a timing set.

These use broad timepoints and might occur up to two hours earlier or later than you might expect.  Ignore the timestamp in other settings because the timestamp can always be manipulated. Inaccurate settings that result from changes in daylight savings time are why two hours might be considered acceptable.

The question isn't about a timestamp, but 'who transacted first'. The consensus of who has transacted is agreed on about every ten minutes, which is slow enough to build that knowledge. A double spend will not happen within a single block, because that would be very obvious, and ten minutes is enough time for the network to update to not have to question whether the transaction has occurred before.

No. Bitcoin does not use the timestamp to confirm transactions or order blocks. It should only be thought of us a rough indication of the time the block confirmed, usually accurate to around 3 hours.

No. This has happened many times in the past, where blocks have had earlier timestamps than preceding blocks. It does not matter since blocks are ordered based on block height. Each block contains within its header a hash of the previous block's header - this is how blocks are built in to a chain, and is not dependent on the timestamp whatsoever.

Again no, because like blocks themselves, transactions are neither ordered nor confirmed based on the timestamp of the block of their own nLockTime field.

The timestamp of a block has to meet two important criteria: It has to be greater than the median time of the previous 11 blocks and less than the network adjusted time + 2 hours. Therefore, this limits manipulation.

A block can be submitted with a timestamp earlier, later or even of the exact same timestamp as of the previous block.

No, because blocks are normally generated every 10 minutes (on average) and therefore nodes check for double-spending analogously with the order of the transactions they've received in each of these valid blocks, regardless of their timestamp.

As said, block timestamp exists, mainly, to determine difficulty.

No. You shouldn't consider the timestamp to be anywhere near accurate, because it is not meant to be. Bitcoin follows the chain with the longest proof of work (POW). This means that all of the nodes automatically follows the chain with the longest POW, when they receive it. Hence, you have a double spend, or more specifically a 51% attack when an attacker is able to generate a longer chain with more POW, and by including the transaction which spends to another address.

Bitcoin uses the timestamp to determine the validity of certain transactions (nlocktime) and the difficulty increment. Otherwise, every block has its own block height which increases sequentially. In the block creation process, each individual block does not consider the timestamp of the previous block so long as it doesn't deviate too far from the MTP. There is quite a lax tolerance on the time deviation because it isn't possible for every node to be synchronized to the exact same time at the current state.

I have been reading about timestamp in bitcoin. And I have some few questions I would love the forum to help me with.

1. If time stamp can be manipulated or altered regularly doesn't that affect the credibility of its service.

2. If coincidentally (or maybe manipulated), a block's timestamp is later than the previous block, wouldn't that affect the blockchain or the timestamp of the block built on top of it?

3. Wouldn't the irregularities in time stamp results in double spending attack in bitcoin

I am sorry if this questions might have been answered before.