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. 
Topic: Multisig question (Read 383 times)
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?
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. 
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:
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:
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?
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"
]
[
"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?
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).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.
- 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
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
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.
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
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. 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.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.
Anybody can spend these outputs by simply providing "OP_TRUE " 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.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.
Removed the script.
~
In order to spend from a M-of-N multi-sig, you need to provide at least M signatures using any M public keys (from the N total). Even though P2MS is not used nowadays, it's simple and neat for learning about multi-sig: https://learnmeabitcoin.com/technical/p2mspub_key OP_CHECKSIG
OP_IF (num of sig required) pub_key1 pub_key2 (total pubkeys) OP_CHECKMULTISIG
OP_ENDIF
OP_VERIFY
In your case, your P2SH would be:
A_Pubkey OP_CHECKSIG
OP_IF 1 B_PUBKEY C_PUBKEY D_PUBKEY 3 OP_CHECKMULTISIG
OP_ENDIF
OP_VERIFY
Anybody can spend these outputs by simply providing "OP_TRUE OP_IF (num of sig required) pub_key1 pub_key2 (total pubkeys) OP_CHECKMULTISIG
OP_ENDIF
OP_VERIFY
In your case, your P2SH would be:
A_Pubkey OP_CHECKSIG
OP_IF 1 B_PUBKEY C_PUBKEY D_PUBKEY 3 OP_CHECKMULTISIG
OP_ENDIF
OP_VERIFY
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. Which is where we reach OP_VERIFY which needs an item on the stack, hence the first OP_TRUE.
- Using OP_IF
Since we want another signature apart from A in any case, there is no need to put the OP_CHECKMULTISIG in a conditional branch that could be avoided. Specially since you don't have any OP_ELSE branch.
Even if we needed a conditional it should be preceded either by OP_CHECKSIGVERIFY or by an OP_SWAP to use the true/false value that the user provides in their scriptsig not the OP_CHECKSIG result.
The correct redeem script that does what OP wants is:
Code:
OP_CHECKSIGVERIFY 1 B_PUBKEY C_PUBKEY D_PUBKEY 3 OP_CHECKMULTISIG
* At least one item left if it is P2SH but one and only one item if it is P2WSH.
Here's the thread: https://bitcointalksearch.org/topic/m.12830232.
Here's a transaction made using the set up discussed in that thread: https://mempool.space/tx/1c41724a7b16ecd5e11867864d834eb24e9d22b372c86aa7869c4cc0b6b36d52. It signs from one mandatory key, and then also signs from a 2-of-3 multi-sig, essentially making it a 3-of-4 with one required key.That's probably cheaper in size than the one proposed by hosseinimr93, but quite easy to mess with it during the beginning.
Just use taproot, and then your 4-of-6 transactions will be no bigger. I assume this setup would use offline signing, in which case different seeds don't increase security.
Still a central point of failure, where one seed gives you more control than it should and the compromise of a single seed equals to a compromise of 3 entities and only requiring the participation of one more. Nevertheless, that is not the point as security of seeds isn't the central discussion here.You don't need to use different derivation paths, you can simply use different addresses/keys from within one Electrum wallet for A1, A2 and A3.
That is only if you want to use a single Multisig address without an easy way of avoiding address re-use. So yes, it can work in that case.Generally, if you want to create a multisig system with HD seeds, then you should use multiple seeds instead of different derivation paths. IMO, no good reason to use HD seeds to just create a single address though.
Besides, I do agree that using separate seeds would both improve security
I assume this setup would use offline signing, in which case different seeds don't increase security.Quote
and reduce the complexity of having to track multiple derivation paths.
You don't need to use different derivation paths, you can simply use different addresses/keys from within one Electrum wallet for A1, A2 and A3. That's probably cheaper in size than the one proposed by hosseinimr93, but quite easy to mess with it during the beginning. There is no standard manner to construct a transaction spending in a P2SH as the one you've provided, so you'll have to construct it individually, which isn't recommended unless you really know what you're doing.
Yeah, agreed. Should've caveat that it is probably not too good to mess with ScriptSig if you're inexperienced. Good to test with regtest before trying it out on mainnet with small amounts of BTC though. P2WSH/P2SH is pretty versatile in the sense that you can create redeem script with a bunch of conditions and customize it to your use case. I don't foresee these kinds of scenarios to be prevalent enough to warrant a standard though. Going by OP's question, that is the only way this can be achieved if you're mapping 1 key -> 1 entity.
Yes, it actually is possible.
That's probably cheaper in size than the one proposed by hosseinimr93, but quite easy to mess with it during the beginning. There is no standard manner to construct a transaction spending in a P2SH as the one you've provided, so you'll have to construct it individually, which isn't recommended unless you really know what you're doing.I'm not familiar with multisig wallet, how does it work? Do you have to manually input each key?
In order to spend from a M-of-N multi-sig, you need to provide at least M signatures using any M public keys (from the N total). Even though P2MS is not used nowadays, it's simple and neat for learning about multi-sig: https://learnmeabitcoin.com/technical/p2ms You want to have a wallet in which transactions can be made if they are signed by person A and one of B, C and D. Is this what you are trying to achieve?
If so, you can create a 4 of 6 multi-signature wallet in which the keys are A1, A2, A3, B, C and D. (A1, A2 and A3 are all owned by one person.)
I'm not familiar with multisig wallet, how does it work? Do you have to manually input each key? If you lose one of the key, will the wallet be unusable? Can you recommend me some of them, I'm ecstatic to try one out to explore it, seems kind of cool, imagine creating a treasure hunt with this kind of thing if what I'm thinking how it works is correct. If so, you can create a 4 of 6 multi-signature wallet in which the keys are A1, A2, A3, B, C and D. (A1, A2 and A3 are all owned by one person.)
Jump to: