2

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?

1 Answer 1

5

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 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.
1
  • Excellent info. Thanks for the reply! Commented Mar 23, 2022 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.