Difference between revisions of "BIP 0011"

From Bitcoin Wiki
Jump to: navigation, search
(Motivation)
(Update BIP text with latest version from https://github.com/bitcoin/bips/blob/c134a853a9fc0657/bip-0011.mediawiki)
(18 intermediate revisions by 9 users not shown)
Line 1: Line 1:
 +
{{bip}}
 +
{{BipMoved|bip-0011.mediawiki}}
 +
 
<pre>
 
<pre>
 
   BIP: 11
 
   BIP: 11
 +
  Layer: Applications
 
   Title: M-of-N Standard Transactions
 
   Title: M-of-N Standard Transactions
 
   Author: Gavin Andresen <gavinandresen@gmail.com>
 
   Author: Gavin Andresen <gavinandresen@gmail.com>
   Status: Draft
+
  Comments-Summary: No comments yet.
 +
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0011
 +
   Status: Final
 
   Type: Standards Track
 
   Type: Standards Track
   Created: 18-10-2011
+
   Created: 2011-10-18
   Post-History: 02-10-2011
+
   Post-History: 2011-10-02
 
</pre>
 
</pre>
  
Line 21: Line 27:
 
* A wallet secured by a "wallet protection service" (WPS).  2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business.
 
* A wallet secured by a "wallet protection service" (WPS).  2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business.
  
* Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the seller to sign a transaction that sends the tied-up coins to the buyer. <br />  <br /> If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins.  Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP.
+
* Three-party escrow (buyer, seller, and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).<br />If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins.  Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP.
  
 
==Specification==
 
==Specification==
Line 35: Line 41:
  
 
(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).
 
(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).
 +
 +
The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accommodate 3-signature transactions, this will be increased to 500 bytes.
  
 
==Rationale==
 
==Rationale==
Line 46: Line 54:
 
A weaker argument is OP_CHECKMULTISIG should not be used because it pops one too many items off the stack during validation. Adding an extra OP_0 placeholder to the scriptSig adds only 1 byte to the transaction, and any alternative that avoids OP_CHECKMULTISIG adds at least several bytes of opcodes.
 
A weaker argument is OP_CHECKMULTISIG should not be used because it pops one too many items off the stack during validation. Adding an extra OP_0 placeholder to the scriptSig adds only 1 byte to the transaction, and any alternative that avoids OP_CHECKMULTISIG adds at least several bytes of opcodes.
  
==Backwards Compatibility==
+
==Implementation==
  
 
OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type.
 
OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type.
 
==Reference Implementation==
 
  
 
https://github.com/gavinandresen/bitcoin-git/tree/op_eval
 
https://github.com/gavinandresen/bitcoin-git/tree/op_eval
 
==See Also==
 
 
OP_EVAL BIP
 
  
 
== Post History ==
 
== Post History ==
  
 
* [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal]
 
* [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal]

Revision as of 07:57, 2 August 2020

This page describes a BIP (Bitcoin Improvement Proposal).
Please see BIP 2 for more information about BIPs and creating them. Please do not just create a wiki page.

Please do not modify this page. This is a mirror of the BIP from the source Git repository here.

  BIP: 11
  Layer: Applications
  Title: M-of-N Standard Transactions
  Author: Gavin Andresen <gavinandresen@gmail.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0011
  Status: Final
  Type: Standards Track
  Created: 2011-10-18
  Post-History: 2011-10-02

Abstract

This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type.

Motivation

Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature.

A couple of motivating use cases:

  • A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business.
  • Three-party escrow (buyer, seller, and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).
    If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP.

Specification

A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks:

   m {pubkey}...{pubkey} n OP_CHECKMULTISIG

But only for n less than or equal to 3.

OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig:

   OP_0 ...signatures...

(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).

The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accommodate 3-signature transactions, this will be increased to 500 bytes.

Rationale

OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases.

One argument against using OP_CHECKMULTISIG is that old clients and miners count it as "20 sigops" for purposes of computing how many signature operations are in a block, and there is a hard limit of 20,000 sigops per block-- meaning a maximum of 1,000 multisig transactions per block. Creating multisig transactions using multiple OP_CHECKSIG operations allows more of them per block.

The counter-argument is that these new multi-signature transactions will be used in combination with OP_EVAL (see the OP_EVAL BIP), and will be counted accurately. And in any case, as transaction volume rises the hard-coded maximum block size will have to be addressed, and the rules for counting number-of-signature-operations-in-a-block can be addressed at that time.

A weaker argument is OP_CHECKMULTISIG should not be used because it pops one too many items off the stack during validation. Adding an extra OP_0 placeholder to the scriptSig adds only 1 byte to the transaction, and any alternative that avoids OP_CHECKMULTISIG adds at least several bytes of opcodes.

Implementation

OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type.

https://github.com/gavinandresen/bitcoin-git/tree/op_eval

Post History