From d9e890a8f27e46806238e298a346397871fd7e87 Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Mon, 21 Oct 2013 02:18:47 -0400 Subject: [PATCH] Fix formatting --- README.mediawiki | 4 +- bip-0001.mediawiki | 14 +++--- bip-0001-1.png => bip-0001/process.png | Bin bip-0010.mediawiki | 25 +++++------ bip-0011.mediawiki | 4 -- bip-0012.mediawiki | 4 -- bip-0013.mediawiki | 14 +++--- bip-0014.mediawiki | 4 -- bip-0015.mediawiki | 60 ++++++++++++------------- bip-0016.mediawiki | 8 +--- bip-0017.mediawiki | 8 +--- bip-0018.mediawiki | 10 ++--- bip-0019.mediawiki | 6 +-- bip-0020.mediawiki | 30 ++++++++----- bip-0021.mediawiki | 15 +++---- bip-0022.mediawiki | 16 +++---- bip-0023.mediawiki | 12 ++--- bip-0030.mediawiki | 6 --- bip-0031.mediawiki | 6 --- bip-0032.mediawiki | 17 +++---- bip-0032/derivation.png | Bin 0 -> 166153 bytes bip-0033.mediawiki | 2 - bip-0034.mediawiki | 6 --- bip-0035.mediawiki | 6 --- bip-0036.mediawiki | 6 --- bip-0037.mediawiki | 6 --- bip-0039.mediawiki | 2 - bip-0050.mediawiki | 2 - bip-0060.mediawiki | 12 ++--- bip-0070.mediawiki | 14 +++--- bip-0070/Protocol_Sequence.png | Bin 0 -> 29564 bytes bip-0071.mediawiki | 4 -- bip-0072.mediawiki | 3 -- bip-0073.mediawiki | 43 +++++++++--------- bip-0073/a.png | Bin 0 -> 674 bytes bip-0073/b.png | Bin 0 -> 514 bytes 36 files changed, 129 insertions(+), 240 deletions(-) rename bip-0001-1.png => bip-0001/process.png (100%) create mode 100644 bip-0032/derivation.png create mode 100644 bip-0070/Protocol_Sequence.png create mode 100644 bip-0073/a.png create mode 100644 bip-0073/b.png diff --git a/README.mediawiki b/README.mediawiki index 83648a6e..6405b42b 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1,10 +1,10 @@ -People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell . After copy-editing and acceptance, it will be published here. +People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here. We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community. -Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [[economic majority]]). +Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority]). {| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" !Number diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index b0662caf..3661daf2 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -1,5 +1,3 @@ -{{bip}} - 
   BIP: 1
   Title: BIP Purpose and Guidelines
@@ -26,7 +24,7 @@ There are three kinds of BIP:
 
 ==BIP Work Flow==
 
-The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to  (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below.
+The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to gmaxwell@gmail.com (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below.
 
 The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones.
 
@@ -36,7 +34,7 @@ Vetting an idea publicly before going as far as writing a BIP is meant to save t
 
 Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
 
-Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors . This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
+Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors gmaxwell@gmail.com. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
 
 If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and create and create a page for it on the [[Bitcoin_Improvement_Proposals|Bitcoin Wiki]]. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
 
@@ -58,7 +56,7 @@ BIPs can also be superseded by a different BIP, rendering the original obsolete.
 
 The possible paths of the status of BIPs are as follows:
 
-[[File:BIP-0001-Process.png]]
+
 
 Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 1 (this BIP).
 
@@ -140,10 +138,10 @@ BIPs may include auxiliary files such as diagrams. Such files must be named BIP-
 
 It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.
 
-If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor . If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
+If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor gmaxwell@gmail.com. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
 BIP Editor Responsibilities & Workflow
 
-A BIP editor must subscribe to the  list. All BIP-related correspondence should be sent (or CC'd) to  (but please do not cross-post!).
+A BIP editor must subscribe to the gmaxwell@gmail.com list. All BIP-related correspondence should be sent (or CC'd) to gmaxwell@gmail.com (but please do not cross-post!).
 
 For each new BIP that comes in an editor does the following:
 
@@ -170,5 +168,3 @@ The editors don't pass judgement on BIPs. We merely do the administrative & edit
 ==History==
 
 This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the Bitcoin editors or the forums at bitcointalk.org.
-
-[[Category:BIP|A]]
diff --git a/bip-0001-1.png b/bip-0001/process.png
similarity index 100%
rename from bip-0001-1.png
rename to bip-0001/process.png
diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki
index 2270a820..ac4f4a4b 100644
--- a/bip-0010.mediawiki
+++ b/bip-0010.mediawiki
@@ -1,17 +1,15 @@
-{{bip}}
-
 
   BIP: 10
   Title: Multi-Sig Transaction Distribution
-  Author: Alan Reiner  
-  Status: Draft 
+  Author: Alan Reiner
+  Status: Draft
   Type: Informational
   Created: 28-10-2011
 

 
 A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address.  The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the proposed transaction and sign it with their private key.  This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.
 
-This BIP describes a way standardize the encoding of proposal transactions, to assist with signature collection and broadcast (which includes regular, 1-of-1 transactions requiring signatures from an offline computer).  The goal is to encourage a standard that guarantees interoperability of all programs that implement it.  
+This BIP describes a way standardize the encoding of proposal transactions, to assist with signature collection and broadcast (which includes regular, 1-of-1 transactions requiring signatures from an offline computer).  The goal is to encourage a standard that guarantees interoperability of all programs that implement it.
 
 
 ==Motivation==
@@ -22,23 +20,24 @@ In addition to providing a general encoding scheme for transaction signing/colle
 
 ==Specification==
 
-This BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations.  
+This BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations.
 
 #  One party will initiate this process by creating a "Distribution Proposal", which could be abbreviated DP, or TxDP
 #  The user creating the TxDP (the preparer) will create the transaction as they would like to see it spent, but with blank TxIn scripts (where the signatures scripts will eventually go).
 #  The proposed transaction will be spending a set of unspent TxOuts available in the blockchain.  The full transactions containing these TxOuts will be serialized and included, as well.  This so that the values of the TxIns can be verified before signing (the prev-tx-hash is part of the data being signed, but the value is not).  By including the full tx, the signing party can verify that the tx matches the OutPoint hash, and then verify input values, all without any access to the blockchain.
-#  The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58.  This is a specific naming convention to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected).  The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID. 
+#  The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58.  This is a specific naming convention to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected).  The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID.
 #  The TxDP will have an potentially-unordered list of sig-pubkey pairs which represent collected signatures.  If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it.
 #  Identical TxDP objects with different signatures can be easily combined.  This allows one party to send out all the requests for signatures at once, and combine them all when they are received (instead of having to "pass it around".
 #  For cases where the TxDP might be put into a file or sent via email, it should use .txdp or .btcdp suffix
 
 Anyone adopting BIP 0010 for multi-sig transactions will use the following format (without indentation):
 
+
  '-----BEGIN-TRANSACTION-TXDPID-------'
  ("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
     (serializedTxListInHex_Line1)
     (serializedTxListInHex_Line2)
-    (serializedTxListInHex_Line3) 
+    (serializedTxListInHex_Line3)
     ...
  ("_TXINPUT_") (00) (InputValue)
     ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
@@ -50,10 +49,11 @@ Anyone adopting BIP 0010 for multi-sig transactions will use the following forma
     (SigHexRemainingLines)
  ("_TXINPUT_") (02) (InputValue)
  '-------END-TRANSACTION-TXDPID-------'
-
+

 
 The following is an example TxDP from Armory, produced while running on the test network.  Its DPID is 3fX59xPj:
 
+
-----BEGIN-TRANSACTION-3fX59xPj------------------------------------------------- _TXDIST_fabfb5da_3fX59xPj_00a0 010000000292807c8e70a28c687daea2998d6273d074e56fa8a55a0b10556974cf2b526e61000000 @@ -86,8 +86,7 @@ The following is an example TxDP from Armory, produced while running on the test 456298a566aa76fefeab8a7cb7a91e8a936a11757c911b4c669f0434d12ab0936fc13986b156156f 9b389ed244bbb580112be07dbe23949a4764dffb -------END-TRANSACTION-3fX59xPj------------------------------------------------- - - + In this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC. This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005. In this TxDP, both inputs have been signed, and thus could broadcast immediately. @@ -97,7 +96,5 @@ A party receiving this TxDP can simply add their signature to the appropriate _T == Reference Implementation == -This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction), and will eventually use it for multi-signature transcations. The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project]. Specifically, the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4704 PyTxDistProposal class] implements all features of BIP 0010. It contains reference code for both +This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction), and will eventually use it for multi-signature transcations. The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project]. Specifically, the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4704 PyTxDistProposal class] implements all features of BIP 0010. It contains reference code for both [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5095 serializing a TxDP] and [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5143 unserializing a TxDP]. - -[[Category:BIP|D]] diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki index b58cffbb..6a4edbe4 100644 --- a/bip-0011.mediawiki +++ b/bip-0011.mediawiki @@ -1,5 +1,3 @@ -{{bip}} - 
   BIP: 11
   Title: M-of-N Standard Transactions
