<p>Background info:</p>

<ul>
<li><a href="https://bitcoin.stackexchange.com/questions/899/in-a-double-spend-attempt-how-is-the-valid-transaction-chosen">In a double spend attempt, how is the valid transaction chosen?</a></li>
</ul>

<p>As Nick mentioned, transaction replacement using nLockTime and the sequence numbers isn't currently enabled by the network. In practice, this means that any transactions with an nLockTime in the future and at least one input with non-max sequence number won't be broadcasted because it is not a 'final' transaction. </p>

<p>So, if you:</p>

<ul>
<li>broadcast TX1 with nLockTime 3 days in the future and then TX2 with nLockTime 2 days in the future, neither will be propagated by the network.</li>
<li>broadcast TX1 with nLockTime 3 days in the future and then TX2 with nLockTime not in effect (or in the past), TX2 will be accepted and broadcasted even though it wasn't the first TX spending its input.</li>
</ul>

<p>Essentially, the network 'accepts' the first <strong>final</strong> (ready for inclusion in a block) transaction spending that input that it sees. There are some proposals to alter this method, such as <a href="https://github.com/bitcoinxt/bitcoinxt" rel="nofollow noreferrer">relay-first-double-spend</a> and <a href="https://bitcoin.stackexchange.com/questions/10733/what-is-replace-by-fee">replace-by-fee</a>.</p>

CC BY-SA 3.0
2015-04-22T07:50:55.243Z
Although this is what the standard bitcoin core does, it is not something you can rely on. You have no control over what other people do so you should assume worst case (which probably means there's no point in doing it at all). For example if the transaction contains a high fee it might be worth while for a miner to hold onto it until the (earliest) locktime expires and try to mine it asap.
Jannes
CC BY-SA 3.0
2015-04-22T02:56:47.473Z
2015-04-22T02:56:47.473Z
2017-04-13T12:47:33.610Z
morsecoder
<p>I don't think transaction replacement is enabled, so it would be the transaction that was accepted first.</p>

CC BY-SA 3.0
2015-04-22T01:12:32.120Z
2015-04-22T01:12:32.120Z
Nick ODell
<p>What happens if I broadcast two nLockTime transactions with different nLockTime but same input?</p>

<p>Is the smallest nLockTime going to be accepted or is it the tx that reaches the network the fastest that will be accepted.</p>

<bitcoind>
2 nLockTime TXs with same input
Wondering
# 2 nLockTime TXs with same input

(Asked by: username_0 on 2015-04-22)

What happens if I broadcast two nLockTime transactions with different nLockTime but same input?

Is the smallest nLockTime going to be accepted or is it the tx that reaches the network the fastest that will be accepted.

**Tags:** bitcoind


---

## 2 answers

### Answer by username_1 on 2015-04-22. Score: 4

Background info:

* [In a double spend attempt, how is the valid transaction chosen?](https://bitcoin.stackexchange.com/questions/899/in-a-double-spend-attempt-how-is-the-valid-transaction-chosen)

As Nick mentioned, transaction replacement using nLockTime and the sequence numbers isn't currently enabled by the network. In practice, this means that any transactions with an nLockTime in the future and at least one input with non-max sequence number won't be broadcasted because it is not a 'final' transaction.

So, if you:

* broadcast TX1 with nLockTime 3 days in the future and then TX2 with nLockTime 2 days in the future, neither will be propagated by the network.
* broadcast TX1 with nLockTime 3 days in the future and then TX2 with nLockTime not in effect (or in the past), TX2 will be accepted and broadcasted even though it wasn't the first TX spending its input.

Essentially, the network 'accepts' the first **final** (ready for inclusion in a block) transaction spending that input that it sees. There are some proposals to alter this method, such as [relay-first-double-spend](https://github.com/bitcoinxt/bitcoinxt) and [replace-by-fee](https://bitcoin.stackexchange.com/questions/10733/what-is-replace-by-fee).

> **Comments:**
> **username_2**: Although this is what the standard bitcoin core does, it is not something you can rely on. You have no control over what other people do so you should assume worst case (which probably means there's no point in doing it at all). For example if the transaction contains a high fee it might be worth while for a miner to hold onto it until the (earliest) locktime expires and try to mine it asap.  

---

### Answer by username_3 on 2015-04-22. Score: 0

I don't think transaction replacement is enabled, so it would be the transaction that was accepted first.


---

