<p>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 <strong>block level</strong>.</p>
<p>So, even if in reality chronologically earlier transaction comes later, it will be included into the next block if current block if full. <strong>Low fee transactions mostly experience this</strong>.</p>
<p><strong>Imagine Alice is paying Bob</strong></p>
<p>Alice puts a <strong>timelock</strong> on the transaction,</p>
<ul>
<li>Time locks are a <strong>transaction level encumbrance</strong>. That is, the transaction is invalid and not propagated if it did not age past it's locktime.</li>
<li>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 <strong>timelock</strong>, 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.</li>
</ul>
<p>Bob asks Alice to use <strong>CheckLockTimeVerify</strong>,</p>
<ul>
<li>CLTV is a <strong>UTXO level encumbrance</strong>. 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.</li>
<li>So if Bob wants to spend that UTXO, he has to create a transaction referencing that UTXO <strong>and have timelock value greater than or equal to CLTV value on UTXO</strong>.</li>
</ul>
<p>This way, Alice has paid(sent UTXO) to Bob and Bob can be sure that he isn't going to get an invalid transaction.</p>

CC BY-SA 4.0
2021-10-13T05:34:39.477Z
2021-10-13T05:34:39.477Z
Pranay Reddy
<p>If I undestend the your question, you referer to the lockTime inside the  transaction and not the block timestamp.</p>
<p>The lockTime is a int value, and this value rappresent &quot;When the transaction can be unlockd to an inputs&quot; and not &quot;When the transaction was published&quot;</p>
<p>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:</p>
<ul>
<li>Lock time = 0: the transaction is propagated and executed at the instant of
creation.</li>
<li>0 &lt; LockTime &lt;= 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.</li>
<li>Lock time&gt; 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.</li>
</ul>
<p>If you mean if the transaction has a timestamp, the answer is two:</p>
<ul>
<li><p>Within the structure the transaction does not have a timestamp, but
rather a lock time.</p>
</li>
<li><p>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.</p>
</li>
</ul>
<p>A real use case:
  My <a href="https://blockstream.info/tx/05985072bbe20747325e69a159fe08176cc1bbc96d25e8848edad2dddc1165d0" rel="nofollow noreferrer">transaction</a> has a block timestamp equal to <strong>8/23/2019, 2:08:43 PM GMT + 2</strong>, 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.</p>
<p>No one excuses that my transaction before the block was published was ALSO inside some other block with a slightly different timestamp</p>
<p>If you want have turned a detailed explanation of what and how a transaction works, I recommend this reading on <a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc" rel="nofollow noreferrer">bitcoin book</a></p>
<h2>Update from Bitcoin Dev</h2>
<p>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</p>
<blockquote>
<p>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.</p>
</blockquote>

CC BY-SA 4.0
2019-08-23T12:45:39.900Z
So transactions don't have a timestamp?
evannemo
CC BY-SA 4.0
2019-08-23T12:46:53.063Z
No, the block has the timestamp and it defines when the miner starts the cryptographic challenge
vincenzopalazzo
CC BY-SA 4.0
2019-08-23T12:47:58.400Z
I thought the cryptographic challenge happened before the block was added and once it is done, the block is actually added.
evannemo
CC BY-SA 4.0
2019-08-23T12:48:24.450Z
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 :)
vincenzopalazzo
CC BY-SA 4.0
2019-08-23T12:49:24.810Z
You got me confused. ( :P )
evannemo
CC BY-SA 4.0
2019-08-23T12:50:59.677Z
So a block can store a "future" transaction? that is mined but not actually calculated?
evannemo
CC BY-SA 4.0
2019-08-23T12:58:52.830Z
The block stores a "future" transaction, because neither the block nor the transaction are actually verified and published, that is the work of the miner, who creates a block with the new transactions inside, solves the cryptographic challenge and publishes the block, I have added a real example to my answer
vincenzopalazzo
CC BY-SA 4.0
2019-08-23T13:01:01.043Z
is this a kind of a state? the blockchain saves the locktime block after block and reduces it to 0 and then executes it?
evannemo
CC BY-SA 4.0
2019-08-23T13:10:41.757Z
I don't understand, this "the blockchain saves the locktime block after block and reduces it to 0 and then "
vincenzopalazzo
CC BY-SA 4.0
2019-08-23T13:12:58.373Z
I mean if the transaction is programmed to happen in 1/1/2030, will then every block include it until 1/1/2030?
evannemo
CC BY-SA 4.0
2019-08-23T13:15:07.460Z
The lock time can be seen as a state, yes, the status of the transaction in my example is immediate, ie "as soon as possible". but do not confuse the timestamp with the locktime, the timestamp only indicates the age of the block, like a date of birth.
vincenzopalazzo
CC BY-SA 4.0
2019-08-23T13:16:30.543Z
@evannemo No, the transaction will only be published in the first available block, but can only be spent after 1/1/2030
vincenzopalazzo
CC BY-SA 4.0
2019-08-23T13:20:39.363Z
All right! My question is, if two transactions are about to spent once they are published (locktime = 0), but Y is included on the current block and X on the next, even though X was broadcasted first to the network, doesn't this create problems?
evannemo
CC BY-SA 4.0
2019-08-23T13:35:25.700Z
What problems are you talking about? before answering, I would like to have an example of a complete use case
vincenzopalazzo
CC BY-SA 4.0
2019-08-23T13:36:36.230Z
For example, The transaction Y could be spent before X, even though X was broadcasted first.
evannemo
CC BY-SA 4.0
2019-08-23T13:38:53.363Z
Absolutly yes, A transaction is not spent at the time of publication, but the newly published transaction spends a transaction already present on the blockchain called the comunemenete UTXO, I added an excellent reading to my answer, you will have answers to all your doubts
vincenzopalazzo
CC BY-SA 4.0
2021-05-14T23:38:08.803Z
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.
Pieter Wuille
CC BY-SA 4.0
2021-05-15T22:59:02.993Z
Ops! All the information inside my answer are wrong, but I can not remember what I try to explaining here. Fortunately, My English evolved and I need to rewrite this answer, but before I need to make backtracking to find what I described here. For the moment I added an alert in the post, and again Thanks to ping me @PieterWuille.
vincenzopalazzo
CC BY-SA 4.0
2019-08-23T12:40:32.467Z
2021-05-15T22:46:29.667Z
2021-05-15T22:46:29.667Z
vincenzopalazzo
<p>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.</p>

