--- Log opened Mon Jun 06 00:00:44 2022
07:04 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
09:59 < michaelfolkson> BIP341 recommended having a Taproot commitment even if no script path as some key aggregation schemes (MSDL-pop, not MuSig) allowed a malicious party to add a script path without being noticed.
10:00 < michaelfolkson> FROST isn't affected right? In same category as MuSig rather than MSDL-pop?
10:21 < sipa> This taproot tweaking can be done on top of FROST or MSDL-pop or MuSig still.
10:22 < michaelfolkson> I'm thinking if you were using MuSig2 or FROST and didn't need a script path the privacy benefit from tweaking the internal pubkey would be minimal. You are already hiding the multisig/threshold key aggregation scheme. Would you care about leaking the fact you didn't have a script path? For key aggregation tests you certainly wouldn't bother tweaking the internal pubkey right?
10:22 < sipa> It's not a privacy benefit.
10:23 < sipa> The reason for tweaking with an empty script is (a) if you want to be able to prove to a third party that no script path is present and (b) to make sure no malicious contributor introduces a script path. (b) may be possible through other means as well.
10:27 < michaelfolkson> Ok a third party who didn't know the individual pubkeys in a scheme like MuSig2
10:29 < sipa> BIP341 just recommends it for these reasons, but in many cases it isn't actually necessary to do this tweaking. It's just easier to just aim for a single standard that's always appropriate than needing to convey the circumstances in which it may or may not matter.
10:31 < michaelfolkson> A third party who wants to know there isn't a hidden script path but who isn't allowed to know the individual pubkeys sounds a bit tenuous (but maybe they will exist). I get the motivation for a single standard obviously
10:32 < sipa> Knowing the individual pubkeys isn't enough in MSDL-pop or FROST, I think.
10:32 < sipa> In MuSig it is.
10:33 < michaelfolkson> Would you say even in tests the single standard should always be followed (tweaking internal pubkey by empty script)?
10:33 < michaelfolkson> I guess tests should follow the standard
10:33 < sipa> Depends what the test is testing.
10:34 < sipa> https://github.com/bitcoin/bitcoin/pull/23480 for example specifically adds a descriptor that bypasses the tweaking; obviously tests for that (if any) can't expect the tweaking to happen.
10:38 < michaelfolkson> Tests that are just generating P2TR addresses without needing script paths or testing key paths specifically. Tests that don't care whether there is a script path or not I guess was my question
10:41 < michaelfolkson> That PR is an interesting case. There *is* a tweak just that the descriptor doesn't know what it is
10:41 < sipa> Well, maybe. There could also not be one.
10:47 < michaelfolkson> There is an empty script or a non-empty script tweak I mean
10:47 < michaelfolkson> Rather than no tweak at all
10:51 < michaelfolkson> If you can spend with an untweaked private key you know there isn't a tweak (empty script or non-empty script tweak)
10:53 < michaelfolkson> (assuming not using a key aggregation scheme)
15:41 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.5]
21:12 -!- jesseposner [~jesse@user/jesseposner] has quit [Ping timeout: 246 seconds]
21:14 -!- jesseposner [~jesse@user/jesseposner] has joined #secp256k1
--- Log closed Tue Jun 07 00:00:45 2022