Fix formatting

1 files changed, 7 insertions, 10 deletions

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index 794d13a..b1c598d 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -1,10 +1,7 @@
-{{bip}}
-
-
 RECENT CHANGES:
-* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)
-* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)
-* [25 May 2013] Added test vectors
+* (16 Apr 2013) Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)
+* (30 Apr 2013) Switched from multiplication by I_L to addition of I_L (faster, easier implementation)
+* (25 May 2013) Added test vectors
 
 <pre>
   BIP: 32
@@ -17,7 +14,7 @@ RECENT CHANGES:
 
 ==Abstract==
 
-This document describes [[Deterministic Wallet|hierarchical determinstic wallets]] (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.
+This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.
 
 The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients.
 
@@ -25,7 +22,7 @@ The specification consists of two parts. In a first part, a system for deriving
 
 ==Motivation==
 
-The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well. 
+The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well.
 
 Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).
 
@@ -105,7 +102,7 @@ The first 32 bits of the identifier are called the fingerprint.
 
 Extended public and private keys are serialized as follows:
 * 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
-* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... 
+* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, ....
 * 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)
 * 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)
 * 32 bytes: the chain code
@@ -127,7 +124,7 @@ The total number of possible extended keypairs is almost 2^512, but the produced
 * Use I<sub>L</sub> as master secret key, and I<sub>R</sub> as master chain code.
 In case I<sub>L</sub> is 0 or >=n, the master key is invalid.
 
-[[File:BIP32-derivation.png]]
+<img src=bip-0032/derivation.png></img>
 
 ==Specification: Wallet structure==