6

By reading this answer, I understand that in m-of-n multisig addresses, m and n are limited by the maximum size allowed by the P2SH redeemScript (i.e. 520 bytes).

However, in this section of BIP141, it is stated that the witnessScript can be as long as 10,000 bytes. As far as I understand, this implies that with SegWit adoption it should be possible to create and use m-of-n multisig addresses with very large m and n that will be considered valid.

By my calculations we will be able to have ns as big as around 300. Am I understanding this correctly?

For instance, would the following witnessScript, which should represent a 50 out of 100 multisig address, be considered valid and spendable under SegWit?

0x01 0x32 <100 public keys> 0x01 0x64 OP_CHECKMULTISIG
10

By reading this answer, I understand that in m-of-n multisig addresses, m and n are limited by the maximum size allowed by the P2SH redeemScript (i.e. 520 bytes).

That's correct. Even though the OP_CHECKMULTISIG script opcode supports more keys, more than 15 public keys simply don't fit in a P2SH redeemscript, so that becomes the limiting factor.

However, in this section of BIP141, it is stated that the witnessScript can be as long as 10,000 bytes. As far as I understand, this implies that with SegWit adoption it should be possible to create and use m-of-n multisig addresses with very large m and n that will be considered valid.

BIP141 only describes the consensus rules - i.e. what transactions are valid inside blocks. There are a number of standardness rules that apply for transactions to be relayed and accepted into memory pools, to avoid potential avenues of abuse before they're understood. Bitcoin Core 0.13.1 and up limit witness scripts to 3600 bytes for that purpose.

For instance, would the following witnessScript, which should represent a 50 out of 100 multisig address, be considered valid and spendable under SegWit?

0x01 0x32 <100 signatures> 0x01 0x64 OP_CHECKMULTISIG

I assume you mean public keys there instead of signatures?

No. OP_CHECKMULTISIG itself only supports up to 20-of-20, so if you want to use that opcode, you can't go above 20. However, you can construct others scripts that go above those limits.

In particular:

<pubkey1> OP_CHECKSIG
OP_SWAP <pubkey2> OP_CHECKSIG OP_ADD
OP_SWAP <pubkey3> OP_CHECKSIG OP_ADD
...
OP_SWAP <pubkey67> OP_CHECKSIG OP_ADD
<m> OP_NUMEQUALVERIFY

would implement an m-of-67 policy, with less than 3600 bytes.

  • 1
    Thank you for your great answer. Yes, I meant "100 public keys", I fixed it in the original question. – Simone Bronzini Feb 28 '17 at 9:55
  • So, if I understand your alternative solution correctly, 10000-byte scripts would allow for multisig addresses with n as great as 276 (i.e. floor((10,000 - 34 - 3) / 36), where the first line is 34 bytes, the last line is 3 bytes, considering m as an OP_PUSHDATA1 followed by a one-byte number, and every other line is 36 bytes), is that correct? – Simone Bronzini Feb 28 '17 at 10:06
  • 1
    Yes, but that would exceed the 201 script ops limit. – Pieter Wuille Feb 28 '17 at 13:58
  • Isn't it too late to enlarge the limit for witness scripts? (I am just asking, I do not need this increasing) And what about the limit of 20 sigop operations for a script? – amaclin Feb 28 '17 at 14:30
  • 1
    Any of these limits can easily be changed in a new software version (for standardness limits like 3600 bytes) or a new script version (for consensus limits like 10k bytes or 201 ops). Given the script versioning that segwit introduces, the latter should be simple. – Pieter Wuille Feb 28 '17 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.