@@ -58,5 +56,3 @@ https://github.com/gavinandresen/bitcoin-git/tree/op_eval
 == Post History ==
 
 * [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal]
-
-[[Category:BIP|C]]
diff --git a/bip-0012.mediawiki b/bip-0012.mediawiki
index 7fee6de1..922283a5 100644
--- a/bip-0012.mediawiki
+++ b/bip-0012.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
 
   BIP: 12
   Title: OP_EVAL
@@ -83,5 +81,3 @@ https://bitcointalk.org/index.php?topic=46538
 "Bitcoin Address 01" BIP
 
 M-of-N Multisignature Transactions BIP 11
-
-[[Category:BIP|W]]
diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki
index 2806584e..ce71a6a4 100644
--- a/bip-0013.mediawiki
+++ b/bip-0013.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
 
   BIP: 13
   Title: Address Format for pay-to-script-hash
@@ -8,6 +6,7 @@
   Type: Standards Track
   Created: 18-10-2011
 

+
 ==Abstract==
 
 This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions.  Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin.
@@ -30,7 +29,7 @@ And the 4-byte checksum is the first four bytes of the SHA256 hash of the versio
 
 ==Rationale==
 
-One criticism is that bitcoin addresses should be deprecated in favor of a more user-friendly mechanism for payments, and that this will just encourage continued use of a poorly designed mechanism. 
+One criticism is that bitcoin addresses should be deprecated in favor of a more user-friendly mechanism for payments, and that this will just encourage continued use of a poorly designed mechanism.
 
 Another criticism is that bitcoin addresses are inherently insecure because there is no identity information tied to them; if you only have a bitcoin address, how can you be certain that you're paying who or what you think you're paying?
 
