1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
<pre>
BIP: XX
Title: OP_CHECKSEQUENCEVERIFY
Authors: BtcDrak <btcdrak@gmail.com>
Mark Friedenbach <mark@friedenbach.org>
Status: Draft
Type: Standards Track
Created: 2015-08-10
</pre>
==Abstract==
This BIP describes a new opcode (OP_CHECKSEQUENCEVERIFY) for the Bitcoin
scripting system that allows a transaction output to be made unspendable
until some relative point in the future according to the nSequence field.
==Summary==
CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it
compares the top item on the stack to the nSequence field of the transaction
containing the scriptSig. If that top stack item is greater than the
transaction sequence threshold (1 << 31) the script fails immediately,
otherwise script evaluation continues as though a NOP was executed.
By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field,
we indirectly verify that the desired block height or block time has been
reached (according to BIP68's redefinition of nSequence); until that block
height or block time has been reached the transaction output remains
unspendable.
==Motivation==
BIP68 repurposes the transaction nSequence field meaning by giving sequence
numbers new consensus-enforced semantics as a relative lock-time. However,
there is no way to build Bitcoin scripts to make decisions based on this
field.
==Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP3:
{
if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
// not enabled; treat as a NOP3
if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
}
break;
}
if (stack.size() < 1)
return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
// Note that unlike CHECKLOCKTIMEVERIFY we do not need to
// accept 5-byte bignums since any value greater than or
// equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
// anyway. This limitation just happens to coincide with
// CScriptNum's default 4-byte limit with an explicit sign
// bit.
//
// This means there is a maximum relative lock time of 52
// years, even though the nSequence field in transactions
// themselves is uint32_t and could allow a relative lock
// time of up to 120 years.
const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);
// In the rare event that the argument may be < 0 due to
// some arithmetic being done first, you can always use
// 0 MAX CHECKSEQUENCEVERIFY.
if (nInvSequence < 0)
return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
// Actually compare the specified inverse sequence number
// with the input.
if (!CheckSequence(nInvSequence))
return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
break;
}
bool CheckSequence(const CScriptNum& nSequence) const
{
int64_t txToSequence;
// Fail under all circumstances if the transaction's version
// number is not set high enough to enable enforced sequence
// number rules.
if (txTo->nVersion < 3)
return false;
txToSequence = (int64_t)~txTo->vin[nIn].nSequence;
if (txToSequence >= SEQUENCE_THRESHOLD)
return false;
// 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
// unless the type of nSequence being tested is the same as
// the nSequence in the transaction.
if (!(
(txToSequence < LOCKTIME_THRESHOLD && nSequence < LOCKTIME_THRESHOLD) ||
(txToSequence >= LOCKTIME_THRESHOLD && nSequence >= LOCKTIME_THRESHOLD)
))
return false;
// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if (nSequence > txToSequence)
return false;
return true;
}
https://github.com/btcdrak/bips/blob/bip-csv/bip-csv/example.cpp
==Example: Escrow with Timeout==
An escrow that times out automatically 30 days after being funded can be
established in the following way. Alice, Bob and Escrow create a 2-of-3
address with the following redeemscript.
IF
2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY
ELSE
<30 days> CHECKSEQUENCEVERIFY DROP
<Alice's pubkey> CHECKSIGVERIFY
ENDIF
At any time funds can be spent using signatures from any two of Alice,
Bob or the Escrow.
After 30 days Alice can sign alone.
The clock does not start ticking until the payment to the escrow address
confirms.
==Reference Implementation==
A reference implementation is provided in the following git repository:
https://github.com/maaku/bitcoin/tree/checksequenceverify
==Deployment==
We reuse the double-threshold switchover mechanism from BIPs 34 and 66,
with the same thresholds, but for nVersion = 4. The new rules are in
effect for every block (at height H) with nVersion = 4 and at least 750
out of 1000 blocks preceding it (with heights H-1000..H-1) also have
nVersion = 4. Furthermore, when 950 out of the 1000 blocks preceding a
block do have nVersion = 4, nVersion = 3 blocks become invalid, and all
further blocks enforce the new rules.
It is recommended that this soft-fork deployment trigger include other
related proposals for improving Bitcoin's lock-time capabilities, including:
[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]:
OP_CHECKLOCKTIMEVERIFY,
[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]:
Consensus-enforced transaction replacement signalled via sequence numbers,
and [https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki BIP XX]:
Median-Past-Time-Lock.
==Upgrade and Testing Plan==
TBD
==Credits==
Mark Friedenbach for designing and authoring the actual implementation
for CHECKSEQUENCEVERIFY.
==References==
BIP 68: Consensus-enforced transaction replacement signalled via sequence numbers
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
BIP 65: OP_CHECKLOCKTIMEVERIFY
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
BIP XX: Median-Past-Time-Lock
https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki
HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
==Copyright==
This document is placed in the public domain.
|
