<p>I'm going to only address the first part of your question, as I think the root of your confusion can be addressed there.</p>
<p>Time locking in Bitcoin refers to two related and interacting, but fundamentally distinct concepts:</p>
<ul>
<li>Transactions can have a locktime. This is a per-transaction field (<code>nLockTime</code>) that determines roughly the earliest time or height when that transaction can be included in the chain. A transaction with a locktime in the future is not invalid; it's merely unacceptable for inclusion in the chain until said time passes. Most Bitcoin nodes today do not relay transactions unless they are eligible for mining in the next blocks.</li>
<li>Scripts can enforce a locktime using the <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki" rel="nofollow noreferrer">OP_CHECKLOCKTIMEVERIFY</a> opcode. That opcode requires that the spending transaction of that script have an <code>nLockTime</code> field not below a provided value. <strong>It does not interact directly with the time or height</strong>. All it does is require that the spending transaction restricts <em>itself</em> to the future, and a transaction without such <code>nLockTime</code> is unconditionally invalid and cannot ever be mined. The consequence is of course that this output cannot be spent until said time passes, but the relation is split in two.</li>
</ul>
<p>This separation of the two has a number of advantages. It means that scripts only need to be run once; we don't need to re-run then every time the time/height changes to reevaluate whether they are still valid. It also means transactions cannot invalidate themselves as time passes - once valid (and acceptable to be mined), a transaction cannot become unacceptable unless double-spent.</p>
<p>So the answer to your question depends on <em>how</em> the transaction violates the timelock:</p>
<ul>
<li>If the transaction has a too low <code>nLockTime</code> field, the transaction is just unconditionally invalid.</li>
<li>If the transaction has a correct <code>nLockTime</code> field, but its time hasn't come yet, the transaction isn't eligible for mining or relay, but when it time comes, anyone can broadcast it and get it mined.</li>
</ul>

CC BY-SA 4.0
2022-03-23T20:20:54.260Z
Excellent info. Thanks for the reply!
juan_more_bitcoin
CC BY-SA 4.0
2022-03-23T18:05:11.527Z
2022-04-27T14:46:40.113Z
2022-04-27T14:46:40.113Z
Pieter Wuille
<p><strong>Background</strong></p>
<p>I was reading a bit about Bitcoin time locked transactions within the context of the Lightning Network. One thing that was never explained is what happens when one tries to prematurely spend the output of a timelocked UTXO.</p>
<p><strong>Example</strong></p>
<p>Alice sends 1 BTC to Bob at address B via transaction T, Output 0. But the transaction is timelocked until the blockheight, currently at H, reaches H+100. So to spend T:0, Bob needs two things:</p>
<ol>
<li>The private key corresponding to address B</li>
<li>Sufficient time such that the blockheight reaches H+100.</li>
</ol>
<p>Bob is impatient and tries to spend T:0 when the blockheight H+30. He broadcasts the transaction.</p>
<p><strong>Question</strong></p>
<p><strong>What happens to Bob's transaction?</strong> Do the miners ignore it and validators reject it since H+100 hasn't occurred yet? I had always assumed that's what happens; The transaction is simply discarded.</p>
<p>But in researching the Lightning Network, in which timelocked transactions play a key role, it's not unheard of for a channel peer to try and cheat his partner by broadcasting a timelocked TX from a prior state. It's actually up to the innocent party to see this transaction on the blockchain, and somehow use some of the data that's revealed in that transaction as an input their own penalty transaction. And furthermore, that penalty transaction must execute <em>prior</em> to the timelocked cheat transaction going through. And that's what I don't get. <strong>How does the innocent party even see this rogue transaction attempt if it's already been rejected by the miners and validators?</strong></p>
<p>Or is my assumption that the miners reject transactions that are dependent upon a not-yet-hit timelocked input incorrect?</p>

<script><validation><locktime>
Are attempts to spend from a timelocked UTXO rejected?
juan_more_bitcoin
# Are attempts to spend from a timelocked UTXO rejected?

(Asked by: username_0 on 2022-03-23)

**Background**

I was reading a bit about Bitcoin time locked transactions within the context of the Lightning Network. One thing that was never explained is what happens when one tries to prematurely spend the output of a timelocked UTXO.

**Example**

Alice sends 1 BTC to Bob at address B via transaction T, Output 0. But the transaction is timelocked until the blockheight, currently at H, reaches H+100. So to spend T:0, Bob needs two things:

1. The private key corresponding to address B
2. Sufficient time such that the blockheight reaches H+100.

Bob is impatient and tries to spend T:0 when the blockheight H+30. He broadcasts the transaction.

**Question**

**What happens to Bob's transaction?** Do the miners ignore it and validators reject it since H+100 hasn't occurred yet? I had always assumed that's what happens; The transaction is simply discarded.

But in researching the Lightning Network, in which timelocked transactions play a key role, it's not unheard of for a channel peer to try and cheat his partner by broadcasting a timelocked TX from a prior state. It's actually up to the innocent party to see this transaction on the blockchain, and somehow use some of the data that's revealed in that transaction as an input their own penalty transaction. And furthermore, that penalty transaction must execute *prior* to the timelocked cheat transaction going through. And that's what I don't get. **How does the innocent party even see this rogue transaction attempt if it's already been rejected by the miners and validators?**

Or is my assumption that the miners reject transactions that are dependent upon a not-yet-hit timelocked input incorrect?

**Tags:** script, validation, locktime


---

## 1 answers

### Answer by username_1 on 2022-03-23. Score: 5 | Accepted answer

I'm going to only address the first part of your question, as I think the root of your confusion can be addressed there.

Time locking in Bitcoin refers to two related and interacting, but fundamentally distinct concepts:

* Transactions can have a locktime. This is a per-transaction field (`nLockTime`) that determines roughly the earliest time or height when that transaction can be included in the chain. A transaction with a locktime in the future is not invalid; it's merely unacceptable for inclusion in the chain until said time passes. Most Bitcoin nodes today do not relay transactions unless they are eligible for mining in the next blocks.
* Scripts can enforce a locktime using the [OP\_CHECKLOCKTIMEVERIFY](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) opcode. That opcode requires that the spending transaction of that script have an `nLockTime` field not below a provided value. **It does not interact directly with the time or height**. All it does is require that the spending transaction restricts *itself* to the future, and a transaction without such `nLockTime` is unconditionally invalid and cannot ever be mined. The consequence is of course that this output cannot be spent until said time passes, but the relation is split in two.

This separation of the two has a number of advantages. It means that scripts only need to be run once; we don't need to re-run then every time the time/height changes to reevaluate whether they are still valid. It also means transactions cannot invalidate themselves as time passes - once valid (and acceptable to be mined), a transaction cannot become unacceptable unless double-spent.

So the answer to your question depends on *how* the transaction violates the timelock:

* If the transaction has a too low `nLockTime` field, the transaction is just unconditionally invalid.
* If the transaction has a correct `nLockTime` field, but its time hasn't come yet, the transaction isn't eligible for mining or relay, but when it time comes, anyone can broadcast it and get it mined.

> **Comments:**
> **username_0**: Excellent info. Thanks for the reply!  

---

