0

Let's say we have transaction X and transaction Y. The timestamp of X is chronologically earlier than that of Y. X's spender broadcasts X to the network and the same goes for Y's spender.

Let's say that miners receive Y first and they add it to the next block, which reaches the max number of stored transactions. Will X be included to the block after this one? Will it be discarded?

If X will be included to the block after this one, isn't it a problem that it happened before Y?

Thanks in advance for your answers!

2

A transaction itself doesn't have a storage structure for timestamp. So the transactions don't know when they're created. But, after bundling the transactions into a block and while solving the hash problem to solve the block, the miner inserts timestamp at the block level.

So, even if in reality chronologically earlier transaction comes later, it will be included into the next block if current block if full. Low fee transactions mostly experience this.

Imagine Alice is paying Bob

Alice puts a timelock on the transaction,

  • Time locks are a transaction level encumbrance. That is, the transaction is invalid and not propagated if it did not age past it's locktime.
  • But know that the UTXO the locktime transaction is spending(referencing) is free to be used. So, while Alice shows Bob that the transaction is under timelock, Alice can meanwhile spend the referenced UTXO and make that timelocked transaction invalid after it becomes ready to be propagated(past timelock) and Bob is scammed one could say.

Bob asks Alice to use CheckLockTimeVerify,

  • CLTV is a UTXO level encumbrance. So the transaction from Alice will go through as valid and a UTXO is added to Bob's UTXO set. That UTXO is spendable only after the time specified in UTXO has elapsed.
  • So if Bob wants to spend that UTXO, he has to create a transaction referencing that UTXO and have timelock value greater than or equal to CLTV value on UTXO.

This way, Alice has paid(sent UTXO) to Bob and Bob can be sure that he isn't going to get an invalid transaction.

0

If I undestend the your question, you referer to the lockTime inside the transaction and not the block timestamp.

The lockTime is a int value, and this value rappresent "When the transaction can be unlockd to an inputs" and not "When the transaction was published"

Lock time: Defines the first instant in which the transaction is considered valid and can be transmitted on the Bitcoin network, represented by an integer value between 0 and 500 million, assuming different meanings based on the value assigned, that is:

  • Lock time = 0: the transaction is propagated and executed at the instant of creation.
  • 0 < LockTime <= 500: the value is interpreted as a block height, ie the transaction will be valid only after the block with height equal to the lock time value has been published.
  • Lock time> 500 million: the value is interpreted as a unix timestamp and therefore the transaction will be valid only after the date represented by the lock time value.

If you mean if the transaction has a timestamp, the answer is two:

  • Within the structure the transaction does not have a timestamp, but rather a lock time.

  • The transaction could have an insertion moment in the block, which depends on the block, because it is he who holds the timestamp as a value.

A real use case:   My transaction has a block timestamp equal to 8/23/2019, 2:08:43 PM GMT + 2, this represents the time in which the miner started the cryptographic challenge, and it is the instant in which the miner has also taken into consideration my transaction including it in the block. My transaction has a lockTime of 0 because it is an immediate execution transaction.

No one excuses that my transaction before the block was published was ALSO inside some other block with a slightly different timestamp

If you want have turned a detailed explanation of what and how a transaction works, I recommend this reading on bitcoin book

Update from Bitcoin Dev

In the comment, Pieter Wuille in the comment below post the following answer and explain that my answer is wrong, and a very precise answer is reported below

The nLockTime of a transaction determines the earliest possible time it can be included in a block. It is illegal to have a block which includes a transaction whose locktime has not passed yet. There are however mechanisms to forcing a transaction output to be only be spendable with a future transaction which has a certain locktime - the net effect being that this output can be included on chain, but transactions spending it cannot until such time passes.

18
  • So transactions don't have a timestamp?
    – evannemo
    Aug 23 '19 at 12:45
  • No, the block has the timestamp and it defines when the miner starts the cryptographic challenge Aug 23 '19 at 12:46
  • I thought the cryptographic challenge happened before the block was added and once it is done, the block is actually added.
    – evannemo
    Aug 23 '19 at 12:47
  • The transactions are published in the block timestamp because all the data structure exists from the moment of publication and in the centuries to come :) Aug 23 '19 at 12:48
  • 2
    There are mistakes here. The nLockTime of a transaction determines the earliest possible time it can be included in a block. It is illegal to have a block which includes a transaction whose locktime has not passed yet. There are however mechanisms to forcing a transaction output to be only be spendable with a future transaction which has a certain locktime - the net effect being that this output can be included on chain, but transactions spending it cannot until such time passes. May 14 at 23:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.