--- Log opened Wed Jul 07 00:00:59 2021 07:10 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 07:12 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1 07:22 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 07:24 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1 08:51 < real_or_random> it would be nice to have some opinions on what we should do with the context object https://github.com/bitcoin-core/secp256k1/pull/956#issuecomment-874607474 08:53 < sipa> i don't think after having mamdatory precomputation of ecmult tables, we still need to demand a verify-initialized context object 08:54 < sipa> but context objects are still useful (randomization for batch verify maybe)? 09:18 < real_or_random> yes, randomization is still helpful 09:18 < real_or_random> and good point about batch verification... 09:19 < real_or_random> so we just probably at least deprecate some context flags (i.e., make them irrelevant) 09:20 < sipa> yeah, i think we can remove the verify context flag 09:20 < sipa> or make it "for backward compatibility only" 09:20 < real_or_random> sipa: in this PR or later together with the sign flag? 09:21 < sipa> can be done later i think 09:21 < real_or_random> if the only/main purpose of contexts is randomization, then having a mutable context is probably a good idea. https://github.com/bitcoin-core/secp256k1/issues/780#issuecomment-670632456 09:21 < real_or_random> but this is a breaking API change. 09:21 < sipa> hmm 09:21 < sipa> that's scary, at least for existing API calls 09:22 < sipa> because it changes how users need to do locking etc 09:22 < real_or_random> yep... 09:23 < real_or_random> maybe then it's better to have a context-v2 that really breaks the API ... not elegant either 09:24 < real_or_random> or simpler: create new functions _sign_randomized() etc. that modify the contexts 09:25 < real_or_random> but don't touch the existing functions. 10:47 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 252 seconds] 10:48 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1 12:13 < gmaxwell> If thats done people will just use the old one. 12:16 < sipa> we could hope that a change to the function definition from const to non-const context is enough to make people check that locking etc is safe 12:17 < sipa> but i'm kind of worried about introducing race conditions in application if we just silently make contexts mutable 12:19 < roconnor> Even if people don't use the function, I don't see how they can use _sign_randomized() without unexpected careful thought about concurrent access. 12:33 < gmaxwell> sipa: It's fine to just change the function name, but if the older function is left around esp with the simpler name, thats what virtually everyone will use. 12:35 < gmaxwell> roconnor: Stateful code is ubiquitous. People do get it wrong, for sure. Ones who don't want to worry about concurrent access will just create one shot contexts and throw them out. 13:18 -!- merkle_noob [~merkle_no@129.0.212.252] has joined #secp256k1 14:12 -!- belcher_ is now known as belcher 16:15 -!- merkle_noob [~merkle_no@129.0.212.252] has left #secp256k1 [] 17:22 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1 17:24 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds] --- Log closed Thu Jul 08 00:00:00 2021