BIP UNOFFICIAL DRAFT 0: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Piuk (talk | contribs)
Giszmo (talk | contribs)
Added to category BIP
 
(10 intermediate revisions by 4 users not shown)
Line 3: Line 3:
   Title: OP_NO_SKIP
   Title: OP_NO_SKIP
   Author: Ben Reeves <support@pi.uk.com>
   Author: Ben Reeves <support@pi.uk.com>
   Status: Draft
   Status: Rejected
   Type: Standards Track
   Type: Standards Track
   Created: 14-01-2012
   Created: 14-01-2012
Line 35: Line 35:
Redeemed by a new standard scriptSig (M-of-N)
Redeemed by a new standard scriptSig (M-of-N)


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


==Example Execution==
==Example Execution==
Line 62: Line 62:
! Stack !! Code
! Stack !! Code
|-
|-
| || 32 <sig> OP_NO_SKIP 22 <OP_SWAP [pubkey] OP_CHECKSIG> OP_HASH160 20 <scriptHash> OP_EQUAL  
| || 32 <sig> OP_NO_SKIP 22 <OP_SWAP 1 [pubkey] 2> OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL  
|-
|-
| <sig> || OP_NO_SKIP 22 <OP_SWAP [pubkey] OP_CHECKSIG> OP_HASH160 20 <scriptHash> OP_EQUAL  
| <sig> || OP_NO_SKIP 22 <OP_SWAP 1 [pubkey] 2> OP_CHECKMULTISIGVERIFY  OP_HASH160 20 <scriptHash> OP_EQUAL  
|-
|-
| <sig> || 22 <OP_SWAP [pubkey] OP_CHECKSIG> OP_HASH160 20 <scriptHash> OP_EQUAL  
| <sig> || 22 <OP_SWAP 1 [pubkey] 2> OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL  
|-
|-
| <sig> <OP_SWAP [pubkey] OP_CHECKSIG> || OP_SWAP [pubkey] OP_CHECKSIG OP_HASH160 20 <scriptHash> OP_EQUAL  
| <sig> <OP_SWAP 1 [pubkey] 2> || OP_SWAP 1 [pubkey] 2 OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL  
|-
|-
| <OP_SWAP [pubkey] OP_CHECKSIG> <sig> || [pubkey] OP_CHECKSIG OP_HASH160 20 <scriptHash> OP_EQUAL  
| <OP_SWAP 1 [pubkey] 2> <sig> || 1 [pubkey] 2 OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL  
|-
|-
| <OP_SWAP [pubkey] OP_CHECKSIG> || OP_HASH160 20 <scriptHash> OP_EQUAL  
| <OP_SWAP 1 [pubkey] 2> || OP_HASH160 20 <scriptHash> OP_EQUAL  
|-
|-
| <scriptHashA> || 20 <scriptHash> OP_EQUAL  
| <scriptHashA> || 20 <scriptHash> OP_EQUAL  
Line 83: Line 83:
==Rationale==
==Rationale==


This BIP replaces BIP 12 ("P2SH") and BIP 16, ("OP_EVAL").
This BIP replaces BIP 12 ("OP_EVAL") and BIP 16, ("/P2SH/").


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.
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.
Line 89: Line 89:
A number of potential issues have been found with the proposals thus far:
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
* CHV requires 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.  
* 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.
* P2SH requires that standard templates become a mandatory part of the scripting language, meaning they can never be fully depreciated in future.
Line 116: Line 116:


https://github.com/zootreeves/bitcoin/commits/master
https://github.com/zootreeves/bitcoin/commits/master
==Reason for Rejection==
Any miner can easily confiscate transactions by replacing the legitmate signature script:
  OP_0  <sig> OP_NO_SKIP <OP_SWAP {1 [pubkey1] [pubkey2] 2} >
with
  <OP_SWAP {1 [pubkey1] [pubkey2] 2} > OP_0 <miner's_sig> OP_1 <miner's_pubkey> OP_1
==See Also==
==See Also==


Line 121: Line 132:
* The [[BIP 0013|Address format for Pay to Script Hash BIP]]
* The [[BIP 0013|Address format for Pay to Script Hash BIP]]
* M-of-N Multisignature Transactions [[BIP 0011|BIP 11]]
* M-of-N Multisignature Transactions [[BIP 0011|BIP 11]]
[[Category:BIP|R]]

Latest revision as of 18:31, 29 January 2012

  BIP: 17
  Title: OP_NO_SKIP
  Author: Ben Reeves <support@pi.uk.com>
  Status: Rejected
  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_CHECKMULTISIGVERIFY OP_HASH160 [20-byte-hash-value] OP_EQUAL

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 1 [pubkey] 2> OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<sig> OP_NO_SKIP 22 <OP_SWAP 1 [pubkey] 2> OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<sig> 22 <OP_SWAP 1 [pubkey] 2> OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<sig> <OP_SWAP 1 [pubkey] 2> OP_SWAP 1 [pubkey] 2 OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<OP_SWAP 1 [pubkey] 2> <sig> 1 [pubkey] 2 OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<OP_SWAP 1 [pubkey] 2> OP_HASH160 20 <scriptHash> OP_EQUAL
<scriptHashA> 20 <scriptHash> OP_EQUAL
<scriptHashA> <scriptHash> OP_EQUAL
1

Rationale

This BIP replaces BIP 12 ("OP_EVAL") and BIP 16, ("/P2SH/").

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 requires 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

Reason for Rejection

Any miner can easily confiscate transactions by replacing the legitmate signature script:

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

with

  <OP_SWAP {1 [pubkey1] [pubkey2] 2} > OP_0 <miner's_sig> OP_1 <miner's_pubkey> OP_1

See Also