From c20640ca23d3be4b3fc965bfd01762a1f2e36b2b Mon Sep 17 00:00:00 2001 From: Shannon Appelcline Date: Fri, 26 May 2017 13:43:18 -0700 Subject: [PATCH] Update 9_3_Using_CSV_in_Scripts.md --- 9_3_Using_CSV_in_Scripts.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/9_3_Using_CSV_in_Scripts.md b/9_3_Using_CSV_in_Scripts.md index 5600aa0..7c5f645 100644 --- a/9_3_Using_CSV_in_Scripts.md +++ b/9_3_Using_CSV_in_Scripts.md @@ -57,12 +57,10 @@ Issue the transaction, but it can't legally be mined until enough blocks or enou Except pretty much no one does this. The new [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) definitions for `nSequence` were incorporated into Bitcoin Core at the same time as [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) which describes the CSV opcode, which works with `nSequence`, just like the CLTV opcode works with `nTimeLock`. Just like CLTV, CSV offers increased capabilities. So almost all usage of relative timelocks has been with the CSV opcode, not with the raw `nSequence` value on its own. -
| | Absolute Timelock | Relative Timelock | -|------------------|-------------------|-------------------| +|:------------------:|-------------------|-------------------| | **Lock Transaction** | nTimeLock | nSequence | | **Lock Output** | OP_CHECKLOCKTIMEVERIFY| OP_CHECKSEQUENCEVERIFY | -
## Understand the CSV Opcode