--- 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