<p>The nLockTime is the earliest time that a miner can include that transaction in a block.  It does not mean the exact time that both parties can assume final settlement has occurred.</p>

<p>You are correct to conclude that there is the potential for another transaction (with nLockTime = 0) to be broadcast and be in competition at the same time as the 
original nLockTime > 0) transaction.</p>

<p>But it wouldn't necessarily be a double spend, as the transaction seen later with the nLockTime = 0 would have had to have been signed by both parties.</p>

<p>If a "double spend" scenario occurs, it wouldn't be a surprise to either party.</p>

<p>The situation can occur where the two parties believe the nLockTime = 0 transaction will be the one confirmed and for whatever reason it doesn't get confirmed fast enough.  Instead then at the original transaction's nLockTime (roughly, as there is a couple hour leeway available to the miner as far as timestamp goes) that transaction confirms and thus the transaction submitted later (where nLockTime = 0) will never confirm.</p>

<p>So the normal confirmation level threshold (e.g., six confirmations) still applies to these transactions as far as final settlement goes.</p>

CC BY-SA 3.0
2012-12-20T21:43:39.340Z
That is a good explanation of how the trailing time of the transaction would go.  I assume the transaction start would have to wait 6 confirmations and subject to all normal race conditions in this case.
makerofthings7
CC BY-SA 3.0
2012-12-20T21:12:10.877Z
2012-12-20T21:20:17.960Z
2012-12-20T21:20:17.960Z
Stephen Gornick
<p>Anytime a transaction has a timestamp attached to it, and there are signed but not submitted transactions at play, shouldn't the holder of the non-submitted tx have to take into account the confirmations w.r.t. the expiration time?</p>

<p>Namely in <a href="http://en.bitcoin.it/wiki/Contracts" rel="nofollow">example 7 of this wiki page on contracts</a> I would think that if the AP waits until nearly midnight (almost when the tx expires) then there is a possibility of a double spend and the AP may not get paid.  That means the AP would have to submit the tx 6 confirmations early... almost one hour.</p>

<ul>
<li><p>Is this a correct understanding of locktime in relation to double spend attacks?</p></li>
<li><p>How should this be handled when the network is rapidly increasing in block generation (and difficulty hasn't been adjusted)?  This is happening now with the GPU-> ASIC conversion</p></li>
</ul>

<doublespend><timestamp><contracts><locktime>
In a given contract, should the "LockTime" timestamp include an extra hour for confirmations to prevent a double spend?
makerofthings7
# In a given contract, should the "LockTime" timestamp include an extra hour for confirmations to prevent a double spend?

(Asked by: username_0 on 2012-12-20)

Anytime a transaction has a timestamp attached to it, and there are signed but not submitted transactions at play, shouldn't the holder of the non-submitted tx have to take into account the confirmations w.r.t. the expiration time?

Namely in [example 7 of this wiki page on contracts](http://en.bitcoin.it/wiki/Contracts) I would think that if the AP waits until nearly midnight (almost when the tx expires) then there is a possibility of a double spend and the AP may not get paid. That means the AP would have to submit the tx 6 confirmations early... almost one hour.

* Is this a correct understanding of locktime in relation to double spend attacks?
* How should this be handled when the network is rapidly increasing in block generation (and difficulty hasn't been adjusted)? This is happening now with the GPU-> ASIC conversion

**Tags:** doublespend, timestamp, contracts, locktime


---

## 1 answers

### Answer by username_1 on 2012-12-20. Score: 1 | Accepted answer

The nLockTime is the earliest time that a miner can include that transaction in a block. It does not mean the exact time that both parties can assume final settlement has occurred.

You are correct to conclude that there is the potential for another transaction (with nLockTime = 0) to be broadcast and be in competition at the same time as the
original nLockTime > 0) transaction.

But it wouldn't necessarily be a double spend, as the transaction seen later with the nLockTime = 0 would have had to have been signed by both parties.

If a "double spend" scenario occurs, it wouldn't be a surprise to either party.

The situation can occur where the two parties believe the nLockTime = 0 transaction will be the one confirmed and for whatever reason it doesn't get confirmed fast enough. Instead then at the original transaction's nLockTime (roughly, as there is a couple hour leeway available to the miner as far as timestamp goes) that transaction confirms and thus the transaction submitted later (where nLockTime = 0) will never confirm.

So the normal confirmation level threshold (e.g., six confirmations) still applies to these transactions as far as final settlement goes.

> **Comments:**
> **username_0**: That is a good explanation of how the trailing time of the transaction would go.  I assume the transaction start would have to wait 6 confirmations and subject to all normal race conditions in this case.  

---

