Tim Ruffing

> Hence, I would vote to remove the flag summary from the configure log. If there is a need for exact flags, we should provide a proper, trustworthy solution. I...

> @purpleKarrot > > > If there is a need for exact flags, we should provide a proper, trustworthy solution. > > Hard to disagree. Could you share any ideas...

> @real-or-random, what do you think is the best course of action? It would probably make sense to first get the licensing update you propose in? See #1892.

> (nit, a few mentions of "GNU All-Permissive" that perhaps would be less confusing if changed to "FSF All Permissive" per [spdx.org/licenses/FSFAP](https://spdx.org/licenses/FSFAP)) I kept them intentionally because i) "GNU All-Permissive"...

> Yes, it's the discrepancy with the "FSFAP" license headers in those BIPs that gave me pause. I guess anyone who really wants to know will figure out that FSFAP...

> BIP 3 cites RFC 7282 as its rough consensus framework, This is not true. BIP 3 cites RFC 7282 as "Related Work". This indicates in no way that RFC...

Concept ACK > We should, however, remove the functions for MuSig2 adaptor signatures as they lack both a specification and a satisfactory security proof. Makes sense.

> We’ve integrated the MuSig2 branch into the Nunchuk wallet so you can try it with a real UI: [nunchuk.io/blog/taproot-multisig](https://nunchuk.io/blog/taproot-multisig). Great to see it in production! > **Quantum‑computing question (let...

> The array-as-a-param makes this annoying because `sizeof(l)` is not helpful. Hm, yeah, idk, the `uint64_t l[8]` parameter declaration is a bit strange, or at least unusual for this code...

> ```c > void func(uint64_t l[static 8]) > ``` Haha okay, I totally wasn't aware of this, even though I happen to look at the standards text from time to...