|
|
| Line 10: |
Line 10: |
| </pre> | | </pre> |
|
| |
|
| ==Abstract==
| | {{BipMoved|bip-0017.mediawiki|BIP 0017}} |
| | |
| 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 23, 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 8, 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 23 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]
| |
|
| |
|
| [[Category:BIP|D]] | | [[Category:BIP|D]] |
|
This page describes a BIP (Bitcoin Improvement Proposal).
Please see BIP 2 for more information about BIPs and creating them. Please do not just create a wiki page.
|
BIP: 17
Title: OP_CHECKHASHVERIFY (CHV)
Author: Luke Dashjr <luke+bip17@dashjr.org>
Status: Draft
Type: Withdrawn
Created: 18-01-2012
|
Please do not modify this page. This is a mirror of the BIP from the source Git repository here.
|