user97405: 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?

user47827: 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.

user5406: 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.

97405: <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>
 47827: <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>
 5406: <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>
