--- Log opened Sat Dec 12 00:00:44 2020 03:07 -!- jonatack [~jon@213.152.161.244] has quit [Ping timeout: 256 seconds] 03:24 -!- jonatack [~jon@88.124.242.136] has joined #secp256k1 03:29 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 264 seconds] 03:30 -!- jonatack [~jon@213.152.161.40] has joined #secp256k1 06:13 < sanket1729> sipa: One last question, even with these experiments and from the paper results we don't know how tight the bound is right? 07:57 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #secp256k1 08:00 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] 08:04 -!- jonatack [~jon@213.152.161.40] has quit [Ping timeout: 240 seconds] 08:06 -!- belcher_ is now known as belcher 08:06 -!- jonatack [~jon@109.232.227.138] has joined #secp256k1 08:42 -!- jonatack [~jon@109.232.227.138] has quit [Quit: jonatack] 09:05 -!- jonatack [~jon@88.124.242.136] has joined #secp256k1 09:10 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 240 seconds] 09:10 -!- jonatack [~jon@213.152.162.84] has joined #secp256k1 09:33 < sipa> sanket1729: indeed 09:33 < sipa> sanket1729: a while ago i tried searching for inputs that need many iterations 09:34 < sipa> but iirc the worst we found was 679 or so 09:50 < sipa> sanket1729: i think this is a good way of explaining delta:s purpose 09:52 < sipa> * Compared to more traditional GCD algorithms, this has the property of only ever looking at the * low-order bits of the variables to decide the next steps, and being easy to make constant-time. * The delta parameter tracks knowledge of how much smaller g is than f; it guides the algorithm 09:52 < sipa> * in the direction of shrinking the numbers' magnitude without explicitly needing to look at high * order bits. --- Log closed Sat Dec 12 12:37:25 2020 --- Log opened Sat Dec 12 12:37:25 2020 13:07 -!- jonatack [~jon@213.152.162.84] has quit [Ping timeout: 256 seconds] 17:45 < andytoshi> ubsan on elements is complaining about the line vch1[i] = ~vch1[i] in elements, where vch is a vector of unsigned char 17:45 < andytoshi> because, i think, ~ promotes vech1[i] to an int, and then there's an implicit conversion back to unsigned char (of a negative number) 17:46 < andytoshi> is this seriously how C (and C++) works? what is the "correct" way to invert a byte 17:47 < sipa> that's indeed how it works, but there is nothing UB there 17:48 < sipa> are you enabling some of the optional ubsan stuff that detects some other pitfalls? 17:48 < andytoshi> ok, cool. i didn't think it was UB, but one of the sanitizers still doesn't like it 17:48 < andytoshi> i assume so ...this is using the bitcoin core cirrus setup 17:49 < sipa> ah yes the bitcoin core CI setup does enable some more things (which i'm occasionally annoyed by...) 17:51 < andytoshi> yeah, there was another instance where it made me add an explicit cast, which seemed more reasonable 17:51 < sipa> you could use vch1[i] ^= '\xff'; 17:51 < andytoshi> but this does not seem reasonable 17:51 < andytoshi> yeah, i'll try that 17:51 < andytoshi> although .. i'm fucking with the script interpreter on the advice of the ubsan, which is complaining about code that i know is ok...which i do not like on principle 17:51 < andytoshi> but i guess these are clearly equivalent 17:52 < andytoshi> i think 0xff is clearer than '\xff'. both are signed ints IIRC 17:52 < andytoshi> i could do 0xffu 17:52 < sipa> '\xff' is a char 17:52 < sipa> i think? 17:53 < sipa> u'\xff' is probably best, it's an unsigned char 17:53 < andytoshi> ah good call 17:53 < sipa> i mean 17:53 < sipa> all of these are equivalent, and valid C++ 17:53 < sipa> even the original 17:54 < andytoshi> ok, glad i'm not crazy 18:07 < sipa> ah, in C character literals have type int 18:07 < sipa> in C++ they're char 19:42 < andytoshi> ah, nice. ok, i was sure i remembered something like that --- Log closed Sun Dec 13 00:00:45 2020