BIP: 17 Layer: Consensus (soft fork) Title: OP_CHECKHASHVERIFY (CHV) Author: Luke Dashjr <luke+bip17@dashjr.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0017 Status: Withdrawn Type: Standards Track Created: 2012-01-18 License: BSD-2-Clause
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.
This BIP is licensed under the BSD 2-clause license.
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.
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 not popped off the stack. This is for backward compatibility.
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.
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
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.
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.
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 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.
Validation, sending, and receiving for bitcoind git master
- The Address format for Pay to Script Hash BIP
- M-of-N Multisignature Transactions (BIP 11)
- Example BIP 17 transaction chain: a b c d