<p>I'd expect the relevant constraint to be the 1000 witness stack item limit for P2TR inputs. This should permit a script specifying at most 999 public keys in an <code>OP_CHECKSIG(ADD)</code>-based construction (i.e. <code>&lt;key1&gt; CHECKSIG &lt;key2&gt; CHECKSIGADD &lt;key3&gt; CHECKSIGADD &lt;key_N&gt; CHECKSIGADD &lt;k&gt; NUMEQUAL</code>), since each public key would need to be paired either with a signature or an empty element on the stack. As the script is executed, each public key would get pushed onto the stack and popped off with a signature or empty element by the <code>OP_CHECKSIG(ADD)</code>. This temporary addition of the public key would cause the temporary 1000th element.</p>
<p>This is from the top of my head, I might be forgetting something and it might be a couple fewer in practice, but the magnitude should be roughly right.</p>
<p>If you were to use the FROST scheme to create an aggregated public key and satisfy that with an aggregated threshold signature, your quorum should theoretically be unlimited.</p>
<p>The PSBT would then simply be submitted once a sufficient number of signatures were added. Either approach would probably be a terrible experience in practice since coordinating the enormous number of signers would be a headache.</p>

CC BY-SA 4.0
2023-02-22T18:48:21.337Z
In a CHECKSIGADD-based scheme you'd have one stack item for every public key (including the non-satisfied ones; the signature for those would just be 0), so I think the limit is probably closer to 499 out of 997 or so.
Pieter Wuille
CC BY-SA 4.0
2023-03-22T14:19:27.817Z
@PieterWuille aren't the public keys pushed on the stack "just in time" for each `OP_CHECKSIGADD` and popped immediately after evalution of the signature? In other words, there's never more than 1 pubkey on the stack. If so 999 of 999 should be possible.

@murch I think it's only the first `OP_CHECKSIG` that pushes the 1000 limit of the stack. The witness puts 999 signatures on the stack, we then add the first pubkey which takes it to 1000, then the pubkey and signature are popped and 1 is pushed on the stack, so we're at 999.
Sjors Provoost
CC BY-SA 4.0
2023-03-22T14:23:24.207Z
@SjorsProvoost Oh, yes, you're right.
Pieter Wuille
CC BY-SA 4.0
2023-03-22T14:34:58.933Z
@SjorsProvoost: So am I understanding you right that you think 999 of 1997 should be possible?
Murch
CC BY-SA 4.0
2023-03-22T15:44:13.250Z
@Murch I don't think N can be higher than 999 (for any M of N), because you have to push either an empty or a real signature for N. But maybe your scriptPubKey can be creative with the altstack?
Sjors Provoost
CC BY-SA 4.0
2023-03-22T16:15:32.623Z
(no, main and altstack have a combined limit)
Sjors Provoost
CC BY-SA 4.0
2023-03-22T16:58:08.060Z
Oh okay, do this is just replying to Pieter, not suggesting a change to my answer?
Murch
CC BY-SA 4.0
2023-02-22T18:42:44.003Z
2023-02-22T19:17:12.840Z
2023-02-22T19:17:12.840Z
Murch
<p>For it to be exactly 51 percent and not &quot;above 50 percent&quot; then you would need to set up say a 51-of-100 or 102-of-200 threshold signature address. A 2-of-3 threshold would suffice for &quot;above 50 percent&quot;. There's no way in Bitcoin script to calculate a percentage of signers is above 50 percent, you have to assign the x-of-y threshold. I guess you could set up a Taproot tree saying 51-of-100 OR 52-of-100 OR 53-of-100.... etc but that doesn't achieve much (if anything) over just using a simple 51-of-100 threshold.</p>

CC BY-SA 4.0
2023-02-22T18:24:23.823Z
Since the transaction will go through after 51% signed, what’s the point of having paths for more signatures?
Murch
CC BY-SA 4.0
2023-02-22T18:26:09.827Z
@Murch: You want to hide the fact that less signatures were actually required to spend it? I agree it is unlikely you'd want this.
Michael Folkson
CC BY-SA 4.0
2023-02-22T17:56:34.027Z
2023-02-22T17:56:34.027Z
Michael Folkson
<p>I want to create a DAO-like wallet where each member would have to sign for any given tx.
Tx should go through if 51% of the users signed.</p>
<p>Is this possible?</p>

