Multisig question

[ranochigo]

Anybody can spend these outputs by simply providing "OP_TRUE <fake_sig>" to the above redeem script.

The flaws in the script are:
- Using OP_CHECKSIG instead of OP_CHECKSIGVERIFY
When you use OP_CHECKSIG it will push the result of the verification to the stack when immediately after your OP_IF is going to pop an item from the stack which is the result of the signature verification. If it is false it won't even execute the branch under it which can be abused by passing a fake signature so that OP_CHECKSIG pushes OP_FALSE to the stack ergo the OP_IF that pops OP_FALSE is skipped.

Thanks for the clarification. Forgot that top stack is popped given that OP_IF is skipped when OP_CHECKSIG is false.

Removed the script.

[1714492672]

1714492672

[1714492672]

1714492672

[1714492672]

1714492672

[1714492672]

1714492672

[o_e_l_e_o]

So what you're saying is if I have a total of 5 signatures, I can use just 1 key? What does the M stand for? Thanks for the link, but I'm a bit worried about learning it if it's not used nowadays, kind of just learning about history of something to me.

m-of-n is just a common way of describing multi-sig set ups. The m stands for how many signatures you need, and the n stands for the total number of cosigners. For example, in a 2-of-3 multi-sig, there will be 3 cosigners, with the signatures of any 2 of them needed to spend the coins.

Although P2MS is very rarely used now, the script used in P2MS is the same script which is used in newer P2SH/P2WSH multi-sig addresses, so still worth a read.

[Latviand]

m-of-n is just a common way of describing multi-sig set ups. The m stands for how many signatures you need, and the n stands for the total number of cosigners. For example, in a 2-of-3 multi-sig, there will be 3 cosigners, with the signatures of any 2 of them needed to spend the coins.

This is what I initially thought too, I just didn't want to be confused so I asked for a clarification which I got with this one, thanks. Can you set the minimum signature to open the wallet? If so, that means that you can set it as 3 of 3?

~

Although P2MS is very rarely used now, the script used in P2MS is the same script which is used in newer P2SH/P2WSH multi-sig addresses, so still worth a read.

I guess, I'll give it a go, seems like a really good read too, I skimmed the contents and I hope that I can understand the technical terms, I'm not that good with unknown stuff.

[o_e_l_e_o]

Can you set the minimum signature to open the wallet? If so, that means that you can set it as 3 of 3?

Yes. You can choose any subset of the number of keys you like. So you could have 1-of-3, 2-of-3, or 3-of-3. Or you could have 4-of-8. Or 9-of-10. Or whatever you like.

[BlackHatCoiner]

Just use taproot, and then your 4-of-6 transactions will be no bigger.

That's a good idea, even though I know none of the best wallet software that support taproot multi-sig. Sparrow only supports single-sig taproot according to this tweet (haven't seen any updates in their taproot functionalities since then). Electrum doesn't support taproot... yet. And, according to this SE post, only Nunchuk does, but I wouldn't recommend using a software with "paid options", and with little recognition and development.

Edit: It's possible in Bitcoin Core 24.0: https://bitcoin.stackexchange.com/a/115726/134811

[hosseinimr93]

Yes. You can choose any subset of the number of keys you like.

Isn't there any maximum limit for total number of cosigners?
As you know, electrum allow increasing the number of consigners up to 15. Isn't that the maximum number of cosigners we can have or that's just a limit enforced by electrum?

If I am not wrong, the p2sh script size can't be more than 520 bytes and that should limit the total number of cosigners we can have in a multi-signature address.

[o_e_l_e_o]

Isn't there any maximum limit for total number of cosigners?

7-of-7 for uncompressed public keys, 15-of-15 for compressed keys, in a P2SH multi-sig. This is based on the limit of 520 bytes as you say, although OP_CHECKMULTISIG would actually support up to 20 keys.

In taproot, OP_CHECKMULTISIG/OP_CHECKMULTISIGVERIFY are replaced with OP_CHECKSIGADD (0xba), which allows up to 999 keys. Here is a transaction which spends a 998-of-999 taproot multisig: https://mempool.space/tx/7393096d97bfee8660f4100ffd61874d62f9a65de9fb6acf740c4c386990ef73

[pooya87]

