lukechilds
/
bips
mirror of https://github.com/lukechilds/bips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

Add constant definitions for clarity 

Formatting Fix typos

Update with BIP 112 assignment

Update references to BIP113

Update deployment methodology

Add references
2015_12_bip1
฿tcDrak 9 years ago
committed by BtcDrak
parent
6150b3a857
commit
6902f790f1
1 changed files with 37 additions and 18 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 55
      bip-0112.mediawiki

55
bip-csv.mediawiki → bip-0112.mediawiki
View File

@ -1,5 +1,5 @@
<pre>
BIP: XX
BIP: 112
Title: CHECKSEQUENCEVERIFY
Authors: BtcDrak <btcdrak@gmail.com>
Mark Friedenbach <mark@friedenbach.org>
@ -29,7 +29,7 @@ the script fails immediately.
BIP 68's redefinition of nSequence prevents a non-final transaction
from being selected for inclusion in a block until the corresponding
input has reached the specified age, as measured in block heiht or
input has reached the specified age, as measured in block height or
block time. By comparing the argument to CHECKSEQUENCEVERIFY against
the nSequence field, we indirectly verify a desired minimum age of the
the output being spent; until that relative age has been reached any
@ -58,6 +58,14 @@ Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
// Threshold for nLockTime: below this value it is interpreted as block number,
// otherwise as UNIX timestamp (already defined in Bitcoin Core).
static const unsigned int LOCKTIME_THRESHOLD = 500000000; // Tue Nov 5 00:53:20 1985 UTC
// Threshold for inverted nSequence: below this value it is interpreted
// as a relative lock-time, otherwise ignored.
static const uint32_t SEQUENCE_THRESHOLD = (1 << 31);
case OP_NOP3:
{
if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
@ -107,19 +115,19 @@ semantics and detailed rationale for those semantics.
// number rules.
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;
txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;
// Sequence numbers under SEQUENCE_THRESHOLD are not consensus
// constrained.
if (txToInvSequence >= SEQUENCE_THRESHOLD)
// constrained.
if (txToInvSequence >= SEQUENCE_THRESHOLD)
return false;
// There are two types of relative lock-time: lock-by-
// blockheight and lock-by-blocktime, distinguished by
// whether txToInvSequence < LOCKTIME_THRESHOLD.
// whether txToInvSequence < LOCKTIME_THRESHOLD.
//
// We want to compare apples to apples, so fail the script
// unless the type of lock-time being tested is the same as
@ -132,9 +140,9 @@ semantics and detailed rationale for those semantics.
// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if (nInvSequence > txInvToSequence)
if (nInvSequence > txToInvSequence)
return false;
return true;
}
@ -173,13 +181,21 @@ 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
66, with the same thresholds, but for nVersion = 8. The new rules are
in effect for every block (at height H) with nVersion = 8 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
have nVersion = 8. Furthermore, when 950 out of the 1000 blocks
preceding a block do have nVersion = 8, nVersion = 3 blocks become
invalid, and all further blocks enforce the new rules.
When assessing the block version as mask of ~0x20000007 must be applied
to work around the complications caused by
[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html BIP101's premature use]
of the [https://gist.github.com/sipa/bf69659f43e763540550 undecided version bits proposal].
By applying ~0x20000007 with nVersion = 8, the thresholds should be tested
comparing block nVersion >= 4 as this will save a bit for future use.
It is recommended that this soft-fork deployment trigger include other
related proposals for improving Bitcoin's lock-time capabilities, including:
@ -189,10 +205,9 @@ 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]:
and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113]:
Median-Past-Time-Lock.
==Credits==
Mark Friedenbach invented the application of sequence numbers to
@ -202,7 +217,7 @@ 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.
BtcDrak authored this BIP document.
==References==
@ -214,13 +229,17 @@ 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 block time for time-lock constraints
https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki
BIP 113: Median past block time for time-lock constraints
https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
revocation hashes
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
[https://gist.github.com/sipa/bf69659f43e763540550 Version bits]
==Copyright==
Write Preview
Loading…
Cancel
Save