@@ -52,9 +51,6 @@ See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src
 
 ==See Also==
 
-* [[BIP 0012|BIP 12: OP_EVAL, the original P2SH design]]
-* [[BIP 0016|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
-* [[BIP 0017|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]]
-
-[[Category:BIP|D]]
-[[Category:Security]]
+* [[bip-0012.mediawiki|BIP 12: OP_EVAL, the original P2SH design]]
+* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
+* [[bip-0017.mediawiki|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]]
diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki
index d95ecb07..8673d299 100644
--- a/bip-0014.mediawiki
+++ b/bip-0014.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
 
   BIP: 14
   Title: BIP Protocol Version and User Agent
@@ -89,5 +87,3 @@ They should not be misused beyond what is specified in this section.
 == Timeline ==
 
 When this document was published, the bitcoin protocol and Satoshi client versions were currently at 0.5 and undergoing changes. In order to minimise disruption and allow the undergoing changes to be completed, the next protocol version at 0.6 became peeled from the client version (also at 0.6). As of that time (January 2012), protocol and implementation version numbers are distinct from each other.
-
-[[Category:BIP|C]]
diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki
index 9750c8b1..1ec6f125 100644
--- a/bip-0015.mediawiki
+++ b/bip-0015.mediawiki
@@ -1,15 +1,13 @@
-{{bip}}
-
 
   BIP: 15
   Title: BIP Aliases
   Author: Amir Taaki 
-  Status: Deferred 
+  Status: Deferred
   Type: Standards Track
   Created: 10-12-2011
 

 
-[[BIP 0070]] (payment protocol) may be seen as the alternative to Aliases.
+[[bip-0070.mediawiki|BIP 0070]] (payment protocol) may be seen as the alternative to Aliases.
 
 Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.
 
@@ -97,7 +95,7 @@ It also scales reasonably- anybody wishing to run a naming service can attach a
 
 A naive implementation is provided below as an example.
 
-
+
 // resolv.h
 #ifndef NOMRESOLV_H__
 #define NOMRESOLV_H__
@@ -151,7 +149,7 @@ private:
     bool Perform();
 
     // CURL error message
-    char pErrorBuffer[CURL_ERROR_SIZE];  
+    char pErrorBuffer[CURL_ERROR_SIZE];
     // CURL response
     string strBuffer;
     // CURL handle
@@ -159,9 +157,9 @@ private:
 };
 
 #endif
-
+

 
-
+
 // resolv.cpp
 #include "resolv.h"
 
@@ -170,16 +168,16 @@ private:
 #include "access.h"
 
 // callback used to write response from the server
-static int writer(char *pData, size_t nSize, size_t nNmemb, std::string *pBuffer)  
-{  
-  int nResult = 0;  
-  if (pBuffer != NULL)  
-  {  
-    pBuffer->append(pData, nSize * nNmemb);  
-    // How much did we write?  
-    nResult = nSize * nNmemb;  
-  }  
-  return nResult;  
+static int writer(char *pData, size_t nSize, size_t nNmemb, std::string *pBuffer)
+{
+  int nResult = 0;
+  if (pBuffer != NULL)
+  {
+    pBuffer->append(pData, nSize * nNmemb);
+    // How much did we write?
+    nResult = nSize * nNmemb;
+  }
+  return nResult;
 }
 
 NameResolutionService::NameResolutionService()
@@ -187,17 +185,17 @@ NameResolutionService::NameResolutionService()
     // Initialise CURL with our various options.
     curl = curl_easy_init();
     // This goes first in case of any problems below. We get an error message.
-    curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, pErrorBuffer);  
+    curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, pErrorBuffer);
     // fail when server sends >= 404
-    curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1);  
-    curl_easy_setopt(curl, CURLOPT_HEADER, 0);  
-    curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1);  
+    curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1);
+    curl_easy_setopt(curl, CURLOPT_HEADER, 0);
+    curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1);
     curl_easy_setopt(curl, CURLOPT_POSTREDIR, CURL_REDIR_POST_302);
-    curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writer);  
+    curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writer);
     curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_TRY);
     curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);
     // server response goes in strBuffer
-    curl_easy_setopt(curl, CURLOPT_WRITEDATA, &strBuffer);  
+    curl_easy_setopt(curl, CURLOPT_WRITEDATA, &strBuffer);
     pErrorBuffer[0] = '\0';
 }
 NameResolutionService::~NameResolutionService()
@@ -215,7 +213,7 @@ void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNi
 bool NameResolutionService::Perform()
 {
     // Called after everything has been setup. This actually does the request.
-    CURLcode result = curl_easy_perform(curl);  
+    CURLcode result = curl_easy_perform(curl);
     return (result == CURLE_OK);
 }
 
@@ -235,7 +233,7 @@ string NameResolutionService::FetchAddress(const string& strHandle, string& strA
     // construct url for GET request
     string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + pszEncodedNick;
     // Pass URL to CURL
-    curl_easy_setopt(curl, CURLOPT_URL, strRequestUrl.c_str());  
+    curl_easy_setopt(curl, CURLOPT_URL, strRequestUrl.c_str());
     if (!Perform())
         return pErrorBuffer;
     // Server should respond with a JSON that has the address in.
@@ -279,7 +277,7 @@ const Object CheckMaybeThrow(const string& strJsonIn)
     // Now check for a key called "error"
     const Value& error  = find_value(request, "error");
     // It's an error JSON! so propagate the error.
-    if (error.type() != null_type)   
+    if (error.type() != null_type)
         throw JSONRPCError(-4, error.get_str());
     // Return JSON object
     return request;
@@ -290,7 +288,7 @@ const string CollectAddress(const string& strIn)
     // If the handle does not have an @ in it, then it's a normal base58 bitcoin address
     if (strIn.find('@') == (size_t)-1)
         return strIn;
-    
+
     // Open the lookup service
     NameResolutionService ns;
     // We established that the input string is not a BTC address, so we use it as a handle now.
@@ -314,7 +312,7 @@ Value rpc_send(const Array& params, bool fHelp)
         throw runtime_error(
             "send  \n"
             " is a real and is rounded to the nearest 0.01");
-    
+
     // Intelligent function which looks up address given handle, or returns address
     string strAddy = CollectAddress(params[0].get_str());
     int64 nAmount = AmountFromValue(params[1]);
@@ -327,7 +325,7 @@ Value rpc_send(const Array& params, bool fHelp)
 }
 
 ...
-
+

 
 === IP Transactions ===
 
@@ -369,7 +367,7 @@ Two examples are presented below. The first shows a simpler format, while the se
 
 '''More possibilities :'''
 
