BIP UNOFFICIAL DRAFT 0: Difference between revisions
Line 27: | Line 27: | ||
* OP_NO_SKIP remains a null op on its own. | * OP_NO_SKIP remains a null op on its own. | ||
* Any "push data" operation immediately following an OP_NO_SKIP will push the data onto the stack as normal but will not advance the instruction pointer i.e. the data will be pushed onto the stack and | * Any "push data" operation immediately following an OP_NO_SKIP will push the data onto the stack as normal but will not advance the instruction pointer i.e. the data will be pushed onto the stack and executed after. | ||
Additionally a new standard scriptPubKey will be defined: | Additionally a new standard scriptPubKey will be defined: |
Revision as of 00:51, 15 January 2012
BIP: 17 Title: OP_NO_SKIP Author: Ben Reeves <support@pi.uk.com> Status: Draft Type: Standards Track Created: 14-01-2012
Abstract
This BIP describes a new op code ("OP_NO_SKIP") and a new type of standard transaction.
Motivation
The purpose of this propose is to provide pay to script functionality without making a standard templates a mandatory part of the scripting language.
Quote BIP_0016:
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_NOP1 will be redefined as OP_NO_SKIP and will behave as follows:
- OP_NO_SKIP remains a null op on its own.
- Any "push data" operation immediately following an OP_NO_SKIP will push the data onto the stack as normal but will not advance the instruction pointer i.e. the data will be pushed onto the stack and executed after.
Additionally a new standard scriptPubKey will be defined:
OP_HASH160 [20-byte-hash-value] OP_EQUAL
Redeemed by a new standard scriptSig (single key):
<sig> OP_NO_SKIP <OP_SWAP [pubkey] OP_CHECKSIG>
or (M-of-N)
OP_0 <sig> OP_NO_SKIP <OP_SWAP {1 [pubkey1] [pubkey2] 2 OP_CHECKMULTISIG}>
Example Execution
Basic example:
Stack | Code |
---|---|
OP_NO_SKIP OP_PUSHDATA1 1 OP_1NEGATE OP_ADD | |
OP_PUSHDATA1 1 OP_1NEGATE OP_ADD | |
79 | OP_1NEGATE OP_ADD |
79 -1 | OP_ADD |
78 |
Pay to script example:
Stack | Code |
---|---|
32 <sig> OP_NO_SKIP 22 <OP_SWAP [pubkey] OP_CHECKSIG> OP_HASH160 20 <scriptHash> OP_EQUAL | |
<sig> | OP_NO_SKIP 22 <OP_SWAP [pubkey] OP_CHECKSIG> OP_HASH160 20 <scriptHash> OP_EQUAL |
<sig> | 22 <OP_SWAP [pubkey] OP_CHECKSIG> OP_HASH160 20 <scriptHash> OP_EQUAL |
<sig> <OP_SWAP [pubkey] OP_CHECKSIG> | OP_SWAP [pubkey] OP_CHECKSIG OP_HASH160 20 <scriptHash> OP_EQUAL |
<OP_SWAP [pubkey] OP_CHECKSIG> <sig> | [pubkey] OP_CHECKSIG OP_HASH160 20 <scriptHash> OP_EQUAL |
<OP_SWAP [pubkey] OP_CHECKSIG> | OP_HASH160 20 <scriptHash> OP_EQUAL |
<scriptHashA> | 20 <scriptHash> OP_EQUAL |
<scriptHashA> <scriptHash> | OP_EQUAL |
1 |
Rationale
This BIP replaces BIP 12 ("P2SH") and BIP 16, ("OP_EVAL").
The rationale for pay to script functionality has been discussed in the other proposals, the general consensus is this functionality is desired and should be implemented ASAP.
A number of potential issues have been found with the proposals thus far:
- CHV/CHC require the scriptPubKey interacts with data from scriptSig which has not been push onto the stack
- OP_EVAL essentially makes the scripting language turing complete, something which Satoshi deliberately avoided during its design.
- P2SH requires that standard templates become a mandatory part of the scripting language, meaning they can never be fully depreciated in future.
OP_NO_SKIP is designed to be a simple compromise that enables pay to script functionality without giving the language any extra expressive powers or violating the rules of a simple stack based language.
Backwards Compatibility
These transactions are non-standard to old implementations, which will (typically) not relay them or include them in blocks.
Old implementations will push the script onto the stack and verify it's hash value matches, but will do no other validation. New client will push the script on to the stack AND execute it.
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 "/OPNOSKIP/" in the input of the coinbase transaction for blocks that they create.
On February 1, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/OPNOSKIP/" in their coinbase, then all blocks with timestamps after 15 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.
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).
Reference Implementation
https://github.com/zootreeves/bitcoin/commits/master
See Also
- https://bitcointalk.org/index.php?topic=46538
- The Address format for Pay to Script Hash BIP
- M-of-N Multisignature Transactions BIP 11