Isn't there any maximum limit for total number of cosigners?
As you know, electrum allow increasing the number of consigners up to 15. Isn't that the maximum number of cosigners we can have or that's just a limit enforced by electrum?

If I am not wrong, the p2sh script size can't be more than 520 bytes and that should limit the total number of cosigners we can have in a multi-signature address.

Technically the OP_CHECKMULTISIG(VERIFY) operations have a consensus critical check where they limit the number to 20 public keys[1][2] but the actual maximum number of public keys used in a multi-sig script depends on the type of the script and the public key length (compressed/uncompressed).
- For a P2MS script where the locking script is inside the scriptpub you can have up to 20 pubkeys regardless of the pubkey type since there is no size limit in consensus rules for scriptpubs.
- But for a P2SH script where there is a redeem script (containing pubkeys), the redeem script needs to be pushed to the stack as raw bytes, so the size is limited by that Push OP and to 520 bytes as you said. So it is 520/65=8 -extra bytes = 7 uncompressed pubkeys and 520/33=15 compressed pubkeys.

[1] https://github.com/bitcoin/bitcoin/blob/d09c8bc730d8d412ddc9b040cbeeb49dff3104de/src/script/interpreter.cpp#L1116
[2] https://github.com/bitcoin/bitcoin/blob/d09c8bc730d8d412ddc9b040cbeeb49dff3104de/src/script/script.h#L30

In taproot, OP_CHECKMULTISIG/OP_CHECKMULTISIGVERIFY are replaced with OP_CHECKSIGADD (0xba), which allows up to 999 keys.

Isn't that a standard rule? I can't see this enforced anywhere else:
https://github.com/search?q=repo%3Abitcoin%2Fbitcoin+MAX_PUBKEYS_PER_MULTI_A+&type=code

[BlackHatCoiner]

I didn't know how to construct a 2-of-3 tapscript multi-sig, so I attempted to do it for visual purposes. In descriptor's language, you can create one with:

Code:

tr(KI,multi_a(2,K1,K2,K3))

Where KI, an unspendable key, like 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0 as described here, and K1,K2,K3 the public keys. Note that you need to get the descriptor's checksum (which is "9ue8weec") using getdescriptorinfo and add it next to tr as following.

In Bitcoin CLI:

Code:

$ bitcoin-cli deriveaddresses "tr(50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0,multi_a(2,024ab6829a2f1613f3dd93c47eaa18c7f01b4a2bbb4ec2ead8a75b18e3857becb4,0261d533fe5964f2458ceb03ab0b2744c4c7dc9428dba8afbd0b591af5d939afdd,03ff7ea3f10a45587576ce7d55845eaa19f8883aa1dc99dfe08790de4a89571e6c))#9ue8weec"
[
  "bcrt1p4hlrruprsujvg7ghfyt6l6leyz6hedgdp8n62l3u7rnwcmfwqr9q5sr5cx"
]

I funded it with a transaction, but I'm unfortunately struggling at spending that output. Correct me if I'm wrong but don't I create a new (with descriptors turned off) wallet, import the private keys of the three public keys shown, and use createpsbt, walletprocesspsbt as shown in here? It's possible to spend that output from Bitcoin Core, right?

[Pmalek]

That's a good idea, even though I know none of the best wallet software that support taproot multi-sig.

I don't know which wallets support Taproot multi-sig (if any) or only single-sig, but dkbit98 created a thread and listed software and hardware wallets that support the new address format. You can check Wallets supporting Taproot. There aren't that many. In the meantime, maybe some new ones can be added to that list.

[Chivas Regal]

If funds were sent to A2+B but A4+D sign a transaction, how can they (A4+D) access the funds sent to A2+B (sorry if my newbie question seems a little dense) Wouldn't they be in two separate wallet addresses?

[LoyceV]

If funds were sent to A2+B but A4+D sign a transaction, how can they (A4+D) access the funds sent to A2+B (sorry if my newbie question seems a little dense) Wouldn't they be in two separate wallet addresses?

A n-of-m multisig creates one address that can be accessed by n people. I recommend to try it on testnet: get some testnet coins, and play around with 3 wallets until you get a multisig address. Then fund it, and withdraw again. Doing so helps explain how it works. You can use Electrum, or even better if you use different wallets for each signer.