<p>I just encountered the same problem and the solution is almost stupid. Since the hint is not found elsewhere, I'd add my two cents in case others stepped upon the same trap. </p>

<p>It turns out that, besides the usual reasons related to time (e.g., time lock hasn't expired, the sequence number is not properly set etc.), trying to spend an unconfirmed UTXO also causes <code>non-final</code> error. I didn't dig into the source code to see why this happens, but the misleading error message cost me a good afternoon.</p>

<p>Why would you ever attempt to spend unconfirmed outputs? Well, when you're busy testing things out and are gradually losing ur patience...</p>

CC BY-SA 4.0
2019-01-16T03:05:06.350Z
If this is true, it's a bug. Finality has nothing to do with confirmed or not.
Pieter Wuille
CC BY-SA 4.0
2019-01-16T03:16:20.373Z
@PieterWuille yep it can be reliably reproduced on Bitcoin Core v0.17.1.0-gef70f9b52b851c7997a9f1a0834714e3eebc1fd8. Is GitHub issue the preferred way to report?
qweruiop
CC BY-SA 4.0
2019-01-16T03:56:04.497Z
Yes, please. I wonder what condition triggers it. Spending unconfirmed outputs is an intended features, and there are several tests for it.
Pieter Wuille
CC BY-SA 4.0
2019-01-16T02:52:16.580Z
2019-01-16T02:52:16.580Z
qweruiop
<p>I have created raw transaction with <code>locktime</code> and sign it. The lock time is already passed but still got error like this when <code>sendrawtransaction</code></p>

<blockquote>
  <p>64: non-final txid</p>
</blockquote>

<p>the locktime value is 1523515709 .
and here hex transaction after sign if anyone willing to check it, I created with testnet BTC. How to fix it ?</p>

<pre><code>02000000031e86fe4a8edf79ec3de22ab4208e9285bc55414c3b57053258e70651ee59ee85000000006b483045022100ecf1b03bf565358ebf25c5b2a1cf8a7f9bb6f6629c3fe12dbeb76b94e7d3f1ba02201d77ac1ba3092f90e360551fa3ac03cacda97c9d7d490e33e93248c76d5ee874012103155badc49210d2fabc6ce4d3ad10031437214404550ff7ef92d99e603f71fd16feffffff39994c9f8f0109f0e4c66fe5206dedc9844249cbff373ecd99def0903d36dcbc000000006b483045022100a68935c9df63462c1a4637aa3c63170c4dc396dbb2da67337d1937836148b51502201e1e294cfad8b393c35fb8405c72ee9e46f9495b86019b03760cdde06cf8a9ed012103155badc49210d2fabc6ce4d3ad10031437214404550ff7ef92d99e603f71fd16feffffff6c81ebda296a42ff4215b3b14055dc3d42d382cceefd118e229512aa1b88eb75020000006a473044022011ae505b77a67a41a3f1ee99b378493f9f5739ba5522ce6a1659cfb2ef129fd80220589d24a28593be57319e9dd058f08ce2ace74ccd3d3ab0edf81487878895f682012103155badc49210d2fabc6ce4d3ad10031437214404550ff7ef92d99e603f71fd16feffffff0302ca9700000000001976a914dc1ded71f0c85710f65b3426137e2d4a5784eed588ac50c30000000000001976a9141ca93028446df6bd23778047417c8447ceb4ab3488ace0533104000000001976a914f084173109b9547db4781e8e1a3a52a0cc709d9888ac3d01cf5a
</code></pre>

CC BY-SA 3.0
2018-04-12T17:04:34.280Z
Looks like a timelock issue. Have you managed to get it though?
sr_gi
CC BY-SA 3.0
2018-04-13T06:51:16.367Z
Locktime in (reversed) hex 3D01CF5A is 1523515709 decimal, which is >= 500mio, so it is a time stamp (date -r 1523515709 --> 12Apr2018). This is roughly when you posted the question. Sure it has passed? Have you tried to change to "00000000", and see if error remains? Error might also indicate n issue with the signature, as it is a multisig tx (though I can see all three signatures).
pebwindkraft
CC BY-SA 4.0
2019-01-16T03:55:09.040Z
@pebwindkraft What is mio?
Pieter Wuille
CC BY-SA 4.0
2019-07-01T15:55:36.757Z
500mio is five hundred millions... based on here: https://bitcoin.org/en/transactions-guide#locktime-and-sequence-number: "Locktime itself is an unsigned 4-byte integer which can be parsed two ways ...". basically, if greater than 500mio it is interpreted as unix epoche time, if less than 500mio, then block height.
pebwindkraft
<bitcoind><sendrawtransaction>
Sendrawtransaction error with locktime : 64: non-final txid
Billy Adelphia
# Sendrawtransaction error with locktime : 64: non-final txid

(Asked by: username_0 on 2018-04-12)

I have created raw transaction with `locktime` and sign it. The lock time is already passed but still got error like this when `sendrawtransaction`

> 64: non-final txid

the locktime value is 1523515709 .
and here hex transaction after sign if anyone willing to check it, I created with testnet BTC. How to fix it ?

```
02000000031e86fe4a8edf79ec3de22ab4208e9285bc55414c3b57053258e70651ee59ee85000000006b483045022100ecf1b03bf565358ebf25c5b2a1cf8a7f9bb6f6629c3fe12dbeb76b94e7d3f1ba02201d77ac1ba3092f90e360551fa3ac03cacda97c9d7d490e33e93248c76d5ee874012103155badc49210d2fabc6ce4d3ad10031437214404550ff7ef92d99e603f71fd16feffffff39994c9f8f0109f0e4c66fe5206dedc9844249cbff373ecd99def0903d36dcbc000000006b483045022100a68935c9df63462c1a4637aa3c63170c4dc396dbb2da67337d1937836148b51502201e1e294cfad8b393c35fb8405c72ee9e46f9495b86019b03760cdde06cf8a9ed012103155badc49210d2fabc6ce4d3ad10031437214404550ff7ef92d99e603f71fd16feffffff6c81ebda296a42ff4215b3b14055dc3d42d382cceefd118e229512aa1b88eb75020000006a473044022011ae505b77a67a41a3f1ee99b378493f9f5739ba5522ce6a1659cfb2ef129fd80220589d24a28593be57319e9dd058f08ce2ace74ccd3d3ab0edf81487878895f682012103155badc49210d2fabc6ce4d3ad10031437214404550ff7ef92d99e603f71fd16feffffff0302ca9700000000001976a914dc1ded71f0c85710f65b3426137e2d4a5784eed588ac50c30000000000001976a9141ca93028446df6bd23778047417c8447ceb4ab3488ace0533104000000001976a914f084173109b9547db4781e8e1a3a52a0cc709d9888ac3d01cf5a

```

**Tags:** bitcoind, sendrawtransaction

> **Comments:**
> **username_1**: Looks like a timelock issue. Have you managed to get it though?  
> **username_2**: Locktime in (reversed) hex 3D01CF5A is 1523515709 decimal, which is >= 500mio, so it is a time stamp (date -r 1523515709 --> 12Apr2018). This is roughly when you posted the question. Sure it has passed? Have you tried to change to "00000000", and see if error remains? Error might also indicate n issue with the signature, as it is a multisig tx (though I can see all three signatures).  
> **username_3**: @username_2 What is mio?  
> **username_2**: 500mio is five hundred millions... based on here: https://bitcoin.org/en/transactions-guide#locktime-and-sequence-number: "Locktime itself is an unsigned 4-byte integer which can be parsed two ways ...". basically, if greater than 500mio it is interpreted as unix epoche time, if less than 500mio, then block height.  

---

## 1 answers

### Answer by username_4 on 2019-01-16. Score: 1

I just encountered the same problem and the solution is almost stupid. Since the hint is not found elsewhere, I'd add my two cents in case others stepped upon the same trap.

It turns out that, besides the usual reasons related to time (e.g., time lock hasn't expired, the sequence number is not properly set etc.), trying to spend an unconfirmed UTXO also causes `non-final` error. I didn't dig into the source code to see why this happens, but the misleading error message cost me a good afternoon.

Why would you ever attempt to spend unconfirmed outputs? Well, when you're busy testing things out and are gradually losing ur patience...

> **Comments:**
> **username_3**: If this is true, it's a bug. Finality has nothing to do with confirmed or not.  
> **username_4**: @username_3 yep it can be reliably reproduced on Bitcoin Core v0.17.1.0-gef70f9b52b851c7997a9f1a0834714e3eebc1fd8. Is GitHub issue the preferred way to report?  
> **username_3**: Yes, please. I wonder what condition triggers it. Spending unconfirmed outputs is an intended features, and there are several tests for it.  

---

