most recent 30 from bitcoin.stackexchange.com 2025-08-06T17:34:33Z https://bitcoin.stackexchange.com/feeds/tag?tagnames=key-aggregation https://creativecommons.org/licenses/by-sa/4.0/rdf https://bitcoin.stackexchange.com/q/127723 1 Loopite https://bitcoin.stackexchange.com/users/133916 2025-08-06T16:05:18Z 2025-08-06T18:14:30Z

<p>Let's consider the following assumptions:</p> <ol> <li><p><strong>A computer can compute the private key from the public key in <code>n</code> years (with <code>n</code> being a small number, give or take).</strong> Of course, this assumption is highly hypothetical and currently considered unrealistic.</p> </li> <li><p><strong>The public keys for multisignature accounts are known.</strong> We assume here that they are not hashed or otherwise hidden. <em>I'm also assuming that MuSig2 is used for multisignature accounts. This is expected to happen in Bitcoin, if I'm not mistaken. Besides, MuSig2 cannot be used for CISA since it only allows a single message to be passed (tell me if I'm wrong).</em></p> </li> </ol> <p>Now, since Assumption 2 holds, we can aggregate the set of public keys using MuSig2, producing a single aggregate public key, <code>AggPub</code>. Because it's a valid x-only public key, there are exactly two corresponding private keys, <code>Priv1</code> and <code>Priv2</code>, linked to <code>AggPub</code>. <em>By knowing one of them, you can easily know the other by negating the first private key.</em></p> <p><strong>From Assumption 1, can we compute one of the private keys (<code>Priv1</code> or <code>Priv2</code>) from <code>AggPub</code> in the same amount of time, i.e., <code>n</code> years?</strong> From my perspective, yes we can.</p> <p><strong>Of course, Assumption 1 is too strong.</strong> But if the answer to the question is yes, it would suggest that signature compression is not the best trade-off here. In fact, this could even be exploited for zombie accounts using MuSig2, allowing the unlocking of dormant funds with just a single private key by performing a simple Schnorr signature.</p>

https://bitcoin.stackexchange.com/q/125030 4 allexj https://bitcoin.stackexchange.com/users/163391 2025-08-06T17:27:39Z 2025-08-06T19:38:31Z

<p><strong>Signature Generation</strong></p> <ol> <li>Let <code>L = h(P1 || ... || Pn)</code>. Each participant computes the digest: <code>ai = h(L || Pi)</code>.</li> <li>Compute the aggregated public key: <code>X̃ = Σ (ai * Pi)</code> for <code>i = 1, ..., n</code>. <code>X̃</code> is made public.</li> <li>Each participant randomly selects <code>ri</code> and computes: <code>Ri = ri * G</code>. Each participant sends their commitment: <code>ti = h(Ri)</code> to all other participants.</li> <li>After receiving the other <code>n-1</code> commitments, each participant sends their point <code>Ri</code>.</li> <li>After receiving the other <code>n-1</code> points <code>Ri</code>, each participant verifies: <code>ti = h(Ri)</code> for all <code>i ∈ {1, ..., n}</code>.</li> <li>Calculate the aggregated point: <code>Rsum = R1 + ... + Rn</code>.</li> <li>Each participant computes the challenge: <code>c = h(Rsum || X̃ || M)</code>.</li> <li>Each participant calculates their partial signature: <code>si = ri + c * di * ai mod N</code>.Finally, compute the aggregated signature: <code>ssum = s1 + ... + sn mod N</code>.</li> <li>The signature is the pair <code>(Rsum, ssum)</code>.</li> </ol> <p><strong>Signature Verification</strong><br /> Check if:<br /> <code>ssum * G = Rsum + c * X̃</code>.</p> <p><strong>Questions:</strong></p> <ol> <li><p><strong>Sharing ti, Ri, and si:</strong><br /> How do participants send their commitments (<code>ti</code>), share their <code>Ri</code> values, and exchange partial signatures (<code>si</code>)? What does this process look like in practice? Is there a standard, asynchronous, and user-friendly way to manage this in software? Or do participants need to manually compute their <code>si</code>, sum them, and share the results back and forth?</p> </li> <li><p><strong>Verification Process:</strong><br /> Who verifies the final signature <code>(Rsum, ssum)</code>? When and how does this verification happen in real-world Bitcoin use cases? Is the verification done via P2SH scripts?<br /> And regarding the initiation of the verification process—does a participant (e.g., one of the multisig signers) who has collected all the <code>Rsum</code> and <code>ssum</code> values create the transaction from the P2SH address? Or am I misunderstanding this flow?</p> </li> <li><p><strong>What Happens Without Commitments?</strong><br /> What could an adversary do if the commitments (<code>ti</code>) were not part of the protocol? What kind of attacks could occur, and how would they exploit the lack of commitments?</p> </li> </ol>

https://bitcoin.stackexchange.com/q/105154 2 Hellwerker https://bitcoin.stackexchange.com/users/92876 2025-08-06T09:01:15Z 2025-08-06T17:18:38Z

<p>I know that it is possible to create a 2-2 multsig using Taproot by combining both private keys into one public key and defining that as the key path spend. I also know that it is possible to use Tapscript to do the same thing with a script path spend using OP_CHECKSIGADD.</p> <p>Is it also possible to use key aggregation in the script path spend, by just providing a public key and signature but doing the same key aggregation as in the key path spend? If so, would it ever make sense to use a &quot;normal&quot; OP_CHECKSIGADD operation in the case of multisig (not threshold signatures).</p>

https://bitcoin.stackexchange.com/q/109918 1 pseudozach https://bitcoin.stackexchange.com/users/72197 2025-08-06T18:28:18Z 2025-08-06T21:58:35Z

<p>What's the technical limitation stopping multiple entities from collectively managing an LN node?</p> <p>I understand all parties (entities that share the Node private key) need to be online to sign routing/sending/creating invoices. If we assume this is the case and they're queried by a simple API for their signature for each such action, is there another technical limitation to why pooled/combined/shared nodes like this can not exist?</p> <p>The use case is to have multiple parties contribute funds and run a larger LN node with more liquidity.</p>

https://bitcoin.stackexchange.com/q/106929 8 Dalit Sairio https://bitcoin.stackexchange.com/users/123331 2025-08-06T07:47:11Z 2025-08-06T06:45:24Z

<p>With multisig, up to 20 signatures may be used in a threshold signature scheme (<a href="https://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses">What are the limits of m and n in m-of-n multisig addresses?</a>).</p> <p>As far as I understand, there should be no hard-coded limit with MuSig, as to the blockchain every scheme would always look like just one single signature (from one single key-pair), even if in reality those were multiple signatures that just were aggregated into one.</p> <p>Is there anything else that limits the amount of signatures that can be used with MuSig, or is this number of possible signatures essentially infinite?</p>

百度