--- Log opened Thu Aug 22 00:00:48 2019
00:30 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 250 seconds]
00:57 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]
00:57 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1
04:21 -!- jonatack [~jon@213.152.161.165] has joined #secp256k1
04:52 -!- jonatack [~jon@213.152.161.165] has quit [Ping timeout: 258 seconds]
05:37 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #secp256k1
06:06 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
06:17 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1
06:25 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-whsxtyblbicdxaok] has joined #secp256k1
06:27 -!- ariard [~ariard@167.99.46.220] has quit [Ping timeout: 248 seconds]
06:27 < elichai2> So it looks like without gmp mod inverse of 0 pass correctly and with gmp it aborts.
06:27 -!- ariard [~ariard@167.99.46.220] has joined #secp256k1
06:40 < elichai2> The `VERIFY_CHECK(gn == 1);`is what makes it abort. i'm not sure if this is an ok behavior (I don't think so because it diverges gmp/non-gmp) and if not should this verify check be changed or should I just add an if that if it's zero just set the result to zero and return
06:41 < elichai2> (clarification, this is only a problem in the variable time inverses, as they're the only ones that use gmp, the non variable and without gmp are inversing 0 to 0 just fine)
06:47 < elichai2> FYI, AFAICT this is not a real problem because all high level api does a `if (secp256k1_scalar_is_zero(sigr) || secp256k1_scalar_is_zero(sigs)) { return 0; }` check so it doesn't try to inverse a 0. this is only a problem for `secp256k1_fe_inv_all_var` and my `secp256k1_scalar_inv_all_var` because in a list it's a bit harder to check for zeros and move them. easier to check after the inverse, when you actually are
06:47 < elichai2> using them (but in practice these function currently aren't used outside of tests)
06:55 -!- jtimon [~quassel@76.85.11.37.dynamic.jazztel.es] has joined #secp256k1
07:44 -!- harding [~harding@cpe-66-91-121-125.hawaii.res.rr.com] has quit [Ping timeout: 248 seconds]
07:45 -!- harding [~harding@cpe-66-91-121-125.hawaii.res.rr.com] has joined #secp256k1
08:41 < elichai2> thoughts? should I PR to add this check to the `secp256k1_*_inv_all_var` functions?
08:41 < elichai2> *(not all, the regular `inv_var`)
08:43 < sipa> elichai2: aborting when called in an incorrect way does not need to be consistent
08:44 < sipa> it's just an assertion
08:44 < elichai2> is it incorrect to inverse a zero? hmm
08:44 < sipa> yes
08:44 < sipa> it's not defined
08:45 < sipa> if that's not clear from the code you can document it instead
08:49 < elichai2> you're right it's mathmatically wrong. my mistake. for some reason I remembered that 0^-1 mod p = 0 mod p. but I was wrong. i'll need to sort out the zero r's before i'm inverting anything
08:49 < elichai2> (that's too bad, it makes the code less elegant but can't change math lol)
08:50 < sipa> r cannot be 0 in a valid signature
08:51 < sipa> and z cannot be 0 in a non-infinity gej
08:52 < elichai2> yeah z==0 is even worse(devision by zero). the thing if a signature'
08:53 < elichai2> *signature's r is zero I want to skip that verification but do the rest, which makes it hard to track the right index if I'm using `secp256k1_scalar_inv_all_var` to inverse the r's (because then i need to keep a list of the non-zero r's and a list of which signatures does these r's *actually represent*)
08:55 < sipa> you can just immediately return failure in that case
08:55 < sipa> as there can be no points for that sig
08:56 < elichai2> yes but only for that signature
08:56 < elichai2> I still need to check the rest
08:56 < elichai2> but if I batch the r inversions I'll now have list of r's whos indexs don't match the indexs of the signatures
08:58 < sipa> if not all signatures have at least one point, the CMS is definitely invalid
08:59 < real_or_random> let me remind everybody that we're not sure about patents ^^
09:00 < elichai2> real_or_random: patents of what?
09:01 < real_or_random> there is at least one patent that claims pubkey recovery for ECDSA
09:03 < elichai2> sipa: really? because it just checks how many are valid it doesn't care what's the reason it's not valid: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1016 (But I might be misunderstanding the code here, the interperter.cpp code isn't too fun and explanatory)
09:03 < elichai2> real_or_random: really? lol, it's in the SEC
09:03 < sipa> elichai2: CMS gets k sigs and n pubkeys
09:03 < elichai2> damn it "The reader’s attention is called to the possibility that compliance with this document may require use of an invention covered by patent rights."
09:03 < sipa> to implement k-of-n
09:04 < elichai2> sipa: so even if one fails that's it. gotcha
09:04 < sipa> elichai2: if one of those k is invalid, the k of n can never be reached
09:05 < andytoshi> sipa: yes, iirc certicom has a patent on recovery
09:05 < elichai2> so why doesn't it fail on the first falsy `fOk`?
09:05 < andytoshi> "maybe"
09:06 < andytoshi> my opinion was that if they ever bothered trying to ligigate about it, they'd go after ethereum first because they use it -everywhere- in critical places
09:06 < sipa> elichai2: ask satoshi
09:06 < andytoshi> whereas if they complained at us we'd shrug, disable signmessage and this optimization, and go on with our lives
09:06 < elichai2> sipa: :)
09:06 < andytoshi> but gmax felt this was reckless
09:06 < andytoshi> and e.g. complained at me for enabling the recovery module in rust-secp by default
09:07 < sipa> elichai2: it would be much cleaner if the secp code worked correctly with sigs that have no valid pubkeys, but if that's hard, don't sweat it
09:08 < sipa> please don't discuss legal stuff in here
11:29 -!- gleb [sid306870@gateway/web/irccloud.com/x-ygxmnjkyvaqipiud] has joined #secp256k1
11:29 < real_or_random> gleb: where do you get this?
11:29 < gleb> yeah so i'm running unit tests on a freshly built bitcoin node
11:29 < gleb> And they all horribly fail
11:30 < gleb> test_bitcoin: key.cpp:344: void ECC_Start(): Assertion `secp256k1_context_sign == nullptr' failed.
11:31 < gleb> by freshly built I mean "make -j4" and all that
11:32 < sipa> that means you're calling ECC_Start 2 times in a row without a Stoo in between
11:32 < real_or_random> right
11:32 < real_or_random> which revision are you building?
11:32 < gleb> Okay let me compile master to see for sure
11:53 < elichai2> you're on 0.18 according to the lines in key.cpp
11:56 < kanzure> "standards for efficient cryptography" you threw me for a loop
12:02 < gleb> real_or_random: okay seems to be the issue with my new code, although I have no idea why and btw worked fine on macos :)
12:15 < gleb> turned out to be totally my issue and nothing to do with operating system too.
12:44 < real_or_random> gleb https://github.com/bitcoin/bitcoin/issues/16288
12:45 < gleb> Might be relevant, thanks, although my issue is on all systems actually.
12:47 < real_or_random> kk
13:08 < gleb> Okay so the library I integrated had assert(false). I haven't noticed that log, but instead I noticed hundreds of ECC_Start bad logs :) Hope this knowledge will save somebody half an hour in future.
13:21 < elichai2> gleb: what library is that?
13:22 < gleb> My interpretation of pieter's python code for ip->asn mapping.
13:22 -!- digi_james [sid281632@gateway/web/irccloud.com/x-hcjqmmywqumzjqio] has joined #secp256k1
13:25 < real_or_random> and how do you get these errors then? because assert(false) aborts the test case and then the next one is started?
13:30 < gleb> Dunno, this code was used in 2 test cases really, but it seems like all the * following* test cases also produced the error.
13:35 < real_or_random> right, that's what I meant
13:36 < real_or_random> so the one test case was aborted without calling ECC_Stop()... and then every following test case asserts
13:36 < real_or_random> I guess there could be a better error message
13:54 < waxwing> i saw someone bring this up on the coincurve repo but i now realise it also interests me: what's the reason for using 01/02 here? https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/ecdh/main_impl.h#L14
13:55 < waxwing> iiuc you can pass custom hash functions anyway but still want to know
13:56 < sipa> waxwing: it's using 02/03
13:56 < sipa> encoding like compressed public keys usually are
13:59 < waxwing> oh duh
13:59 < real_or_random> (which doesn't save a lot in the end due the 64 bit block size of SHA256 ^^)
14:01 < waxwing> thanks :)
14:41 -!- jtimon [~quassel@76.85.11.37.dynamic.jazztel.es] has quit [Quit: gone]
15:34 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]
15:34 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #secp256k1
18:17 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-whsxtyblbicdxaok] has quit [Quit: Connection closed for inactivity]
18:31 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bfkkrywaeduvnxfb] has joined #secp256k1
19:28 -!- roconnor [~roconnor@host-184-164-11-222.dyn.295.ca] has quit [Quit: Konversation terminated!]
20:57 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bfkkrywaeduvnxfb] has quit [Quit: Connection closed for inactivity]
22:32 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
23:14 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
23:14 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
23:18 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 244 seconds]
23:35 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
23:41 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
23:42 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
23:45 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has joined #secp256k1
23:46 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 272 seconds]
23:51 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
23:52 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
23:57 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 272 seconds]
--- Log closed Fri Aug 23 00:00:51 2019