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 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

1 Answer 1


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.

  • 1
    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. Commented Dec 20, 2012 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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