BitcoinCash/specification
1
Fork 0
Code Issues Pull Requests Releases Activity

Added hard forks and relevant files after 2018/05/15.

Browse Source 
Formated all the files.
This commit is contained in:
Christopher-Zeng
2020-11-10 12:04:49 -05:00
parent 18f36edeea
commit a92fa7435c
25 changed files with 2746 additions and 1009 deletions
Download Patch File Download Diff File Expand all files Collapse all files
protocol/forks/bip-0068.md
+45 -26
View File
@@ -1,17 +1,17 @@
<pre>
BIP: 68
Layer: Consensus (soft fork)
Title: Relative lock-time using consensus-enforced sequence numbers
Author: Mark Friedenbach &lt;mark@friedenbach.org&gt;
BtcDrak &lt;btcdrak@gmail.com&gt;
Nicolas Dorier &lt;nicolas.dorier@gmail.com&gt;
kinoshitajona &lt;kinoshitajona@gmail.com&gt;
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0068
Status: Final
Type: Standards Track
Created: 2015-05-28
</pre>
# BIP-0068
BIP: 68
Layer: Consensus (soft fork)
Title: Relative lock-time using consensus-enforced sequence numbers
Author: Mark Friedenbach &lt;mark@friedenbach.org&gt;
BtcDrak &lt;btcdrak@gmail.com&gt;
Nicolas Dorier &lt;nicolas.dorier@gmail.com&gt;
kinoshitajona &lt;kinoshitajona@gmail.com&gt;
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0068
Status: Final
Type: Standards Track
Created: 2015-05-28
## Abstract
@@ -19,9 +19,16 @@ This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the
## Motivation
Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this BIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases.
Bitcoin transactions have a sequence number field for each input.
The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value.
Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine.
However, a miner acting on profit motives alone would break that assumption completely.
The change described by this BIP repurposes the sequence number for new use cases without breaking existing functionality.
It also leaves room for future expansion and other use cases.
The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in [Hashed Timelock Contracts (HTLCs)](https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf) and [BIP112](/protocol/forks/bip-0112#bidirectional-payment-channels).
The transaction nLockTime is used to prevent the mining of a transaction until a certain date.
nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan.
This, among other uses, allows bi-directional payment channels as used in [Hashed Timelock Contracts (HTLCs)](https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf) and [BIP112](/protocol/forks/bip-0112#bidirectional-payment-channels).
## Specification
@@ -33,24 +40,33 @@ If bit (1 << 31) of the sequence number is set, then no consensus meaning is app
If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
The sequence number encoding is interpreted as follows:
The sequence number encoding is interpreted as follows:
Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity.
The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block.
If the bit is not set, the relative lock-time specifies a number of blocks.
The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112).
This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. The 16-bit specification allows for a year of relative lock-time and the remaining bits allow for future expansion.
This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time.
The 16-bit specification allows for a year of relative lock-time and the remaining bits allow for future expansion.
<img src=https://raw.githubusercontent.com/bitcoin/bips/master/bip-0068/encoding.png></img>
For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block-based or time-based, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits.
For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds.
So when using block-based or time-based, the same amount of time can be encoded with the available number of bits.
Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits.
When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter.
When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age.
A relative time-based lock-time of zero indicates an input which can be included in any block.
More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter.
The mining date of the output is equal to the median-time-past of the previous block which mined it.
The block produced time is equal to the median-time-past of its previous block.
When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age.
A relative block-based lock-time of zero indicates an input which can be included in any block.
More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
The new rules are not applied to the nSequence field of the input of the coinbase transaction.
@@ -233,11 +249,14 @@ This BIP must be deployed simultaneously with BIP112 and BIP113 using the same d
## Compatibility
The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.
The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction.
The semantics of that application are preserved by this BIP.
As can be seen from the specification section, a number of bits are undefined by this BIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this BIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset.
As can be seen from the specification section, a number of bits are undefined by this BIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this BIP.
Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset.
Additionally, this BIP specifies only 16 bits to actually encode relative lock-time meaning a further 6 are unused (1 << 16 through 1 << 21 inclusive). This allows the possibility to increase granularity by soft-fork, or for increasing the maximum possible relative lock-time in the future.
Additionally, this BIP specifies only 16 bits to actually encode relative lock-time meaning a further 6 are unused (1 << 16 through 1 << 21 inclusive).
This allows the possibility to increase granularity by soft-fork, or for increasing the maximum possible relative lock-time in the future.
The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts:
@@ -261,4 +280,4 @@ Bitcoin mailing list discussion: https://www.mail-archive.com/bitcoin-developmen
[BIP113](/protocol/forks/bip-0113): https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
Hashed Timelock Contracts (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf
Hashed Timelock Contracts (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf