Formatted BIP to have consistent styling.

bip-0010.md

@@ -1,27 +1,21 @@
-===BIP 0010 - Proposal for Standardized, Multi-Signature Transaction Execution===
-
 <pre>
    BIP: 10
-   Title:       Distribution Proposals for Multi-Sig Transactions
-   Author:      Alan Reiner  
-   Status:      Draft 
-   Type:        Standards Track
-   Created:     2011-10-28
+   Title: Multi-Sig Transaction Distribution
+   Author: Alan Reiner  
+   Status: Draft 
+   Type: Informational
+   Created: 28-10-2011
 </pre>
 
-===Abstract===
-
 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 final, 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 protocol to standardize the representation of proposal transactions and the subsequent collection of signatures to execute multi-signature transactions.  The goal is to encourage a standard that guarantees interoperability of all programs that implement it.  
 
-
-===Motivation===
+==Motivation==
 
 The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity.  Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently.  By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection.
 
-
-===Specification===
+==Specification==
 
 This BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations.  
 
@@ -85,7 +79,7 @@ The style of communication is taken directly from PGP/GPG, which uses blocks of
 
 A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line.  If that is the last signature required, they can broadcast it themselves.  Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP.  However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it should not be the recommended method for combining TxDPs.
 
-=== Reference Implementation ===
+== Reference Implementation ==
 
 This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing, and is prepared to be used for supporting multi-signature transactions in a future release.  As such, the ''Armory'' source code contains a working implementation of BIP 0010 for single-party transactions (for offline wallets), and the logic is implemented (but untested) for multi-signature transactions.
 
@@ -99,7 +93,6 @@ The source code can be found at:  https://github.com/etotheipi/BitcoinArmory/blo
 
 '''Finished TxDP to broadcast-Tx:'''  https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4795
 
-
-===Known Issues===
+==Known Issues==
 
 One of the reasons TxDPs are versatile, is the ability for a device to "understand" and sign a transaction '''without''' access to the blockchain.  However, this means that any information included in the TxDP that is not part of the final broadcast transaction (such as input values), cannot be verified by the device.  i.e. I can create a TxDP and lie about the values of each input, to mislead the dumb client into thinking that less money is coming from its own funds than actually are (unless the client has the blockchain and/or has been tracking each transaction).  This works, because the input values are not included in the final transaction, only the output values are actually signed by the device.  This is not a show-stopper issue for BIP 0010, as developers who are concerned about such "attacks" can choose to ignore such fields, or always receive TxDPs through a computer that does have access to the blockchain and can verify the non-signature-related information in it. 

bip-0014.md

@@ -1,6 +1,6 @@
 <pre>
   BIP: 14
-  Title: BIP Protocol Version and User Agent
+  Title: Protocol Version and User Agent
   Author: Amir Taaki <genjix@riseup.net>
           Patrick Strateman <bitcoin-bips@covertinferno.org>
   Status: Accepted

bip-0015.md

@@ -1,6 +1,6 @@
 <pre>
   BIP: 15
-  Title: BIP Aliases
+  Title: Aliases
   Author: Amir Taaki <genjix@riseup.net>
   Status: Deferred
   Type: Standards Track