BIP UNOFFICIAL DRAFT 0

From Bitcoin Wiki
Revision as of 23:51, 14 January 2012 by Piuk (talk | contribs)
Jump to: navigation, search
  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 execute 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

http://pastehtml.com/view/bkqo1blp8.html

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 validate that the {script}'s hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation.

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