2

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.

Wondering
  • 21
  • 1

2 Answers2

4

Background info:

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 and replace-by-fee.

Community
  • 1
morsecoder
  • 14,168
  • 2
  • 42
  • 94
  • 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 Apr 22 '15 at 07:50
0

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

Nick ODell
  • 29,396
  • 11
  • 72
  • 130