Per BIP327, MuSig2 key aggregation is defined for u public keys where 0 < u < 2^32.
Previously, the code did not handle u == 0.
This patch updates the code to reject an empty pubkey list and adds a regression test.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35316.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | rkrux, achow101 |
| Concept ACK | real-or-random |
If your review is incorrectly listed, please copy-paste <code><!--meta-tag:bot-skip--></code> into the comment that the bot should ignore.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
Yes, this secp256k1_musig_pubkey_agg call will crash when the last argument is 0.
Concept ACK
edit: Okay, I'm not sure if returning false in the cache is the proper thing to do because I don't know about the callers of GetMuSig2KeyAggCache. But I can say that we shouldn't call secp256k1_musig_pubkey_agg with a 0 as the last argument. Aggregating zero keys is not very meaningful and we shouldn't let the user do this.
lgtm ACK 8ce84321ceaf16c0ee3418d30011c357fdc46deb
Most of the transitive callers of GetMuSig2KeyAggCache function already have related checks in place such as the ones called in the creation of nonce, partial sig, and aggregate sig. So adding this check should not be fixing any burning issue, but adding it is also not harmful and makes the implementation BIP compliant (even more).
ACK 8ce84321ceaf16c0ee3418d30011c357fdc46deb