Do transactions including CHECKLOCKTIMEVERIFY get mined immediately?

Question

As I understand it, nLockTime prevents transactions from being included in a block, or even relayed. The problem is, if I pre-sign a transaction, and give it to someone, they have no guarantee that I won't invalidate that transaction by spending its inputs somewhere else before the nLockTime enables the transaction I gave them.

If I create a transaction with CHECKLOCKTIMEVERIFY, that gets mined immediately, right?

What is an example CLTV pair of transactions, including the one that sets the condition, and the one that spends it? It would be helpful to see example sequence numbers, transaction nLockTime, CLTV value, and block numbers for the two transactions.

The following question contains the relevant CLTV code:

Why is OP_CHECKLOCKTIMEVERIFY disabled by maximum sequence number?

Here's the OP_CHECKLOCKTIMEVERIFY BIP: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

Answer 1

Taking a stab at answering my own question.

Both the transaction using OP_CHECKLOCKTIMEVERIFY in its output script and the one spending OP_CHECKLOCKTIMEVERIFY can be mined immediately in most cases. The output script will probably be used in a P2SH (pay to script hash) so no one will even know that CLTV is even used--only the hash will be visible.

On to spending that CLTV output...

The goal of CLTV is to lock up funds until a certain time. For instance, I want to have a joint account with a business partner that requires two signatures to spend, but after a certain time the funds are spendable by just one signature (in case one of us disappears).

So I was expecting to see a comparison between the CLTV time and the current block time, but all I found was a comparison to nLockTime:

if (nLockTime > (int64_t)txTo->nLockTime)
        return false;

Traditionally, there's no reason to create a transaction with nLockTime set (non-zero) because that transaction would only be spendable in the future. In the case of a CLTV input past its expiration, I can spend it immediately:

• Create a transaction that sources the CLTV output (that's already been in the block chain for some time).
• Set the nLockTime to the current block time. We're basically using nLockTime to pass in the current block time.
• Set the seq number to something other than the max. This handles a special case where max'd seq numbers allow transactions with nLockTimes set earlier than the current block time to be mined.
• The transaction will pass verification because txTo->nLockTime > nLockTime (the CLTV time in the script).

Note that a transaction with OP_CHECKLOCKTIMEVERIFY in a scriptSig input may have nLockTime set to 0, because it's not using that code path in the script. Many protocols have logic like

spendable with 2 signatures or just 1 signature after x date.

So 2 signature might be used rather than waiting for the date.

For instance: https://api.blockcypher.com/v1/btc/main/txs/7b8846797d9c43c7c89543dda13ad5f8742f0068c56c0fa884692a62fe81a79c?limit=50&includeHex=true has a script with OP_CHECKLOCKTIMEVERIFY, but its nLockTime is 0, and seq is max. (2^32 -1 ).

For reference: locktime and sequence specification: https://bitcoin.org/en/developer-guide#locktime-and-sequence-number