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-08 16:36:32 +00:00
Code Issues Releases Wiki Activity

Update 9_3_Using_CSV_in_Scripts.md

Browse Source
This commit is contained in:
Shannon Appelcline 2017-05-26 15:29:04 -07:00 committed by GitHub
parent b0356871d7
commit cc87fb5979
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
9_3_Using_CSV_in_Scripts.md
View File

@ -91,7 +91,7 @@ CSV has many of the same subtleties in usage as CLTV:
* Both the stack operand and `nSequence` must have the same value on the 23rd bit. * Both the stack operand and `nSequence` must have the same value on the 23rd bit.
* The `nSequence` must be greater than or equal to the stack operand. * The `nSequence` must be greater than or equal to the stack operand.
Just as with CLTV, when you are respending a UTXO with a CSV in its locking conditions, you must set the `nSequence` to enable the transaction. You'll usually set it to the number of blocks or the converted value of seconds since the UTXO was mined, as appropriate. Just as with CLTV, when you are respending a UTXO with a CSV in its locking conditions, you must set the `nSequence` to enable the transaction. You'll usually set it to the exact value in the locking script.
## Write a CSV Script ## Write a CSV Script
@ -129,5 +129,10 @@ Hexcode: 03a77640
## Spend a CSV UTXO ## Spend a CSV UTXO
To spend a UTXO locked with a CSV script, you must set the `nSequence` of that input to a value greater than the requirement in the script, but less than the time between the UTXO and the present block. Yes, this means that you need to know the exact requirement in the locking script ... but you have a copy of the `redeemScript`, so if you don't know the requirements, you deserialize it, and then set the `nSequence` to the number that's shown there.
## Summary: Using CSV in Scripts ## Summary: Using CSV in Scripts
`nSequence` and CSV offer an alternative to `nLockTime` and CLTV where you lock a transaction based on a relative time since the input was mined, rather than a set time in the future. Other than that they work almost identically, other than the fact that the `nSequence` value is encoded slightly differently than the `nLockTime` value, with specific bits meaning specific things.
_What is the power of CSV?_ CSV isn't just a lazy way to lock, when you don't want to calculate a time in the future. Instead, it's a totally different paradigm, a lock that you would use if it was important to create a specific minimum duration between when a transaction is mined and when its funds can be respent. The most obvious usage is (once more) for an escrow, when you want a precise time between the input of funds and their output. However, it has much more powerful possibilities in off-chain transactions, including payment channels. These applications are by definition built on transactions that are not actually put onto the blockchain, which means that if they are later put on the blockchain an enforced time-lapse can be very helpful. [Hashed Timelock Contracts](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts) have been one such implementation, empowering the Lightning payment network.