bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

Comprehensive editing to clarify meaning and intent of existing text.

Browse Source
This commit is contained in:
Mark Friedenbach 2015-08-12 18:14:51 -07:00 committed by BtcDrak
parent ae46943f11
commit 6150b3a857
1 changed files with 77 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

133
bip-csv.mediawiki
View File

@ -1,6 +1,6 @@
<pre> <pre>
BIP: XX BIP: XX
Title: OP_CHECKSEQUENCEVERIFY Title: CHECKSEQUENCEVERIFY
Authors: BtcDrak <btcdrak@gmail.com> Authors: BtcDrak <btcdrak@gmail.com>
Mark Friedenbach <mark@friedenbach.org> Mark Friedenbach <mark@friedenbach.org>
Status: Draft Status: Draft
@ -10,32 +10,46 @@
==Abstract== ==Abstract==
This BIP describes a new opcode (OP_CHECKSEQUENCEVERIFY) for the Bitcoin This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
scripting system that allows a transaction output to be made unspendable scripting system that in combination with BIP 68 allows execution
until some relative point in the future according to the nSequence field. pathways of a script to be restricted based on the age of the output
being spent.
==Summary== ==Summary==
CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
compares the top item on the stack to the nSequence field of the transaction it compares the top item on the stack to the inverse of the nSequence
containing the scriptSig. If that top stack item is greater than the field of the transaction input containing the scriptSig. If the
transaction sequence threshold (1 << 31) the script fails immediately, inverse of nSequence is less than the sequence threshold (1 << 31),
otherwise script evaluation continues as though a NOP was executed. the transaction version is greater than or equal to 2, and the top
item on the stack is less than or equal to the inverted nSequence,
script evaluation continues as though a NOP was executed. Otherwise
the script fails immediately.
By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, BIP 68's redefinition of nSequence prevents a non-final transaction
we indirectly verify that the desired block height or block time has been from being selected for inclusion in a block until the corresponding
reached (according to BIP68's redefinition of nSequence); until that block input has reached the specified age, as measured in block heiht or
height or block time has been reached the transaction output remains block time. By comparing the argument to CHECKSEQUENCEVERIFY against
unspendable. the nSequence field, we indirectly verify a desired minimum age of the
the output being spent; until that relative age has been reached any
script execution pathway including the CHECKSEQUENCEVERIFY will fail
to validate, causing the transaction not to be selected for inclusion
in a block.
==Motivation== ==Motivation==
BIP68 repurposes the transaction nSequence field meaning by giving sequence BIP 68 repurposes the transaction nSequence field meaning by giving
numbers new consensus-enforced semantics as a relative lock-time. However, sequence numbers new consensus-enforced semantics as a relative
there is no way to build Bitcoin scripts to make decisions based on this lock-time. However, there is no way to build Bitcoin scripts to make
field. decisions based on this field.
By making the nSequence field accessible to script, it becomes
possible to construct code pathways that only become accessible some
minimum time after proof-of-publication. This enables a wide variety
of applications in phased protocols such as escrow, payment channels,
or bidirectional pegs.
==Specification== ==Specification==
@ -84,42 +98,47 @@ semantics and detailed rationale for those semantics.
break; break;
} }
bool CheckSequence(const CScriptNum& nSequence) const bool CheckSequence(const CScriptNum& nInvSequence) const
{ {
int64_t txToSequence; int64_t txToInvSequence;
// Fail under all circumstances if the transaction's version // Fail under all circumstances if the transaction's version
// number is not set high enough to enable enforced sequence // number is not set high enough to enable enforced sequence
// number rules. // number rules.
if (txTo->nVersion < 3) if (txTo->nVersion < 2)
return false;
// Sequence number must be inverted to convert it into a
// relative lock-time.
txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;
// Sequence numbers under SEQUENCE_THRESHOLD are not consensus
// constrained.
if (txToInvSequence >= SEQUENCE_THRESHOLD)
return false; return false;
txToSequence = (int64_t)~txTo->vin[nIn].nSequence; // There are two types of relative lock-time: lock-by-
if (txToSequence >= SEQUENCE_THRESHOLD) // blockheight and lock-by-blocktime, distinguished by
return false; // whether txToInvSequence < LOCKTIME_THRESHOLD.
// There are two types of nSequence: lock-by-blockheight
// and lock-by-blocktime, distinguished by whether
// nSequence < LOCKTIME_THRESHOLD.
// //
// We want to compare apples to apples, so fail the script // We want to compare apples to apples, so fail the script
// unless the type of nSequence being tested is the same as // unless the type of lock-time being tested is the same as
// the nSequence in the transaction. // the lock-time in the transaction input.
if (!( if (!(
(txToSequence < LOCKTIME_THRESHOLD && nSequence < LOCKTIME_THRESHOLD) || (txToInvSequence < LOCKTIME_THRESHOLD && nInvSequence < LOCKTIME_THRESHOLD) ||
(txToSequence >= LOCKTIME_THRESHOLD && nSequence >= LOCKTIME_THRESHOLD) (txToInvSequence >= LOCKTIME_THRESHOLD && nInvSequence >= LOCKTIME_THRESHOLD)
)) ))
return false; return false;
// Now that we know we're comparing apples-to-apples, the // Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one. // comparison is a simple numeric one.
if (nSequence > txToSequence) if (nInvSequence > txInvToSequence)
return false; return false;
return true; return true;
} }
https://github.com/btcdrak/bips/blob/bip-csv/bip-csv/example.cpp https://github.com/maaku/bitcoin/commit/33be476a60fcc2afbe6be0ca7b93a84209173eb2
==Example: Escrow with Timeout== ==Example: Escrow with Timeout==
@ -131,7 +150,7 @@ address with the following redeemscript.
IF IF
2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY 2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY
ELSE ELSE
<30 days> CHECKSEQUENCEVERIFY DROP <LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
<Alice's pubkey> CHECKSIGVERIFY <Alice's pubkey> CHECKSIGVERIFY
ENDIF ENDIF
@ -153,13 +172,13 @@ https://github.com/maaku/bitcoin/tree/checksequenceverify
==Deployment== ==Deployment==
We reuse the double-threshold switchover mechanism from BIPs 34 and 66, We reuse the double-threshold switchover mechanism from BIPs 34 and
with the same thresholds, but for nVersion = 4. The new rules are in 66, with the same thresholds, but for nVersion = 4. The new rules are
effect for every block (at height H) with nVersion = 4 and at least 750 in effect for every block (at height H) with nVersion = 4 and at least
out of 1000 blocks preceding it (with heights H-1000..H-1) also have 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
nVersion = 4. Furthermore, when 950 out of the 1000 blocks preceding a have nVersion = 4. Furthermore, when 950 out of the 1000 blocks
block do have nVersion = 4, nVersion = 3 blocks become invalid, and all preceding a block do have nVersion = 4, nVersion = 3 blocks become
further blocks enforce the new rules. invalid, and all further blocks enforce the new rules.
It is recommended that this soft-fork deployment trigger include other It is recommended that this soft-fork deployment trigger include other
related proposals for improving Bitcoin's lock-time capabilities, including: related proposals for improving Bitcoin's lock-time capabilities, including:
@ -174,33 +193,35 @@ and [https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki BIP XX]:
Median-Past-Time-Lock. Median-Past-Time-Lock.
==Upgrade and Testing Plan==
TBD
==Credits== ==Credits==
Mark Friedenbach for designing and authoring the actual implementation Mark Friedenbach invented the application of sequence numbers to
for CHECKSEQUENCEVERIFY. achieve relative lock-time, and wrote the reference implementation of
CHECKSEQUENCEVERIFY.
The reference implementation and this BIP was based heavily on work
done by Peter Todd for the closely related BIP 65.
BtcDrak edited this BIP document.
==References== ==References==
BIP 68: Consensus-enforced transaction replacement signalled via sequence numbers BIP 68: Consensus-enforced transaction replacement signalled via
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki sequence numbers
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
BIP 65: OP_CHECKLOCKTIMEVERIFY BIP 65: OP_CHECKLOCKTIMEVERIFY
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
BIP XX: Median-Past-Time-Lock BIP XX: Median past block time for time-lock constraints
https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki
HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html revocation hashes
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
==Copyright== ==Copyright==
This document is placed in the public domain. This document is placed in the public domain.