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)
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