flywithu/Learning-Bitcoin-from-the-Command-Line
1
1
Fork 0
mirror of https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line.git synced 2025-06-07 16:06:26 +00:00
Code Issues Releases Wiki Activity

Update 9_1_Understanding_Timelock_Options.md

Browse Source
This commit is contained in:
Shannon Appelcline 2017-05-31 13:09:37 -07:00 committed by GitHub
parent e9e295d268
commit 8de06b4e18
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
9_1_Understanding_Timelock_Options.md
View File

@ -2,14 +2,14 @@
> **NOTE:** This is a draft in progress, so that I can get some feedback from early reviewers. It is not yet ready for learning.
In [§6.4: Sending a Transaction with a Locktime](6_4_Sending_a_Transaction_with_a_Locktime.md), `nLocktime` offered a great foundation for locking transactions so that they couldn't be spent until some point in the future — based either on time or blockheight. But, that's not the only way to put a timelock on a transaction.
In [§6.4: Sending a Transaction with a Locktime](6_4_Sending_a_Transaction_with_a_Locktime.md), `nLocktime` offered a great first option for locking transactions so that they couldn't be spent until some point in the future — based either on time or blockheight. But, that's not the only way to put a timelock on a transaction.
## Understand the Limitations of nLockTime
`nLockTime` is a simple and powerful way to lock a transaction, but it has some limitations:
1. **No Splits.** `nLocktime` locks the entire transaction.
2. **No Networking.** Most modern nodes won't accept a `nLockTime` into the memory pool until it's almost ready to finalize.
1. **No Divisions.** `nLocktime` locks the entire transaction.
2. **No Networking.** Most modern nodes won't accept a `nLockTime` into the mempool until it's almost ready to finalize.
3. **No Scripts.** The original, simple use of `nLockTime` didn't allow it to be used in Scripts.
4. **No Protection.** `nLockTime` allows the funds to be spent with a different, non-locked transaction.
@ -17,13 +17,13 @@ The last item was often the dealbreaker for `nLockTime`. It prevented a transact
## Understand the Possibilities of Timelock Scripts
In more recent years, Bitcoin Core has expanded to include two new sorts of timelocks, _OP_CHECKLOCKTIMEVERIFY_ (CLTV) and _OP_CHECKSEQUENCEVERIFY_ (CSV). These both work under a new methodology that further empowers Bitcoin.
In more recent years, Bitcoin Core has expanded to allow the manipulation of timelocks at the opcode level with _OP_CHECKLOCKTIMEVERIFY_ (CLTV) and _OP_CHECKSEQUENCEVERIFY_ (CSV). These both work under a new methodology that further empowers Bitcoin.
_They Are Opcodes._ Because they're opcodes, CLTV and CSV can be used as part of more complex redemption conditions. Most often they're linked with the conditionals described in the next chapter.
_They Lock Outputs._ Because they're opcodes that are included in transactions as part of a `sigPubKey`, they just lock that single output. That means that the transactions are accepted onto the Bitcoin network and that the UTXOs used to fund those transactions are spent. There's no going back on a transaction Timelocked with CLTV or CSV, as there is with a bare `nLockTime`. Respending the resultant UTXO then requires that the timelock conditions be met.
_They Lock Outputs._ Because they're opcodes that are included in transactions as part of a `sigPubKey`, they just lock that single output. That means that the transactions are accepted onto the Bitcoin network and that the UTXOs used to fund those transactions are spent. There's no going back on a transaction timelocked with CLTV or CSV like there is with a bare `nLockTime`. Respending the resultant UTXO then requires that the timelock conditions be met.
Here's one catch to use timelocks: _They Can't Relock Funds._ The Timelocks are designed in such a way that they unlock funds at a certain time. They cannot then relock a fund: once a timelocked fund is available to spend, it remains available to spend.
Here's one catch for using timelocks: _They're one-way locks._ Timelocks are designed so that they unlock funds at a certain time. They cannot then relock a fund: once a timelocked fund is available to spend, it remains available to spend.
### Understand the Possibilities of CLTV
@ -33,7 +33,7 @@ CLTV was first detailed in [BIP 65](https://github.com/bitcoin/bips/blob/master/
### Understand the Possibilities of CSV
_OP_CHECKSEQUENCEVERIFY_ or CSV depends on a new sort of "relative locktime", which is set in the transaction's _nSequence_ field. As usual, it can be set as either a time or a blockheight. If it's set as a time, "n", then a relative-timelocked transaction is spendable "n x 512" seconds after it was created, and if it's set as a block, "n", then a relative-timelocked transaction is spendable "n" blocks after it was created.
_OP_CHECKSEQUENCEVERIFY_ or CSV depends on a new sort of "relative locktime", which is set in the transaction's _nSequence_ field. As usual, it can be set as either a time or a blockheight. If it's set as a time, "n", then a relative-timelocked transaction is spendable "n x 512" seconds after its UTXO was mined, and if it's set as a block, "n", then a relative-timelocked transaction is spendable "n" blocks after its UTXO was mined.
The use of `nSequence` for a relative timelock was first detailed in [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), then the CSV opcode was added in [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki).