Re: Is It Possible to Verify Participation In Aggregated Signatures

Let's see how keys are aggregated:

Code:

P3=024CBBD03BC9B079BC360A26A034A298EB4520333F87DA4A3D195F390B50B7BD27
P2=027FA2874F02C66B1B7778FD178E8332CF113FDB5536F2005E83DD1F6E77037A89
P1=02A3D48DC0B2BA69F340F68FB4D8BEEF5BE361FB64DAB71EF74ACCF6ACABF70B01
SHA-256("KeyAgg list")=481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0
SHA-256(481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0)=634f77a422b6a39257a76f2c13ae017702bacd4c49b33dad1139cdd56060d360
SHA-256(481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0024CBBD03BC9B079BC360A26A034A298EB4520333F87DA4A3D195F390B50B7BD27027FA2874F02C66B1B7778FD178E8332CF113FDB5536F2005E83DD1F6E77037A8902A3D48DC0B2BA69F340F68FB4D8BEEF5BE361FB64DAB71EF74ACCF6ACABF70B01)=9309c24c2bc0162de694d5f3a80e35cd17e7db4afd1994b86a1470dc4ea5bf57

Then, the aggregated hash is 9309c24c2bc0162de694d5f3a80e35cd17e7db4afd1994b86a1470dc4ea5bf57, if those three keys are sorted. Because SHA-256 is executed in 512-bit chunks, it is aligned in this way:

Code:

6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19

481c971c 3c0b46d7 f0b275ae 598d4e2c
7ed7319c 594a5c6e c79ea0d4 990294f0
481c971c 3c0b46d7 f0b275ae 598d4e2c
7ed7319c 594a5c6e c79ea0d4 990294f0

b399d5e0 c8fff302 6badac71 07c5b7f1 9701e2ef 2a72ecf8 201a4c7b ab148a38

024CBBD0 3BC9B079 BC360A26 A034A298
EB452033 3F87DA4A 3D195F39 0B50B7BD
27027FA2 874F02C6 6B1B7778 FD178E83
32CF113F DB5536F2 005E83DD 1F6E7703

e4408850 f10bfbab 723cc288 07ec49e0 491d6a67 50fff49c 2b6358ec 0ac4bc1a

7A8902A3 D48DC0B2 BA69F340 F68FB4D8
BEEF5BE3 61FB64DA B71EF74A CCF6ACAB
F70B0180 00000000 00000000 00000000
00000000 00000000 00000000 00000518

9309c24c 2bc0162d e694d5f3 a80e35cd 17e7db4a fd1994b8 6a1470dc 4ea5bf57

So, I guess by providing some in-between hashes, it could be possible to prove, that the aggregated hash contained a specific public key. For example, for the last key:

Code:

e4408850 f10bfbab 723cc288 07ec49e0 491d6a67 50fff49c 2b6358ec 0ac4bc1a

7A8902A3 D48DC0B2 BA69F340 F68FB4D8
BEEF5BE3 61FB64DA B71EF74A CCF6ACAB
F70B0180 00000000 00000000 00000000
00000000 00000000 00000000 00000518

9309c24c 2bc0162d e694d5f3 a80e35cd 17e7db4a fd1994b8 6a1470dc 4ea5bf57

Of course, public keys are not-so-well-aligned, because they take 33 bytes, instead of 32, but still, picking any other keys will change the initialization vector from e4408850f10bfbab723cc28807ec49e0491d6a6750fff49c2b6358ec0ac4bc1a to something else. And picking any other data, would very likely not hash into 9309c24c2bc0162de694d5f3a80e35cd17e7db4afd1994b86a1470dc4ea5bf57. But: I still have to dig deeper into the code, to produce more detailed logs.

I assume at least some of my assumptions about SHA-256 are correct, because I found the same constants in the code:
https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/musig/keyagg_impl.h#L64

Code:

/* Initializes SHA256 with fixed midstate. This midstate was computed by applying
* SHA256 to SHA256("KeyAgg list")||SHA256("KeyAgg list"). */
static void secp256k1_musig_keyagglist_sha256(secp256k1_sha256 *sha) {
secp256k1_sha256_initialize(sha);

sha->s[0] = 0xb399d5e0ul;
sha->s[1] = 0xc8fff302ul;
sha->s[2] = 0x6badac71ul;
sha->s[3] = 0x07c5b7f1ul;
sha->s[4] = 0x9701e2eful;
sha->s[5] = 0x2a72ecf8ul;
sha->s[6] = 0x201a4c7bul;
sha->s[7] = 0xab148a38ul;
sha->bytes = 64;
}