BIP UNOFFICIAL DRAFT 0: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Piuk (talk | contribs)
Piuk (talk | contribs)
Line 31: Line 31:
Additionally a new standard scriptPubKey will be defined:
Additionally a new standard scriptPubKey will be defined:


     OP_HASH160 [20-byte-hash-value] OP_EQUAL
     OP_HASH160 [20-byte-hash-value] OP_EQUAL OP_CHECKMULTISIG


Redeemed by a new standard scriptSig (single key):
Redeemed by a new standard scriptSig (M-of-N)


    <sig> OP_NO_SKIP <OP_SWAP [pubkey] OP_CHECKSIG>
   OP_0  <sig> OP_NO_SKIP <OP_SWAP {1 [pubkey1] [pubkey2] 2}>
 
or (M-of-N)
 
   OP_0  <sig> OP_NO_SKIP <OP_SWAP {1 [pubkey1] [pubkey2] 2 OP_CHECKMULTISIG}>


==Example Execution==
==Example Execution==

Revision as of 01:41, 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 OP_CHECKMULTISIG

Redeemed by a new standard scriptSig (M-of-N)

  OP_0  <sig> OP_NO_SKIP <OP_SWAP {1 [pubkey1] [pubkey2] 2}>

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