pull down to refresh

  1. What is BIP11? BIP11 stands for Bitcoin Improvement Proposal 11. It proposes a new standard transaction type for M-of-N-signatures required transactions. This means that to redeem funds in these transactions, more than one signature is required, with "M" being the minimum number of signatures needed, and "N" being the total number of signatures involved.
  2. Motivation: The motivation behind BIP11 is to enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. Two motivating use cases are mentioned in the proposal:
    • Wallets secured by a "wallet protection service" (WPS) where 2-of-2 signatures are required. This involves one signature from the user's computer with the wallet and another from the WPS.
    • Three-party escrow transactions where 2-of-3 signatures are required, involving the buyer, seller, and a trusted dispute agent.
  3. Specification: The proposal introduces a new standard transaction type using the scriptPubKey format:
    m {pubkey}...{pubkey} n OP_CHECKMULTISIG
    
    The scriptPubKey includes "m" public keys followed by "n" OP_CHECKMULTISIG operation. Note that "n" should be less than or equal to 3.
    The transactions are redeemed using the scriptSig format:
    OP_0 ...signatures...
    
    The "OP_0" is required due to a bug in OP_CHECKMULTISIG, and it acts as a dummy value on the stack.
  4. Current Limitations: The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes. To accommodate 3-signature transactions, this limitation will be increased to 500 bytes.
  5. Rationale: The proposal uses OP_CHECKMULTISIG, an already enabled opcode, as the most straightforward way to support the required use cases. It does acknowledge some arguments against using OP_CHECKMULTISIG, including counting it as "20 sigops" for block computation purposes. This means a maximum of 1,000 multisig transactions per block. However, the counter-argument is that these new multi-signature transactions will be used in combination with OP_EVAL (see OP_EVAL BIP), and they will be counted accurately. As transaction volume rises, the hard-coded maximum block size will have to be addressed, and the rules for counting signature operations can be adjusted accordingly.
    Additionally, the proposal addresses a weaker argument related to the extra item popped off the stack during validation by adding an extra OP_0 placeholder to the scriptSig, which adds only 1 byte to the transaction.