OP CHECKMULTISIG: Difference between revisions
NotATether (talk | contribs) Create OP_CHECKMULTISIG page |
NotATether (talk | contribs) m fix minor typo |
||
Line 1: | Line 1: | ||
'''OP_CHECKMULTISIG''' and '''OP_CHECKMULTISIGVERIFY''' are [[Script|script]] opcodes used to verify that the | '''OP_CHECKMULTISIG''' and '''OP_CHECKMULTISIGVERIFY''' are [[Script|script]] opcodes used to verify that the signatures for an M-of-N multisig transaction input are valid. It is usually found in P2SH-P2WSH scripts (a P2WSH script that's wrapped inside a [[P2SH|P2SH]] script) Both of them pop a variable number of values on the stack. In order of stack depth, these are: | ||
* The number of public keys <M>, as a constant opcode, such as OP_2 | * The number of public keys <M>, as a constant opcode, such as OP_2 |
Latest revision as of 00:19, 14 July 2021
OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are script opcodes used to verify that the signatures for an M-of-N multisig transaction input are valid. It is usually found in P2SH-P2WSH scripts (a P2WSH script that's wrapped inside a P2SH script) Both of them pop a variable number of values on the stack. In order of stack depth, these are:
- The number of public keys <M>, as a constant opcode, such as OP_2
- The next <M> parameters that follow are the values of each public key, depending on the value of <M>.
- The number of signatures <N>, as a constant opcode, such as OP_2
- The next <N> parameters that follow are the values of each signature, depending on the value of <N>.
- A dummy value, unused because of a bug in OP_CHECKMULTISIG code that removes an extra value from the stack. Required to be OP_0 to prevent a malleability attack vector described in BIP 147.
OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY both consume 20 signature operations (sigops). Because there's a hard limit of 20,000 sigops per block, this means a maximum of 1,000 OP_CHECKMULTISIG(VERIFY) transactions can be included in any block.
How it works
In this example[1], before OP_CHECKMULTISIG(VERIFY) executes, the stack looks like this:
3 (pubKey3) (pubKey2) (pubKey1) 2 (sig2) (sig1) 0
1. Perform basic sanity checks, such as the number of public keys and signatures on the stack match <M> and <N> respectively, and there aren't more signatures than public keys.
2. Pop <M>, the public keys, <N>, the signatures, and an unused OP_0 value from the stack.
3. Loop through the public keys and signatures starting with the ones at the top of the stack. In this case, the public key and signature indices will be at pubKey3 and sig2 like this:
n-> 3 ikey-> (pubKey3) (pubKey2) (pubKey1) m-> 2 isig-> (sig2) (sig1) 0
4. The signature at the index is validated against the public key at the other index. If they match, both indices are advanced to the next public key and signature. Otherwise, only the public key index is advanced to the next position, while the signature index stays the same. For this example, signature validation fails once and then succeeds the next time, so the indices advance like this:
Failed validation index advancement:
n-> 3 (pubKey3) ikey-> (pubKey2) (pubKey1) m-> 2 isig-> (sig2) (sig1) 0
Passed validation index advancement:
n-> 3 (pubKey3) (pubKey2) ikey-> (pubKey1) m-> 2 (sig2) isig-> (sig1) 0
If not all the signatures can be verified then these opcodes return false (OP_0), otherwise, they return true (OP_1).
Additional details
OP_CHECKMULTISIGVERIFY
OP_CHECKMULTISIGVERIFY is equivalent to OP_CHECKMULTISIG except that OP_VERIFY is executed after the operation.
Segwit
Segwit has moved the contents of the scriptSig to the witness data to thwart malleability problems in the scriptSig. Besides that, the operation of OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY aren't affected.
Taproot
There is a new opcode, OP_CHECKSIGADD, for validating the signatures of Schnorr-aggregated public keys and has a much smaller transaction size than OP_CHECKMULTISIG.