-* Allow to securely use '''unsecured channels''' 
+* Allow to securely use '''unsecured channels'''
 You can put an url and a bitcoin address that will be used to sign the result. It means that a query to this url will return a bitcoin address and a signature. Bitcoin can then check (with the verify_message function) that the returned address has not been replaced by another one.
  $ namecoind name_show id/khal
  {
diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki
index 3034f678..c99f5e13 100644
--- a/bip-0016.mediawiki
+++ b/bip-0016.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
 
   BIP: 16
   Title: Pay to Script Hash
@@ -90,7 +88,7 @@ Avoiding a block-chain split by malicious pay-to-script transactions requires ca
 
 * A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.
 
-To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time. 
+To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
 
 To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create.
 
@@ -110,6 +108,4 @@ https://gist.github.com/gavinandresen/3966071
 * [[bip-0016/qa.mediawiki|Quality Assurance test checklist]]
 
 == References ==
-
-
-[[Category:BIP|D]]
+
diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki
index d10ab8a9..fa13c0b4 100644
--- a/bip-0017.mediawiki
+++ b/bip-0017.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
 
   BIP: 17
   Title: OP_CHECKHASHVERIFY (CHV)
@@ -98,8 +96,6 @@ OP_NOP2 is used, so existing OP_EVAL (BIP 12) transactions in the block chain ca
 
 ==See Also==
 
-* The [[BIP 0013|Address format for Pay to Script Hash BIP]]
-* [[BIP 0011|M-of-N Multisignature Transactions (BIP 11)]]
+* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]]
+* [[bip-0011.mediawiki|M-of-N Multisignature Transactions (BIP 11)]]
 * Example BIP 17 transaction chain: [http://blockexplorer.com/tx/b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d a] [http://blockexplorer.com/tx/eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb b] [http://blockexplorer.com/tx/055707ce7fea7b9776fdc70413f65ceec413d46344424ab01acd5138767db137 c] [http://blockexplorer.com/tx/6d36bc17e947ce00bb6f12f8e7a56a1585c5a36188ffa2b05e10b4743273a74b d]
-
-[[Category:BIP|D]]
diff --git a/bip-0018.mediawiki b/bip-0018.mediawiki
index d102aff5..c0d80821 100644
--- a/bip-0018.mediawiki
+++ b/bip-0018.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
 
   BIP: 18
   Title: hashScriptCheck
@@ -123,8 +121,6 @@ https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash
 
 ==See Also==
 
-* The [[BIP 0013|Address format for Pay to Script Hash BIP]]
-* [[BIP 16|BIP 16 - Pay to Script Hash (aka "/P2SH/")]]
-* M-of-N Multisignature Transactions [[BIP 0011|BIP 11]]
-
-[[Category:BIP]]
+* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]]
+* [[bip-0016.mediawiki|BIP 16 - Pay to Script Hash (aka "/P2SH/")]]
+* M-of-N Multisignature Transactions [[bip-0011.mediawiki|BIP 11]]
diff --git a/bip-0019.mediawiki b/bip-0019.mediawiki
index b653de8e..2255313b 100644
--- a/bip-0019.mediawiki
+++ b/bip-0019.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
 
   BIP: 19
   Title: M-of-N Standard Transactions (Low SigOp)
@@ -60,12 +58,10 @@ scriptSig:
 ==Rationale==
 
 OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases.
-This is already specified in [[BIP 0011]].
+This is already specified in [[bip-0011.mediawiki|BIP 0011]].
 However, each OP_CHECKMULTISIG counts toward the block limit as 20 sigops, which only allows 1000 total multisig transactions in a block.
 Using OP_CHECKSIG only counts as 1 per signature, so can scale better.
 
 ==Implementation==
 
 All used operations are already supported by old clients and miners as a non-standard transaction type.
-
-[[Category:BIP|C]]
diff --git a/bip-0020.mediawiki b/bip-0020.mediawiki
index 3bd2605f..53823e83 100644
--- a/bip-0020.mediawiki
+++ b/bip-0020.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
 
   BIP: 20
   Title: URI Scheme
@@ -57,7 +55,7 @@ Graphical bitcoin clients SHOULD register themselves as the handler for the "bit
 ==== Transfer amount/size ====
 
 If an amount is provided, it may be specified either in decimal or, when prefixed with a single "x" character, hexadecimal.
-The number SHOULD be followed by "X"  to signify an exponent to the base multiplier.
+The number SHOULD be followed by "X" <digits> to signify an exponent to the base multiplier.
 Thus, "X8" multiplies your number by 100,000,000.
 For decimal values, this means the standard BTC unit.
 For hexadecimal values, this means ᵇTBC units (which are equivalent to 42.94967296 BTC).
