1 files changed, 102 insertions, 0 deletions
diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki
new file mode 100644
index 0000000..0cd5d70
--- /dev/null
+++ b/bip-0017.mediawiki
@@ -0,0 +1,102 @@
+<pre>
+  BIP: 17
+  Title: OP_CHECKHASHVERIFY (CHV)
+  Author: Luke Dashjr <luke+bip17@dashjr.org>
+  Status: Withdrawn
+  Type: Standards Track
+  Created: 18-01-2012
+</pre>
+
+==Abstract==
+
+This BIP describes a new opcode (OP_CHECKHASHVERIFY) for the 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==
+
+The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.
+
+The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.
+
+==Specification==
+
+OP_CHECKHASHVERIFY will re-define the existing OP_NOP2 opcode, and will function as follows when executed:
+
+* First, hash the end of the prior script (in the general case, scriptSig; if no prior script, a null string is hashed) beginning from the last evaluated OP_CODESEPARATOR onward (or from the beginning of the script, if no OP_CODESEPARATOR was present)
+* Then, compare this with the item on the top of the stack (if there is none, the script fails immediately)
+* If the hashes match, do nothing, proceed as if an OP_NOP; if they do not match, the script fails immediately.
+* Note that in the case of a matched hash, the top stack item (the hash being compared with) is <u>not</u> popped off the stack. This is for backward compatibility.
+
+This opcode reassignment shall be applied when validating transactions in blocks only with timestamps after February 20, 2012 (see the Backwards Compatibility section for details).
+
+A new standard transaction type that is relayed and included in mined blocks is defined:
+
+    [20-byte-hash-value] OP_CHECKHASHVERIFY OP_DROP
+
+[20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes.
+
+This new transaction type is redeemed by a standard scriptSig:
+
+    ...signatures... OP_CODESEPARATOR {script}
+
+Transactions that redeem these pay-to-script outpoints are only considered standard if they contain exactly one OP_CODESEPARATOR and the appended ''script'' is, itself, one of the other standard transaction types.
+
+==Example==
+
+For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is:
+
+    scriptSig: [signature] OP_CODESEPARATOR [pubkey] OP_CHECKSIG
+    scriptPubKey: [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_CHECKHASHVERIFY OP_DROP
+
+2-of-3:
+
+    scriptSig: [signatures...] OP_CODESEPARATOR 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG
+    scriptPubKey: [20-byte-hash of {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} ] OP_CHECKHASHVERIFY OP_DROP
+
+==Rationale==
+
+This BIP replaces BIP 12 and BIP 16, which propose evaluating a Script from the stack after verifying its hash.
+
+The Motivation for this BIP (and BIP 13, the pay-to-script-hash address type) is somewhat controversial; several people feel that it is unnecessary, and complex/multisignature transaction types should be supported by simply giving the sender the complete {serialized script}. The author believes that this BIP will minimize the changes needed to all of the supporting infrastructure that has already been created to send funds to a base58-encoded-20-byte bitcoin addresses, allowing merchants and exchanges and other software to start supporting multisignature transactions sooner.
+
+There is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is:
+
+# Attacker creates a pay-to-script-hash transaction that is valid as seen by old software, but invalid for new implementation, and sends themselves some coins using it.
+# Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software.
+# Attacker mines 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 by the rest of the network. It is difficult because creating blocks is difficult and users should not accept 1-confirmation transactions for higher-value transactions.
+
+==Backwards Compatibility==
+
+These transactions are non-standard to old implementations, which will (typically) not relay them nor include them in blocks.
+
+Old implementations will not validate that the {script}'s hash value matches when they validate blocks created by software that fully support this BIP.
+
+Avoiding a block-chain split by malicious pay-to-script transactions requires careful handling of one case:
+
+* 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 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/CHV" in the input of the coinbase transaction for blocks that they create.
+
+On February 3, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If at least 60% contain "p2sh/CHV" in their coinbase, then all blocks with timestamps after 18 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions validated.
+
+If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved).
+
+OP_NOP2 is used, so existing OP_EVAL (BIP 12) transactions in the block chain can still be redeemed.
+
+==Reference Implementation==
+
+[https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify Validation, sending, and receiving for bitcoind git master]
+
+[https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify_backport Validation only for 0.3.19+]
+
+==See Also==
+
+* The [[BIP 0013|Address format for Pay to Script Hash BIP]]
+* [[BIP 0011|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]
+