bip9: fix heading levels.

It goes from level 2 (specification) to 4; those headings should be level 3.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

1 files changed, 5 insertions, 5 deletions

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 49e6adf..6848c45 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -35,7 +35,7 @@ timeout or activation, though it is recommended to have a pause in between to de
 
 Setting the timeout to 3 years after the starttime allows at least 9 new deployments per year.
 
-====States====
+===States===
 
 With each block and soft fork, we associate a deployment state. The possible states are:
 
@@ -45,7 +45,7 @@ With each block and soft fork, we associate a deployment state. The possible sta
 # '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
 # '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached.
 
-====Bit flags====
+===Bit flags===
 
 Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
@@ -59,11 +59,11 @@ bits are 0 for the purposes of deployments.
 Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on
 consensus rules.
 
-====New consensus rules====
+===New consensus rules===
 
 The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
 
-====State transitions====
+===State transitions===
 
 <img src="bip-0009/states.png" align="middle"></img>
 
@@ -149,7 +149,7 @@ current retarget period (i.e. up to and including its ancestor with height block
 it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
 block, indexed by its parent.
 
-====Warning mechanism====
+===Warning mechanism===
 
 To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion.  Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).