--- Log opened Sun May 03 00:00:11 2020 00:58 < elichai2> Ok, we definitely want to add the error-exitcode, because there's already a ctime failure in travis that we missed because of it https://travis-ci.org/github/bitcoin-core/secp256k1/jobs/681571334#L454 00:59 < elichai2> but it's only with `-O0`, so I assume we should just disable the ctime test under that flag? 05:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds] 06:10 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #secp256k1 07:03 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1 10:10 < elichai2> lol apparently stumbling across a random (sig,msg,pubkey) tuple is likelier than I'd thought (the fuzzer found one, although not sure that it counts as the msg is 0 hehe) 10:19 < sipa> fuzzers don't try random input, so the act of finding one has nothing to do with probability 10:20 < sipa> (or at least not uniformly randomlyk 10:35 < elichai2> I know, I just wanted to try some "rainy day" scenario in the fuzzer, that will be equal to breaking ecdsa verification 10:37 < sipa> right 10:37 < sipa> it found msg=0 ? 10:37 < sipa> or rather H(msg)=0, in proper ECDSA 10:39 < elichai2> yep, it found msg=0 pubkey=[0x02;33], and sig=[0x02;64] 10:39 < elichai2> I guess I can hard code a msg+pubkey and let it "find" a signature 10:42 < sipa> combining it with the small group mode we use for exhaustive checks may be useful 10:42 < sipa> though, those are already exhaustively tested of course - fuzzing won't find more paths generally 10:43 < elichai2> the exhaustive test idea is pretty awesome. is any other project doing something like that? 10:43 < sipa> not that i know of --- Log closed Mon May 04 00:00:10 2020