diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index a487392d..02bc2a4e 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.