(but please do not cross-post!).
+
+For each new BIP that comes in an editor does the following:
+
+* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
+* The title should accurately describe the content.
+* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7).
+
+If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
+
+Once the BIP is ready for the repository, the BIP editor will:
+
+* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141).
+
+* List the BIP in BIP 0 (in two places: the categorized list, and the numeric list).
+
+* Add the BIP to the wiki.
+
+* Send email back to the BIP author with next steps (post to bitcoin mailing list).
+
+Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
+
+The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume.
+
+==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.
+
diff --git a/bip-0011.txt b/bip-0011.txt
new file mode 100644
index 00000000..e5257ba2
--- /dev/null
+++ b/bip-0011.txt
@@ -0,0 +1,57 @@
+
+ BIP: 11
+ Title: M-of-N Standard Transactions
+ Author: Gavin Andresen
+ Status: Draft
+ Type: Standards Track
+ Created: 18-10-2011
+ Post-History: 02-10-2011
+
+
+==Abstract==
+
+This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type.
+
+==Motivation==
+
+Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature.
+
+A couple of motivating use cases:
+
+* A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business.
+
+* Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).
If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP.
+
+==Specification==
+
+A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks:
+
+ m {pubkey}...{pubkey} n OP_CHECKMULTISIG
+
+But only for n less than or equal to 3.
+
+OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig:
+ OP_0 ...signatures...
+
+(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).
+
+==Rationale==
+
+OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases.
+
+One argument against using OP_CHECKMULTISIG is that old clients and miners count it as "20 sigops" for purposes of computing how many signature operations are in a block, and there is a hard limit of 20,000 sigops per block-- meaning a maximum of 1,000 multisig transactions per block. Creating multisig transactions using multiple OP_CHECKSIG operations allows more of them per block.
+
+The counter-argument is that these new multi-signature transactions will be used in combination with OP_EVAL (see the OP_EVAL BIP), and '''will''' be counted accurately. And in any case, as transaction volume rises the hard-coded maximum block size will have to be addressed, and the rules for counting number-of-signature-operations-in-a-block can be addressed at that time.
+
+A weaker argument is OP_CHECKMULTISIG should not be used because it pops one too many items off the stack during validation. Adding an extra OP_0 placeholder to the scriptSig adds only 1 byte to the transaction, and any alternative that avoids OP_CHECKMULTISIG adds at least several bytes of opcodes.
+
+==Implementation==
+
+OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type.
+
+https://github.com/gavinandresen/bitcoin-git/tree/op_eval
+
+== Post History ==
+
+* [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal]
+
diff --git a/bip-0012.txt b/bip-0012.txt
new file mode 100644
index 00000000..2ef52633
--- /dev/null
+++ b/bip-0012.txt
@@ -0,0 +1,84 @@
+
+ BIP: 12
+ Title: OP_EVAL
+ Author: Gavin Andresen
+ Status: Draft
+ Type: Standards Track
+ Created: 18-10-2011
+
+
+==Abstract==
+
+This BIP describes a new opcode (OP_EVAL) for the [https://en.bitcoin.it/wiki/Script Bitcoin scripting system], and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them.
+
+==Motivation==
+
+Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners.
+
+==Specification==
+
+OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows:
+
+* When executed during transaction verification, pops the item from the top of the stack, deserializes it, and executes the resulting script.
+* If there is no item on the top of the stack or the item is not a valid script then transaction validation fails.
+* If there are any OP_CODESEPARATORs in the deserialized script then transaction validation fails.
+* If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2.
+* Transaction verification must fail if interpreting OP_EVAL as a no-op would cause the verification to fail.
+
+A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks is also defined:
+
+ DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL
+
+Which is redeemed by a standard scriptSig:
+ ...signatures... {serialized script}
+
+Transactions that redeem standard OP_EVAL scriptPubKeys are only considered standard if the ''serialized script'' is, itself, one of the standard transaction types.
+
+==Rationale==
+
+OP_EVAL allows the receiver of bitcoins to specify how they can be spent when they are spent, instead of requiring the sender of the bitcoins to know the details of how the bitcoins may be redeemed. The sender only needs to know the hash of the ''serialized script'', and one new type of bitcoin address can be used to fund arbitrarily complex transactions.
+
+If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver.
+
+The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties.
+
+That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure.
+
+There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is:
+
+# Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients.
+# Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim.
+# Attacker manages to mine a block that contains both transactions. If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block.
+
+The attack is expensive because it requires the attacker create a block that they know will be invalidated. It is difficult because bitcoin businesses should not accept 1-confirmation transactions for higher-value transactions.
+
+==Backwards Compatibility==
+
+Surprisingly, because OP_EVAL redefines the OP_NOP1 opcode, standard OP_EVAL transactions will validate with old clients and miners. They will check only that the ''serialized script'' hashes to the correct value; the OP_EVAL will be interpreted as a no-op, and as long as the hash is correct the transaction will be considered valid (no signature checking will be done by old clients and miners).
+
+Old clients will ignore OP_EVAL transactions and transactions that depend on them until they are put into a block by either an old miner that includes non-standard transactions in its blocks or by a new miner.
+
+Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases:
+
+# An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners.
+# An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners.
+
+For case (1), new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012. Before then, miners will be asked to put the string "OP_EVAL" in blocks that they produce so that hashing power that supports the new opcode can be gauged. If less than 50% of miners accept the change as of January 15, 2012 the rollout will be postponed until more than 50% of hashing power supports OP_EVAL (the rollout will be rejected if it becomes clear that a majority of hashing power will not be achieved).
+
+For case (2), new clients and miners will be written to make sure that transactions involving OP_EVAL are valid if OP_EVAL is interpreted as a no-op.
+Example of a transaction that must fail for both old and new miners/clients:
+ scriptSig: {serialized OP_11}
+ scriptPubKey: OP_EVAL OP_11 OP_EQUAL
+
+==Reference Implementation==
+
+https://github.com/gavinandresen/bitcoin-git/tree/op_eval
+
+==See Also==
+
+https://bitcointalk.org/index.php?topic=46538
+
+"Bitcoin Address 01" BIP
+
+M-of-N Multisignature Transactions BIP 11
+
diff --git a/bip-0013.txt b/bip-0013.txt
new file mode 100644
index 00000000..1b08085f
--- /dev/null
+++ b/bip-0013.txt
@@ -0,0 +1,52 @@
+
+ BIP: 13
+ Title: Address Format for OP_EVAL
+ Author: Gavin Andresen
+ Status: Pre-Draft
+ 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.
+
+In essence, an address encoded under this proposal represents the encoded hash of a script, rather than the encoded hash of an ECDSA [[public key]].
+
+==Motivation==
+
+Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services.
+
+==Specification==
+
+The new bitcoin address type is constructed in the same manner as existing bitcoin addresses:
+
+ base58-encode: [one-byte version][20-byte hash][4-byte checksum]
+
+Version byte is 1 for a main-network address, 112 for a testnet address.
+The 20-byte hash is the hash of the script that will be used to redeem the coins.
+And the 4-byte checksum is the first four bytes of the SHA256 hash of the version and hash.
+
+==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.
+
+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?
+
+Furthermore, truncating SHA256 is not an optimal checksum; there are much better error-detecting algorithms. If we are introducing a new form of Bitcoin address, then perhaps a better algorithm should be used.
+
+This is one piece of the simplest path to a more secure bitcoin infrastructure. It is not intended to solve all of bitcoin's usability or security issues, but to be an incremental improvement over what exists today. A future BIP or BIPs should propose more user-friendly mechanisms for making payments, or for verifying that you're sending a payment to the Free Software Foundation and not Joe Random Hacker.
+
+Assuming that typing in bitcoin addresses manually will become increasingly rare in the future, and given that the existing checksum method for bitcoin addresses seems to work "well enough" in practice and has already been implemented multiple times, the Author believes no change to the checksum algorithm is necessary.
+
+==Backwards Compatibility==
+
+This proposal is not backwards compatible, but it fails gracefully-- if an older implementation is given one of these new bitcoin addresses, it will report the address as invalid and will refuse to create a transaction.
+
+==Reference Implementation==
+
+https://github.com/gavinandresen/bitcoin-git/tree/op_eval
+
+==See Also==
+
+The OP_EVAL BIP.
+