P2MS

P2MS, short for pay to multisig, locks an output to a list of public keys. The lock sets two numbers: m, how many signatures are needed, and n, how many keys there are. A 2-of-3 lock needs valid signatures from two of its three keys. P2MS is a legacy type. Raw multisig is rare on chain today, because most multisig wraps the script in P2SH or P2WSH.

BIP 11 defined M-of-N multisig as a standard transaction type. The earliest examples below are from January 2012.

What does a P2MS locking script look like?

The lock is OP_2, the public keys, OP_3, and then OP_CHECKMULTISIG. The whole script is 201 bytes:

524104d81fd577272bbe73308c93009eec5dc9fc319fc1ee2e7066e17220a5d47a18314578be2faea34b9f1f8ca078f8621acd4bc22897b03daa422b9bf56646b342a24104ec3afff0b2b66e8152e9018fe3be3fc92b30bf886b3487a525997d00fd9da2d012dce5d5275854adc3106572a5d1e12d4211b228429f5a7b2f7ba92eb0475bb14104b49b496684b02855bc32f5daefa2e2e406db4418f3b86bca5195600951c7d918cdbe5e6d3736ec2abf2dd7610995c3086976b2c0c7b4e459d10b34a316d5a5e753ae

Each key here is uncompressed, so each one is pushed with 41 and 65 bytes of data. A P2MS lock can mix compressed (33-byte) and uncompressed keys. Output 0 of 581d30e2a73a2db683ac2f15d53590bd0cd72de52555c2722d9d6a78e9fea510 uses this lock.

What does the unlocking script look like?

The scriptSig has an empty first item, then the two signatures:

00483045022100af204ef91b8dba5884df50f87219ccef22014c21dd05aa44470d4ed800b7f6e40220428fe058684db1bb2bfb6061bff67048592c574effc217f0d150daedcf36787601483045022100e8547aa2c2a2761a5a28806d3ae0d1bbf0aeff782f9081dfea67b86cacb321340220771a166929469c34959daf726a2ac0c253f9aff391e58a3c7cb46d8b7e0fdc4801

00 is the empty first item, and each signature is pushed with 48, for 72 bytes. Input 0 of 949591ad468cef5c41656c0a502d9500671ee421fadb590fbc6373000039b693 spends the 2-of-3 lock above.

What is the dummy item?

OP_CHECKMULTISIG has an off-by-one bug: it pops one more item than it should. The spend adds an extra item at the start to absorb it. This is the dummy item. Since BIP 147, the dummy must be empty, which means OP_0 (00). Nodes reject any other value.

The signatures must also appear in the same order as their keys. The next section shows why.

How does a P2MS script run?

All the signatures and keys are pushed onto the stack first. Then OP_CHECKMULTISIG works like this:

1. It pops n, then pops that many public keys off the stack.
2. It pops m, then pops that many signatures.
3. It takes the first signature and the first key. If they match, it moves to the next signature. If they do not, it moves to the next key.
4. A key that has been passed is never checked again.
5. If every signature found a matching key, it pushes OP_1. Otherwise the script fails.

Because the walk only moves forward, a signature can match a key only if it comes after the previous signature's key. That is why the signatures must follow the key order.

What are the limits on P2MS?

• A standard bare multisig lock can have at most 3 keys. A larger one is valid if it is mined, but nodes will not relay it.
• OP_CHECKMULTISIG itself accepts up to 20 keys.
• Wrapped in P2SH, the redeem script can hold up to 15 compressed keys, because a redeem script can be at most 520 bytes. Uncompressed keys take 66 bytes each, so seven is the most that fit.

Does P2MS have an address?

No. A raw P2MS lock has no address format. You can convert each of its public keys to an address, but the multisig lock itself does not have one. To lock coins to a multisig, wrap the script in P2SH or P2WSH, which do have addresses. Most wallets only let you pay an address, so a raw P2MS lock would need the sender to build the transaction by hand.

P2MS has never been removed from the consensus rules. It became standard in early 2012, before P2SH took effect in April 2012 under BIP 16.

Which P2MS transactions can you check on our explorer?

• Output 0 of 60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1 is a raw 1-of-2 lock, spent by input 0 of 23b397edccd3740a74adb603c9756370fafcde9bcc4483eb271ecad09a94dd63. The lock is from 30 January 2012, and the spend from 3 February 2012.
• Output 0 of 2daea775df11a98646c475c04247b998bbed053dc0c72db162dd6b0a99a59c26 is a raw 3-of-3 lock, spent by input 0 of e8ac451e7f47d566d4dd822a67fea2181ecfa7c7ba96d9faa63e2f6b26e55fd3. The lock is from 3 February 2012, and the spend from 11 February 2012.
• Output 0 of c4aaf7fbec7a9a079e670e50f6a672315451c7618814494ab1f89cf3fd97b3bb is a 20-of-20 lock, spent by input 0 of da738e29f64e90ae46dcc3e6b4154041d6324abbe7919e722d486a4a3148b7dc. Its 20 keys are above the 3-key standard limit, so it is not standard, though OP_CHECKMULTISIG accepts it.