Formatting feedback & copyright from btcdrak.

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

1 files changed, 22 insertions, 17 deletions

diff --git a/bip-wuille-todd-maxwell-russell.mediawiki b/bip-wuille-todd-maxwell-russell.mediawiki
index d43157b..3bb2b9b 100644
--- a/bip-wuille-todd-maxwell-russell.mediawiki
+++ b/bip-wuille-todd-maxwell-russell.mediawiki
@@ -1,3 +1,4 @@
+<pre>
   BIP: ??
   Title: Version bits with timeout and delay
   Author: Pieter Wuille <pieter.wuille@gmail.com>, Peter Todd <pete@petertodd.org>, Greg Maxwell <greg@xiph.org>, Rusty Russell <rusty@rustcorp.com.au>
@@ -36,21 +37,21 @@ retarget period.
 Software which supports the change should begin by setting B in all blocks
 mined until it is resolved.
 
- <nowiki>if (BState == defined) {
-     SetBInBlock();
- }
+    if (BState == defined) {
+        SetBInBlock();
+    }
 
 '''Success: Lock-in Threshold'''
 If bit B is set in 1916 (1512 on testnet) or
 more of the 2016 blocks within a retarget period, it is considered
 ''locked-in''.  Miners should stop setting bit B.
 
- <nowiki>if (NextBlockHeight % 2016 == 0) {
-    if (BState == defined && Previous2016BlocksCountB() >= 1916) {
-        BState = locked-in;
-        BActiveHeight = NextBlockHeight + 2016;
+    if (NextBlockHeight % 2016 == 0) {
+        if (BState == defined && Previous2016BlocksCountB() >= 1916) {
+            BState = locked-in;
+            BActiveHeight = NextBlockHeight + 2016;
+        }
     }
- }
 
 '''Success: Activation Delay'''
 The consensus rules related to ''locked-in'' soft fork will be enforced in
@@ -58,11 +59,11 @@ the second retarget period; ie. there is a one retarget period in
 which the remaining 5% can upgrade.  At the that activation block and
 after, the bit B may be reused for a different soft fork.
 
- <nowiki>if (BState == locked-in && NextBlockHeight == BActiveHeight) {
-    BState = activated;
-    ApplyRulesForBFromNextBlock();
-    /* B can be reused, immediately */
- }
+    if (BState == locked-in && NextBlockHeight == BActiveHeight) {
+        BState = activated;
+        ApplyRulesForBFromNextBlock();
+        /* B can be reused, immediately */
+     }
 
 '''Failure: Timeout'''
 A soft fork proposal should include a ''timeout''.  This is measured
@@ -120,11 +121,11 @@ If the soft fork still not ''locked-in'' and the
 GetMedianTimePast() of a block following a retarget period is at or
 past this timeout, miners should cease setting this bit.
 
- <nowiki>if (NextBlockHeight % 2016 == 0) {
-    if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) {
-         BState = failed;
+    if (NextBlockHeight % 2016 == 0) {
+        if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) {
+             BState = failed;
+        }
     }
- }
 
 After another retarget period (to allow detection of buggy miners),
 the bit may be reused.
@@ -160,3 +161,7 @@ enough failed proposals to cause a bit shortage.
 The fallow period at the conclusion of a soft fork attempt allows some
 detection of buggy clients, and allows time for warnings and software
 upgrades for successful soft forks.
+
+==Copyright==
+
+This document is placed in the public domain.