CC BY-SA 4.0
2023-02-23T18:14:02.503Z
Is it just 51% of the wallets need to sign regardless of how much funds they control? I don't think this will be secure against sibyl attacks. Any funds controlled by the wallet would now give an incentive for an attacker to spin up more addresses than the 51% wallet holds, I suppose if that number was extremely high it would represent difficulty?
Poseidon
CC BY-SA 4.0
2023-02-23T18:19:33.120Z
(Assuming it is actually decentralized and permission-less to join)
Poseidon
<multi-signature><taproot><p2tr>
How can I create a multi sign for a large number of users
pxr_64
# How can I create a multi sign for a large number of users

(Asked by: username_0 on 2023-02-22)

I want to create a DAO-like wallet where each member would have to sign for any given tx.
Tx should go through if 51% of the users signed.

Is this possible?

**Tags:** multi-signature, taproot, p2tr

> **Comments:**
> **username_1**: Is it just 51% of the wallets need to sign regardless of how much funds they control? I don't think this will be secure against sibyl attacks. Any funds controlled by the wallet would now give an incentive for an attacker to spin up more addresses than the 51% wallet holds, I suppose if that number was extremely high it would represent difficulty?  
> **username_1**: (Assuming it is actually decentralized and permission-less to join)  

---

## 2 answers

### Answer by username_2 on 2023-02-22. Score: 3

I'd expect the relevant constraint to be the 1000 witness stack item limit for P2TR inputs. This should permit a script specifying at most 999 public keys in an `OP_CHECKSIG(ADD)`-based construction (i.e. `<key1> CHECKSIG <key2> CHECKSIGADD <key3> CHECKSIGADD <key_N> CHECKSIGADD <k> NUMEQUAL`), since each public key would need to be paired either with a signature or an empty element on the stack. As the script is executed, each public key would get pushed onto the stack and popped off with a signature or empty element by the `OP_CHECKSIG(ADD)`. This temporary addition of the public key would cause the temporary 1000th element.

This is from the top of my head, I might be forgetting something and it might be a couple fewer in practice, but the magnitude should be roughly right.

If you were to use the FROST scheme to create an aggregated public key and satisfy that with an aggregated threshold signature, your quorum should theoretically be unlimited.

The PSBT would then simply be submitted once a sufficient number of signatures were added. Either approach would probably be a terrible experience in practice since coordinating the enormous number of signers would be a headache.

> **Comments:**
> **username_3**: In a CHECKSIGADD-based scheme you'd have one stack item for every public key (including the non-satisfied ones; the signature for those would just be 0), so I think the limit is probably closer to 499 out of 997 or so.  
> **username_4**: @username_3 aren't the public keys pushed on the stack "just in time" for each `OP_CHECKSIGADD` and popped immediately after evalution of the signature? In other words, there's never more than 1 pubkey on the stack. If so 999 of 999 should be possible.  @username_2 I think it's only the first `OP_CHECKSIG` that pushes the 1000 limit of the stack. The witness puts 999 signatures on the stack, we then add the first pubkey which takes it to 1000, then the pubkey and signature are popped and 1 is pushed on the stack, so we're at 999.  
> **username_3**: @username_4 Oh, yes, you're right.  
> **username_2**: @username_4: So am I understanding you right that you think 999 of 1997 should be possible?  
> **username_4**: @username_2 I don't think N can be higher than 999 (for any M of N), because you have to push either an empty or a real signature for N. But maybe your scriptPubKey can be creative with the altstack?  
> **username_4**: (no, main and altstack have a combined limit)  
> **username_2**: Oh okay, do this is just replying to username_3, not suggesting a change to my answer?  

---

### Answer by username_5 on 2023-02-22. Score: 1

For it to be exactly 51 percent and not "above 50 percent" then you would need to set up say a 51-of-100 or 102-of-200 threshold signature address. A 2-of-3 threshold would suffice for "above 50 percent". There's no way in Bitcoin script to calculate a percentage of signers is above 50 percent, you have to assign the x-of-y threshold. I guess you could set up a Taproot tree saying 51-of-100 OR 52-of-100 OR 53-of-100.... etc but that doesn't achieve much (if anything) over just using a simple 51-of-100 threshold.

> **Comments:**
> **username_2**: Since the transaction will go through after 51% signed, what’s the point of having paths for more signatures?  
> **username_5**: @username_2: You want to hide the fact that less signatures were actually required to spend it? I agree it is unlikely you'd want this.  

---

