Difference between revisions of "CSV"

From DigiByte Wiki
Jump to navigation Jump to search
 
Line 1: Line 1:
  
CSV stands for Check Sequence Verify for the DigiByte scripting system. CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. It has made huge improvement in DigiByte protocols.
+
Also part of the BIP68/112/113 soft fork was the&nbsp;[https://en.bitcoin.it/wiki/CheckSequenceVerify CheckSequenceVerify]&nbsp;opcode<span style="font-size: 10.8333px;">,</span>&nbsp;which provides for relative locktime the same feature CLTV (CheckLockTimeVerify) provides for absolute locktime. When the CSV opcode is called, it will cause the script to fail unless the nSequence on the transaction indicates an equal or greater amount of relative locktime has passed than the parameter provided to the CSV opcode. Since an input may only be included in a valid block if its relative locktime is expired, this ensures the CSV-based timelock has expired before the transaction may be included in a valid block.
  
CheckSequenceVerify (CSV) is included in SegNet 4. CSV is a big improvement in DigiByte protocol. CSV allows users to prevent selected inputs getting confimred for a certain amount of time. As a result after this period of blockage of coins, the coins will be unlocked for transaction.
+
[https://en.bitcoin.it/wiki/Timelock Source]
 
 
It is quiet similar to CLTV (CheckLockTimeVerify) which can allow a user to make DigiBytes unspendable for a period of time. But CSV is quiet different to CLTV. The main difference between them is that CLTV locks coins until a specified moment in time whereas CSV lock is relative and applies only after the transaction is included in a block. As a result CSV implementation gives more flexibility in transactions. This is useful for Payment Channels which are great for micropayments or for fast payments.
 
 
 
The combination of Segregated Witness and CSV particularly benefits added scaling layers on top of the DigiByte blockchain
 
 
 
[https://coinour.com/index.php/what-is-csv-check-sequence-verify/ Source]
 

Latest revision as of 04:28, 21 August 2019

Also part of the BIP68/112/113 soft fork was the CheckSequenceVerify opcode, which provides for relative locktime the same feature CLTV (CheckLockTimeVerify) provides for absolute locktime. When the CSV opcode is called, it will cause the script to fail unless the nSequence on the transaction indicates an equal or greater amount of relative locktime has passed than the parameter provided to the CSV opcode. Since an input may only be included in a valid block if its relative locktime is expired, this ensures the CSV-based timelock has expired before the transaction may be included in a valid block.

Source