Rename to mediawiki extension

1 files changed, 98 insertions, 0 deletions

diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki
new file mode 100644
index 0000000..bd96ed6
--- /dev/null
+++ b/bip-0010.mediawiki
@@ -0,0 +1,98 @@
+<pre>
+  BIP: 10
+  Title: Multi-Sig Transaction Distribution
+  Author: Alan Reiner  
+  Status: Draft 
+  Type: Informational
+  Created: 28-10-2011
+</pre>
+
+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==
+
+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==
+
+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
+#  Transaction preparation -- the user creating the TxDP will create the transaction as they would like to see it spent (obviously without the signatures).  Then they will go through each input and replace its script with the script of the txout that the input is spending.  The reason for is so that ''receiving parties can sign with their private key without needing access to the blockchain.'' 
+#  This TxDP will be serialized (see below), which will include a tag identifying the TxDP in the serialization, as well as in the filename, if it is saved to file.
+#  The TxDP will have an "DP ID" which is the hash of the TxDP in Base58 -- the reason for the specific naming convention is 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 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
+#  For cases where the TxDP might be put into a file to be 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)
+        (preparedTxSerializedHexLine0)
+        (preparedTxSerializedHexLine1)
+        (preparedTxSerializedHexLine2) 
+        ...
+     ("_TXINPUT_") (00) (InputValue)
+        ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
+        (SigHexRemainingLines)
+        ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
+        (SigHexRemainingLines)
+     ("_TXINPUT_") (01) (InputValue)
+        ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
+        (SigHexRemainingLines)
+     ("_TXINPUT_") (02) (InputValue)
+     '-------END-TRANSACTION-TXDPID-------'
+
+A multi-signature proposal that has 3 signatures on it could be stored in a file "Tx_QrtZ3K42n.txdp" and it would look something like:
+
+ '''-----BEGIN-TXDP-----'''
+ '''_TXDIST_f9beb4d9_QrtZ3K42n_fda5'''
+ 204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e642062 
+ 61696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104 
+ 678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6 
+ 49f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f 
+ ac00000000f9beb4d9d7000000010000006fe28c0ab6f1b372c1a6a246ae63f7 
+ 4f931e8365e15a089c68d6190000000000982051fd1e4ba744bbbe680e1fee14 
+ 677ba1a3c3540bf7b1cdb606e857233e0e61bc6649ffff001d01e36299010100 
+ fe328f9a3920119cbd3f1311f830039832abb3baf284625151f328f9a3920
+ '''_TXINPUT_00_23.13000000'''
+ _SIG_1Gffm3Kj3_02_7e_fa8d9127149200f568383a089c68d61900000000009
+ 8205bbbe680e1fee1467744bbbe680e1fee14677ba1a3c3540bf7b1cdb606e85
+ 7233e0e61bc6649
+ '''_TXINPUT_01_4.00000000'''
+ '''_TXINPUT_02_10.00000000'''
+ _SIG_1QRTt83p8_007f ffff00db606e857233e0e61bc6649ffff00db60831f9
+ 6efa8d9127149200f568383a089c68d619000000000098205bbbe680e1fee1
+ 46770e1fee14677ba1a3c35
+ _SIG_1m3Rk38fd_007f
+ ffff00db606e857233e0e61bc6649ffff00db606efa8d9127149200f568383a0
+ 89c68d619000000000098205bbbe680e1fee146770e1fee14677ba1a3c35
+ '''------END-TXDP------'''
+
+In this transaction, there are 3 inputs, providing 23.13, 4.0 and 10.0 BTC, respectively.  Input 0 has one signature, input 1 has zero signatures, and input 2 has two signatures.
+
+The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures.  This serialization is compact, and will be interpretted the same in all character encodings.  It can be copied inline into an email, or saved in a text file.  The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program/parser to simply determine the core elements of the TxDP.
+
+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 ==
+
+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:
+  
+[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4616 Create TxDP from list of unspent TxOuts]
+
+[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4840 Serialization of TxDP]
+
+[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4879 Unserialize a TxDP]
+
+[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4795 Convert Completed TxDP to Broadcast-Tx]
+
+==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.
+
+This is only a minor issue, since developers who are concerned about such "attacks" can choose to ignore non-signed fields in the TxDP.  Or, they can guarantee that all TxDPs will pass through a trusted system that ''does'' have access to the blockchain and can verify such information.