<p>Wallet Y won't receive payment until nLockTime condition passed and transaction included into a block. </p>

<p>AFAIK most peers won't relay nlocktime with 1 month in the future.
<a href="https://bitcoin.stackexchange.com/a/26983/12049">https://bitcoin.stackexchange.com/a/26983/12049</a></p>

<p>Once transaction gets included into the blockchain, it can't be undone.</p>

<p>So the second transaction spending B is valid, and the first transaction spending A+B is invalid DOUBLE SPEND!</p>

CC BY-SA 3.0
2016-08-14T13:51:03.703Z
2016-08-14T13:51:03.703Z
2017-04-13T12:47:33.743Z
Farghaly
<p>Since one of the inputs of the <code>nLockTime</code> transaction has been spent already, the <code>nLockTime</code> transaction becomes invalid, as not all referenced inputs are available for spending.</p>

<p>This is <a href="https://bitcoin.org/en/developer-guide#locktime-and-sequence-number" rel="nofollow">described in the Bitcoin developers guide</a> explicitly as a way to cancel a locktime transaction: </p>

<blockquote>
  <p>If any of the signers change their mind, they can create a new non-locktime transaction. The new transaction will use, as one of its inputs, one of the same outputs which was used as an input to the locktime transaction. This makes the locktime transaction invalid if the new transaction is added to the block chain before the time lock expires.</p>
</blockquote>

<p>Before the time or block height specified for the <code>nLockTime</code> transaction is reached, the transaction is considered invalid and will not be stored or relayed by (other) nodes. This has been weakened in 0.9.0 so that transactions one block within <code>nLockTime</code> are accepted for relay but not yet for inclusion. </p>

CC BY-SA 3.0
2016-08-15T16:48:04.230Z
Note that if this behaviour (possibility to early spend) is undesired, for example Lightning Network prevents that by locking the the coins in a (2-of-2 multisig OR 1 timelocked signature) script so that early spending is only possible if both parties agree.
Jannes
CC BY-SA 3.0
2016-08-14T22:42:49.643Z
2016-08-14T22:54:28.707Z
2016-08-14T22:54:28.707Z
Murch
<p>Let's say I have a wallet X with money from 3 unspent outputs (UTXOs) A, B and C.</p>

<p>I make an nlocktime transaction to spend 2 of my 3 UTXOs (A &amp; B) to wallet Y, 1 month in the future, sign it, and give it to someone (actually the owner of wallet Y) so that this person can broadcast it later.</p>

<p>Now, let's say a week later, before the nlocktime's block happens, I go and spend one of the UTXOs of the nlocktime transaction (A), but not the other (B).</p>

<p>Will the person that receives the 1st transaction be able to spend the UTXO B in the end? Or would my 2nd transaction render the entire 1st transaction invalid?</p>

<p>Thanks</p>

<signature><contracts><locktime><checklocktimeverify>
Can you "undo" an nlockTime transaction by spending a single UTXO of it before lockTime's block happens?
knocte
# Can you "undo" an nlockTime transaction by spending a single UTXO of it before lockTime's block happens?

(Asked by: username_0 on 2016-08-14)

Let's say I have a wallet X with money from 3 unspent outputs (UTXOs) A, B and C.

I make an nlocktime transaction to spend 2 of my 3 UTXOs (A & B) to wallet Y, 1 month in the future, sign it, and give it to someone (actually the owner of wallet Y) so that this person can broadcast it later.

Now, let's say a week later, before the nlocktime's block happens, I go and spend one of the UTXOs of the nlocktime transaction (A), but not the other (B).

Will the person that receives the 1st transaction be able to spend the UTXO B in the end? Or would my 2nd transaction render the entire 1st transaction invalid?

Thanks

**Tags:** signature, contracts, locktime, checklocktimeverify


---

## 2 answers

### Answer by username_2 on 2016-08-14. Score: 4 | Accepted answer

Since one of the inputs of the `nLockTime` transaction has been spent already, the `nLockTime` transaction becomes invalid, as not all referenced inputs are available for spending.

This is [described in the Bitcoin developers guide](https://bitcoin.org/en/developer-guide#locktime-and-sequence-number) explicitly as a way to cancel a locktime transaction:

> If any of the signers change their mind, they can create a new non-locktime transaction. The new transaction will use, as one of its inputs, one of the same outputs which was used as an input to the locktime transaction. This makes the locktime transaction invalid if the new transaction is added to the block chain before the time lock expires.

Before the time or block height specified for the `nLockTime` transaction is reached, the transaction is considered invalid and will not be stored or relayed by (other) nodes. This has been weakened in 0.9.0 so that transactions one block within `nLockTime` are accepted for relay but not yet for inclusion.

> **Comments:**
> **username_3**: Note that if this behaviour (possibility to early spend) is undesired, for example Lightning Network prevents that by locking the the coins in a (2-of-2 multisig OR 1 timelocked signature) script so that early spending is only possible if both parties agree.  

---

### Answer by username_1 on 2016-08-14. Score: 1

Wallet Y won't receive payment until nLockTime condition passed and transaction included into a block.

AFAIK most peers won't relay nlocktime with 1 month in the future.
<https://bitcoin.stackexchange.com/a/26983/12049>

Once transaction gets included into the blockchain, it can't be undone.

So the second transaction spending B is valid, and the first transaction spending A+B is invalid DOUBLE SPEND!


---

