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 387 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"
]
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.)
Then if this seed gets compromised, wouldn’t the hacker use them to recover all the three keys? Although the hacker would still need one more co-signer but wouldn’t that be too risky and probably defeats the whole idea of multi sig?
That is kind of besides the point, since the intention of OP wasn't for one co-signer to have additional security but for the entire system to require the signature of one specific cosigner. Though, there is also a point in that, but the security being provided would be the same as n-of-m multisig, with m distinct entities.Besides, I do agree that using separate seeds would both improve security and reduce the complexity of having to track multiple derivation paths. Wallets like Electrum already makes use of their own versioning system to reduce the chances of user error. It isn't that much more complicated to store a few more seeds anyways.
Can anyone explain in an accessible way why split A into A1, A2, A3, if, as a result, all these 3 keys will belong to one person?
In this way, the person A owns 3 out of 6 keys and it won't be possible to make any transaction from the wallet without his permission. Since the wallet is a 4 of 6 multi-signature wallet, even if all persons B, C and D agree to make a transaction, they will still need person A's permission. This is what OP is trying to achieve. Especially if A1, A2, A3 can be obtained from one key.
LoyceV suggested user A having a single seed phrase, so that he/she doesn't have to keep three seed phrases. The 3 keys can be obtained using a single seed phrase and three different passphrases or having a single seed phrase and generating the keys on three different derivation paths.
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.)
Can anyone explain in an accessible way why split A into A1, A2, A3, if, as a result, all these 3 keys will belong to one person?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.)
With A1, A2 and A3 being with just one person, that is he will have to back 3 keys and 3 Seeds.
All 3 keys can be derived from the same seed.Why complicate? Can't this be simplified?
With A1, A2 and A3 being with just one person, that is he will have to back 3 keys and 3 Seeds.
All 3 keys can be derived from the same seed.Then if this seed gets compromised, wouldn’t the hacker use them to recover all the three keys? Although the hacker would still need one more co-signer but wouldn’t that be too risky and probably defeats the whole idea of multi sig?
With A1, A2 and A3 being with just one person, that is he will have to back 3 keys and 3 Seeds.
All 3 keys can be derived from the same seed. 
Is it possible to make a multisig address with 4 keys (A, B, C, D) that requires 2 signatures to broadcast a transaction, but one of the signatures MUST be from A?
With your question, I believe the person A is an important co-signer for that Bitcoin treasury. You want to add a condition that without person A confirmation through his signature, no Bitcoin transaction will be moved out of that treasury.It is good to control that treasury but it has disadvantage and risk too. Like if that important co-signer passes away, bitcoins in that wallet will not be accessed. It's very risky.
The main reason we have multisig wallet is to avoid hacks, increase security and safety for our bitcoin, but it is not used to increase risk of losing our bitcoins.
If you want risk, you can set a 3/4 cosigner wallet with 4 cosigners: 2 from person A, 1 from person B, 1 from person C. Because that multisig wallet need 3 cosigners to sign a transaction, if only two people B and C sign a transaction, it will not be enough without a signature from person A.
Multisig wallets can keep your coins safer if you use them right
Yes, it actually is possible. I stumbled upon this a while back and thought it was a pretty nice usecase. Smaller redeem script size as well, as compared to the other solution involving a single entity holding multiple keys.
Here's the thread: https://bitcointalksearch.org/topic/m.12830232.
We simplified and expanded on it afterwards in another discussion, I was the OP IIRC. The simplified scripting would be something like
In your case, your P2SH would be:
** See pooya's reply.
Here's the thread: https://bitcointalksearch.org/topic/m.12830232.
We simplified and expanded on it afterwards in another discussion, I was the OP IIRC. The simplified scripting would be something like
In your case, your P2SH would be:
** See pooya's reply.
Is it possible to make a multisig address with 4 keys (A, B, C, D) that requires 2 signatures to broadcast a transaction, but one of the signatures MUST be from A?
Sorry if this has been answered before.
Sorry if this has been answered before.
If I get you correctly you want to have 4 keys and during a transaction key A must sign, I would say there isn’t such a set up because every key on a multi sig actually holds the same capacity as the other. Moreover in a 4 keys set up more than 2 signatures would be needed for better security purpose.
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.)
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.)
This will actually be a good setup with an increased number of n, more co-signers (m) will be needed. But my problem in this case now will be having to back up all this keys and seeds. With A1, A2 and A3 being with just one person, that is he will have to back 3 keys and 3 Seeds. The more the number of these are there to back up the more I think it is easier to find at least one of them. If these 6 things are dispersed in different location (which is ideal for security reasons) then should the other three key (B, C and D) gets hold of one of these then they co sign in.
I feel a lesser m-of-n will be better if one person would hold two or more keys for backup case
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.)
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.)
Creative solution, thank you.
Is it possible to make a multisig address with 4 keys (A, B, C, D) that requires 2 signatures to broadcast a transaction, but one of the signatures MUST be from A?
You mean the 2 signature must be from A? Meaning the A have 2 signature?
Yes it's possible but take note that this A can broadcast a transaction without the other cosigners but it defeats the purpose of multisig wallet.
Unless you talking about 1 signature all of the cosigner(parties A,B,C,D) have their own keys and must share the public key to A to create a multisig wallet(same goes to (B,C,D).
Take note all of them can sign a transaction but since you said you have 4 co-signer and 2 signature only requires 2 co-signer(2 parties can be A and B or C and D) to be able to sign and broadcast a transaction.
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.)
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.)
Is it possible to make a multisig address with 4 keys (A, B, C, D) that requires 2 signatures to broadcast a transaction, but one of the signatures MUST be from A?
Sorry if this has been answered before.
Sorry if this has been answered before.
Jump to: