Now that is a cool factoid. So the on chain way locks the utxo ‘mid-transaction’ and the other way merely schedules a transaction? How does the plumbing work?
Discussion
Basically the locking is done by requiring a certain block depth as well as a signature from the address your sending to. This means that any transaction that tries to spend that coin prematurely is invalid because it violates the condition you wrote when sending it.
The second one works by writing a transaction that itself is invalid until a certain block height.
The difference between the 2 is that the former will go on the chain now, meaning the coins are spent now but locked in place until that future date. The latter does not go on chain. It can't be mined until that future date. This means that you can still spend the bitcoins before it goes into effect. Essentially, the on chain one is actually sent while the second is still fully in the sender's possession until the time comes and its resubmitted to the network by some party.
This is super helpful. Thanks! Is there any restriction on when it is sent with the first option? Couldn’t you put it as far out into the future as you want?
Transactions that aren’t yet valid won’t be relayed. Otherwise you could costlessly use an arbitrary amount of memory on every node on the network.
You can think of time locks as being in the transaction or in the unlocking script and as being relative or absolute (in blocks or calendar date).
https://medium.com/summa-technology/bitcoins-time-locks-27e0c362d7a1
> OP_CHECKLOCKTIMEVERIFY (CLTV): This opcode allows you to create a transaction output that cannot be spent until a certain time in the future. It is more reliable than nLockTime for future spending conditions.
Every Bitcoin transaction is a script that redefines the permissions required to affect a specific quantity of Bitcoin. When you send the normal Bitcoin transaction, you are not sending Bitcoin to an address, you are telling the network that the signature must match that pubkey for a transaction involving that coin to be valid. You can set other restrictions on valid transactions through other opcodes and scripts.
The reason there's a 65k block limit with CLTV is because this opcode accepts a 16 bit integer value.
That’s for scripts, IIRC