Pay To Multisig

BIP 11: M-of-N Standard Transactions

A diagram showing the structure of a P2MS.

P2MS is a script pattern that allows you to lock bitcoins to multiple public keys, and require signatures for some (or all) of those public keys to unlock it.

For example, you could create a P2MS script that includes the public keys of 3 different people, but only 2 of those people would need to provide their signatures to spend the bitcoins:

A diagram showing a P2MS script being locked to 3 different public keys, and requiring 2 signatures from any of those 3 public keys to unlock it.

Although P2MS is a standard script, it's more common to wrap this type of script in a P2SH or P2WSH.

Legacy Script. This is a legacy script pattern and is rarely used directly on outputs.


How does P2MS work?

Raw multisig scripts are pretty straightforward to create.


To create a raw P2MS script you include the following OP_CODES and data in the ScriptPubKey:

  1. A number opcode M to indicate how many signatures are required.
  2. Then push each of the public keys.
  3. A number opcode N to indicate how many public keys there are.
  4. OP_CHECKMULTISIG opcode at the end.

So in the following example we have a 2-of-3 (M-of-N) multisig locking script, where OP_2 signatures are going to be required to unlock the OP_3 public keys:


Transaction: 581d30e2a73a2db683ac2f15d53590bd0cd72de52555c2722d9d6a78e9fea510 (Output 0)

A P2MS can contain both compressed public keys (33 bytes) and uncompressed public keys (65 bytes).

P2MS is a standard locking script for up to 3 public keys. It's possible to create a multisig script with more public keys, but it will be considered non-standard and will not be relayed by nodes. However, you can use up to 15 public keys if you wrap the P2MS inside of a P2SH instead.


To unlock a P2MS script, you just need to provide the required number of signatures in the ScriptSig.

So for this example, we need to provide OP_2 signatures (as requested in the ScriptPubKey above):


Transaction: 949591ad468cef5c41656c0a502d9500671ee421fadb590fbc6373000039b693 (Input 0)

OP_CHECKMULTISIG Bug: This opcode has a bug where it pops one extra element of the stack than it needs to (off-by-one error). That's why we add a dummy value (typically OP_O) at the start of the ScriptSig to account for this and to prevent the script from failing.

You need to provide the corresponding signatures in the same order as the order of the public keys in the ScriptPubKey. You'll see why in the execution step below.


An animation showing the execution of a full P2MS script.

When this script executes, all of the signatures and public keys get pushed on to the stack at first.

Then we get to OP_CHECKMULTISIG, which:

  1. Pops off N, and then pops that number of public keys off the stack.
  2. Pops off M, and then pops that number of signatures off the stack.

After popping all the public keys and signatures off the stack, OP_CHECKMULTISIG compares each signature with each public key:

After all the signatures have been checked, if the tally of valid signatures is equal to M, then OP_CHECKMULTISIG pushes a OP_1 on to the stack and the script is valid.


Where can you find P2MS scripts?

It's not common to find P2MS scripts in the blockchain, as most multisig transactions are wrapped inside P2SH or P2WSH instead.

Nonetheless, here are some example transactions that have raw P2MS locking scripts on their outputs:

First P2MS transaction made on 30 Jan 2012. It's using 1-of-2 multisig.
Second P2MS transaction made on 03 Feb 2012. It's using 3-of-3 multisig.
Third P2MS transaction made on 03 Feb 2012. It's using 2-of-3 multisig.
A random 1-of-1 multisig example.
A random 1-of-2 multisig example. The second "public key" in the ScriptPubKey isn't actually a valid public key (they always start with an 02, 03, or 04), but it didn't matter because only one signature was required to unlock this output, and the first public key was valid.
A random 2-of-3 multisig example.
A large 20-of-20 multisig example. This is technically not a P2MS, as a P2MS is a standard script and is limited to a maximum of 3 public keys, so if you created a P2MS of this size it would not be relayed by nodes. Nonetheless, the OP_CHECKMULTISIG opcode is valid for up to 20 public keys (this limit is set in script.h).


Does P2MS have an address?

A raw P2MS locking script does not have an address.

Of course, the ScriptPubKey for a P2MS does contain public keys, so you can convert each of those to an address if you wish, which would correspond to what the P2PKH locking script for each of those public keys would be. But the standard P2MS locking script itself has not been assigned its own address format.

If you want to use an address for locking coins to a P2MS, you should wrap the P2MS script inside a P2SH or P2WSH.


A diagram showing a P2MS wrapped inside a P2SH.

The most common method for using P2MS (multisig) locking scripts is to wrap them in a P2SH or P2WSH. This gives you some advantages over using raw P2MS scripts directly:

  1. P2MS has no address format. So if you want someone to put a P2MS lock on your bitcoins, you will need to construct and send them the raw locking script yourself. Worse still, they may not be able to create this transaction for you, as most wallets only allow you to use addresses (and not raw scripts) when making a transaction.
  2. P2MS is limited to 3 public keys. The locking script of a P2MS can get pretty sizeable with all the public keys, so it's limited to 3 (to prevent too much data being stored in the UTXO set). However, with P2SH you can use multisig locks with up to 15 public keys.

So you can still use P2MS if you want, but it's more convenient to use P2SH to achieve the same thing instead.

Why do we have both P2MS and P2SH?

Because P2MS became a standard script before P2SH was available.

It could be removed as a standard script, but…

We can't just introduce a policy that breaks existing functionality.
Pieter Wuille

So P2MS remains as a relic from the time before P2SH existed.