diff options
| author | BtcDrak <btcdrak@gmail.com> | 2015-11-28 22:30:58 +0000 |
|---|---|---|
| committer | BtcDrak <btcdrak@gmail.com> | 2015-11-28 22:30:58 +0000 |
| commit | a8e0d0f4c77f9e3002da7d4e9c6d4671d0dffa01 (patch) | |
| tree | 8cf0c4e95baf917164ebd247e1a71187ac1844c1 /bip-0068.mediawiki | |
| parent | 8ad8cad875842ee9f63eb43216eb7eb7ac02de4d (diff) | |
Small fixup
Diffstat (limited to 'bip-0068.mediawiki')
| -rw-r--r-- | bip-0068.mediawiki | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index a487392..02bc2a4 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -1,6 +1,6 @@ <pre> BIP: 68 - Title: Relative lock-time through consensus-enforced sequence numbers + Title: Relative lock-time using consensus-enforced sequence numbers Author: Mark Friedenbach <mark@friedenbach.org> BtcDrak <btcdrak@gmail.com> Nicolas Dorier <nicolas.dorier@gmail.com> @@ -12,7 +12,7 @@ ==Abstract== -This BIP introduces consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint. +This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint. ==Motivation== @@ -38,12 +38,12 @@ This specification only interprets 16 bits of the sequence number as relative lo <img src=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 relative lock-time, 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. -The mining date of the output is equals to the Median Time Past of the previous block which mined it. +The mining date of the output is equals to the median-time-past of the previous block which mined it. -The block produced time is either equals to median time past of its parent or to its nTime field, depending on the state of BIP113 (MTP). +The block produced time is either equals to median time past of its parent or to its nTime field, depending on the state of BIP113 median-time-past. 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. |