@@ -94,9 +92,11 @@ Make it possible for later generations to improve our work, to mend our errors,
 This section is non-normative and does not cover all possible syntax.
 Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.
 
-[foo] means optional,  are placeholders
+[foo] means optional, <bar> are placeholders
 
+
  bitcoin:
[;version=1.0][?amount=][?label=

 
 === Examples ===
 
@@ -129,15 +129,21 @@ Characters must be URI encoded properly.
 ===Sending money via private key===
 To send a payment to someone else first construct a new keypair. You may want to use a [[mini private key format]], or you may also use a full private key for more security depending on the amount being sent and how long you expect to pass before a claim. Now create and publish a transaction with an output of the amount you wish to send. Use this script in that output:
 
+
   OP_CHECKSIG
+

 
 Construct an address from the public key. Encode the URI as below:
 
+
  bitcoin:
?send=
+

 
-You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where 
 matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form:
+You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where <address> matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form:
 
+
  
+

 
 This claims the money you were sent. Until your claim transaction has confirmed the sender may take their money back.
 
@@ -147,6 +153,7 @@ This claims the money you were sent. Until your claim transaction has confirmed
 
 === Parsing amount ===
 ==== ECMAScript ====
+
  reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;
  function parseAmount(txt) {
     var m = txt.match(reAmount);
@@ -163,8 +170,10 @@ This claims the money you were sent. Until your claim transaction has confirmed
             (m[4] ? Math.pow(10, m[4]) : 1e8)
     );
  }
+

 
 ==== Python ====
+
  m = re.match(r'^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$', amount, re.IGNORECASE)
  if m.group(5):
      amount = float(int(m.group(5), 16))
@@ -180,8 +189,10 @@ This claims the money you were sent. Until your claim transaction has confirmed
          amount *= 10 ** int(m.group(4))
      else:
          amount *= 100000000
+

 
 ==== C# ====
+
  Regex amountExpression = new Regex(@"^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$", RegexOptions.IgnoreCase);
  Match match = amountExpression.Match(value);
  if (match.Success)
@@ -191,11 +202,11 @@ This claims the money you were sent. Until your claim transaction has confirmed
          long hexDecimal = 0;
          if (match.Groups[7].Success)
              hexDecimal = Convert.ToInt64(match.Groups[7].Value, 16) * (long)Math.Pow(16, -match.Groups[7].Length);
- 
+
          long hexExponent = 0x10000;
          if (match.Groups[9].Success)
              hexExponent = (long)Math.Pow(16, Convert.ToInt32(match.Groups[9].Value, 16));
- 
+
          Amount = (Convert.ToInt64(match.Groups[5].Value, 16) + hexDecimal) * hexExponent;
      }
      else
@@ -206,7 +217,4 @@ This claims the money you were sent. Until your claim transaction has confirmed
          Amount = (long)(decimal.Parse(match.Groups[2].Value) * decimalExponent);
      }
  }
-
-[[Category:Developer]]
-[[Category:Technical]]
-[[Category:BIP|D]]
+

diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki
index c4f3ef7a..8f2201be 100644
--- a/bip-0021.mediawiki
+++ b/bip-0021.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
 
   BIP: 21
   Title: URI Scheme
@@ -10,7 +8,7 @@
   Created: 29-01-2012
 

 
-This BIP is a modification of an earlier [[BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.
+This BIP is a modification of an earlier [[bip-0020.mediawiki|BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.
 
 ==Abstract==
 This BIP proposes a URI scheme for making Bitcoin payments.
@@ -72,7 +70,7 @@ Other proposed names sound much more cryptic; the chance that someone googles th
 Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.
 
 ==Forward compatibility==
-Variables which are prefixed with a req- are considered required.  If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid.  Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored.  
+Variables which are prefixed with a req- are considered required.  If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid.  Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored.
 
 ==Backward compatibility==
 As this BIP is written, several clients already implement a bitcoin: URI scheme similar to this one, however usually without the additional "req-" prefix requirement.  Thus, it is recommended that additional variables prefixed with req- not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade.
@@ -82,9 +80,9 @@ As this BIP is written, several clients already implement a bitcoin: URI scheme
 === Simpler syntax ===
 
 This section is non-normative and does not cover all possible syntax.
-Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.
+Please see the BNF grammar above for the normative syntax.
 
-[foo] means optional,  are placeholders
+[foo] means optional, <bar> are placeholders
 
  bitcoin:
[?amount=][?label=