Merge branch 'master' of github.com:genjix/bips

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
+  BIP: 10
+  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 (as a 1-of-1 transaction).  Armory does not have Multi-signature transaction support yet, but all the code is implemented, just untested.  The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project].  The PyTxDistProposal class implements all features of BIP 0010:
   
@@ -97,8 +91,7 @@ This proposal has been implemented and tested in the ''Armory'' Bitcoin software
 
 [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4795 Convert Completed TxDP to Broadcast-Tx]
 
-
-===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. Someone could create a TxDP and lie about the values of each input, knowing that the signing device will not be able to verify those values.  Since the final, serialized transaction does not include input values, the subsequent signature will be valid no matter what inputs values were provided.
 

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