<p>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?</p>

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

<p>Thanks in advance for your answers!</p>

<transactions><mining-theory><unconfirmed-transactions><network><nodes>
A question about transaction broadcasting and block creation
evannemo
# A question about transaction broadcasting and block creation

(Asked by: username_0 on 2019-08-23)

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!

**Tags:** transactions, mining-theory, unconfirmed-transactions, network, nodes


---

## 2 answers

### Answer by username_1 on 2021-10-13. Score: 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.


---

### Answer by username_2 on 2019-08-23. Score: 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](https://blockstream.info/tx/05985072bbe20747325e69a159fe08176cc1bbc96d25e8848edad2dddc1165d0) 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](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc)

## Update from Bitcoin Dev

In the comment, username_3 username_3 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.

> **Comments:**
> **username_0**: So transactions don't have a timestamp?  
> **username_2**: No, the block has the timestamp and it defines when the miner starts the cryptographic challenge  
> **username_0**: I thought the cryptographic challenge happened before the block was added and once it is done, the block is actually added.  
> **username_2**: 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 :)  
> **username_0**: You got me confused. ( :P )  
> **username_0**: So a block can store a "future" transaction? that is mined but not actually calculated?  
> **username_2**: The block stores a "future" transaction, because neither the block nor the transaction are actually verified and published, that is the work of the miner, who creates a block with the new transactions inside, solves the cryptographic challenge and publishes the block, I have added a real example to my answer  
> **username_0**: is this a kind of a state? the blockchain saves the locktime block after block and reduces it to 0 and then executes it?  
> **username_2**: I don't understand, this "the blockchain saves the locktime block after block and reduces it to 0 and then "  
> **username_0**: I mean if the transaction is programmed to happen in 1/1/2030, will then every block include it until 1/1/2030?  
> **username_2**: The lock time can be seen as a state, yes, the status of the transaction in my example is immediate, ie "as soon as possible". but do not confuse the timestamp with the locktime, the timestamp only indicates the age of the block, like a date of birth.  
> **username_2**: @username_0 No, the transaction will only be published in the first available block, but can only be spent after 1/1/2030  
> **username_0**: All right! My question is, if two transactions are about to spent once they are published (locktime = 0), but Y is included on the current block and X on the next, even though X was broadcasted first to the network, doesn't this create problems?  
> **username_2**: What problems are you talking about? before answering, I would like to have an example of a complete use case  
> **username_0**: For example, The transaction Y could be spent before X, even though X was broadcasted first.  
> **username_2**: Absolutly yes, A transaction is not spent at the time of publication, but the newly published transaction spends a transaction already present on the blockchain called the comunemenete UTXO, I added an excellent reading to my answer, you will have answers to all your doubts  
> **username_3**: 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.  
> **username_2**: Ops! All the information inside my answer are wrong, but I can not remember what I try to explaining here. Fortunately, My English evolved and I need to rewrite this answer, but before I need to make backtracking to find what I described here. For the moment I added an alert in the post, and again Thanks to ping me @username_3.  

---

