--- Day changed Wed Aug 08 2018 00:05 -!- Miron17 [~Miron@121.150.158.191] has joined #secp256k1 00:06 -!- Miron17 [~Miron@121.150.158.191] has quit [Remote host closed the connection] 00:07 -!- jercos15 [~jercos@177.125.20.131] has joined #secp256k1 00:12 -!- jercos15 [~jercos@177.125.20.131] has quit [Ping timeout: 240 seconds] 00:21 -!- nhandler25 [~nhandler@93.117.16.16] has joined #secp256k1 00:27 -!- nhandler25 [~nhandler@93.117.16.16] has quit [Ping timeout: 248 seconds] 01:39 -!- enyc7 [~enyc@66-214-106-174.dhcp.flln.nv.charter.com] has joined #secp256k1 01:39 -!- enyc7 [~enyc@66-214-106-174.dhcp.flln.nv.charter.com] has quit [Remote host closed the connection] 01:45 -!- sneakyness [~sneakynes@62.16.50.226] has joined #secp256k1 01:47 -!- sneakyness [~sneakynes@62.16.50.226] has quit [Remote host closed the connection] 02:07 -!- oldschool^4 [~oldschool@172.134.151.153.ap.dti.ne.jp] has joined #secp256k1 02:09 -!- oldschool^4 [~oldschool@172.134.151.153.ap.dti.ne.jp] has quit [Remote host closed the connection] 03:19 -!- CGML1 [~CGML@187.110.232.22] has joined #secp256k1 03:24 -!- CGML1 [~CGML@187.110.232.22] has quit [Ping timeout: 240 seconds] 03:26 -!- Steinsplitter23 [~Steinspli@pc-246-190-86-200.cm.vtr.net] has joined #secp256k1 03:28 -!- Steinsplitter23 [~Steinspli@pc-246-190-86-200.cm.vtr.net] has quit [Remote host closed the connection] 03:37 -!- sneakyness [~sneakynes@188.242.105.243] has joined #secp256k1 03:38 -!- sneakyness [~sneakynes@188.242.105.243] has quit [Remote host closed the connection] 03:40 -!- deusexbeer [~deusexbee@080-250-078-032-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!] 03:41 -!- Theking^28 [~Theking^@113.195.165.139] has joined #secp256k1 03:42 -!- Theking^28 [~Theking^@113.195.165.139] has quit [Remote host closed the connection] 03:56 -!- Aleszandro [~Aleszandr@p228173-ipngn2901akatuka.ibaraki.ocn.ne.jp] has joined #secp256k1 03:57 -!- Aleszandro [~Aleszandr@p228173-ipngn2901akatuka.ibaraki.ocn.ne.jp] has quit [Remote host closed the connection] 04:06 -!- thomas16 [~thomas@127.47.18.95.dynamic.jazztel.es] has joined #secp256k1 04:07 -!- thomas16 [~thomas@127.47.18.95.dynamic.jazztel.es] has quit [Remote host closed the connection] 05:03 -!- grumble8 [~grumble@175.193.236.11] has joined #secp256k1 05:03 -!- grumble8 [~grumble@175.193.236.11] has quit [Remote host closed the connection] 05:21 -!- vespaper [~vespaper@117.243.194.6] has joined #secp256k1 05:22 -!- vespaper [~vespaper@117.243.194.6] has quit [K-Lined] 05:43 < andytoshi> roconnor: fwiw i have had many instances in new test code where valgrind would complain at me about branching on uninitialized memory and the solution was to set more than just the infinity flag 05:43 < andytoshi> which suggests that valgrind can detect when we actually screw up here, and since it always runs clean on master (as a matter of policy) maybe we're ok 05:46 < nsh> plus who needs undefined behaviour in the compiler when the processors are chock full of it anyway 05:47 < nsh> (i keed, somewhat) 05:59 -!- CGML29 [~CGML2@cpe-76-175-112-98.socal.res.rr.com] has joined #secp256k1 05:59 -!- CGML29 [~CGML2@cpe-76-175-112-98.socal.res.rr.com] has quit [Remote host closed the connection] 06:47 -!- nikow5 [~nikow@106.75.54.33] has joined #secp256k1 06:48 -!- nikow5 [~nikow@106.75.54.33] has quit [Remote host closed the connection] 06:54 -!- Kazuto [~Kazuto@p1475127-ipngn201204tokaisakaetozai.aichi.ocn.ne.jp] has joined #secp256k1 07:00 -!- Kazuto [~Kazuto@p1475127-ipngn201204tokaisakaetozai.aichi.ocn.ne.jp] has quit [Ping timeout: 268 seconds] 07:00 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 07:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 248 seconds] 07:01 -!- lukedashjr is now known as luke-jr 09:15 < roconnor> I'm told that assigning uninitialized values is not allowed in VerifiedC. 09:16 < roconnor> So if I work through all the pre and post condtions through VerifiedC any such assignments should pop out. 09:16 < roconnor> However I'm months away from completing that projects. 09:17 < roconnor> andytoshi: Right. Upon further inspection I haven't technically been able to pinpoint any use of assignment of uninialized memory. 09:18 < roconnor> But I haven't noticed any particular attemps to prevent it either, beyond the fact that secp256k1_gej_set_infinity and friends initialize all fields. 09:46 -!- maaku_ is now known as maaku 09:53 < andytoshi> yes, i don't think we've tried to prevent it beyond valgrind running clean 10:04 <@gmaxwell> valgrind only complains about branching on it. 10:04 <@gmaxwell> I certantly review for any kind of usage of uninitilized memory, branching on it _will_ cause 'miscompliation'. 10:04 <@gmaxwell> But just copying it in an assignment? I haven't. 10:13 < roconnor> https://stackoverflow.com/questions/11962457/why-is-using-an-uninitialized-variable-undefined-behavior is an interested thread on stackoverflow. 10:17 <@gmaxwell> roconnor: is any of the verified c stuff that you're doing something that could help find more test cases? e.g. in our unrolled field and scalar multiplies, I'd like to have test vectors that hit every one of the condition tests. After testing a tremendous number of random cases, there are still some that are uncovered. Potentially they are actually unreachable. 10:18 < roconnor> It suggests that assignment is fine on an architecutre without trap representations so long as it is from a variable that could not have been declared register (for example by taking its memory address at some point in the program). But such code isn't portable. OTOH I think some other people dispute this. 10:19 < roconnor> gmaxwell: It's somewhat doubtful that I'd be able to produce test vectors. ... 10:19 < roconnor> the reason is that I set the pre and post-conditions myself, and throughout the reasoning of the code I am constanly weakining post conditions as I go through it. 10:20 < roconnor> That is to say, I may end up reasoning about states that are actually impossible to obtain, and this is all fine to do so long as I get something that implies the post condition of the function I've declared by the end. 10:21 <@gmaxwell> If you can prove some of these conditions impossible, then we could convert them into VERIFY asserts. So that would be useful. 10:22 < roconnor> Right, If you tell me what branches you think are impossible, I could make a reasonable attempt to prove that indeed they are impossible. 10:22 <@gmaxwell> Basically, I have a goal of getting the codebase to the point where it is difficult to add an error that the tests do not detect. Right now, however, you can go and just remove one of those conditionals, and the tests will not complain. Was that adding an error? I'm not sure. 10:22 < roconnor> Or at least specify pre-conditions that ensure that they are impossible. 10:23 < roconnor> I'm not actually working with VerfiableC right at the moment. I'm just thinking about the future as I scout through libsecp256k1 source code. 10:27 <@gmaxwell> We should probably rerun coverage just in case newer updates improved test coverage, but see https://people.xiph.org/~greg/libsecp256k1-coverage/src/scalar_4x64_impl.h.gcov.html line 521..554 shows the last comparison in the muladd never being used. 10:29 <@gmaxwell> the is one bracketed unit in the left column for each "branch" (for this purposes the comparison operators are branches, though they're not actually compiled into jumps) and it shows if both cases of the branch fired. 10:31 <@gmaxwell> I don't recall now though if I ever merged my scalar tests... I should verify that I did before you spend any actual time on it, since some of those I might have vectors for. Though I know that for at least some I was unable to.. even with trillions of random trials. 10:31 <@gmaxwell> (though irritatingly, for the field side at least, there were cases which I did eventually find vectors for but which actually took trillions of random tries to find ones for) 10:31 < roconnor> gmaxwell: unfortunately VerifiableC is 32-bit and doesn't support uint128_t at the moment. :( 10:32 < roconnor> hopefully one day. 10:32 <@gmaxwell> okay, well same deal exists for 32-bit. 10:32 < roconnor> In that case I can probably do something about it. 10:32 <@gmaxwell> Most of my testing effort has focued on 64-bit since the usage for bitcoin we care most about is 64-bit. 10:32 < roconnor> I haven't looked at the scalar code yet. I was about to. 10:32 <@gmaxwell> though it's a lot simpler than the field code, at least currently. 10:43 < roconnor> are scalar field operations even invoked for ECSchnorr? 10:44 <@gmaxwell> roconnor: the signing is a scalar multiply and add, for batch verification, all the blinding is via operations in the scalar field. 10:45 < roconnor> But maybe not for a single signature verification. 10:46 < roconnor> Although there is a call to negate @ https://github.com/bitcoin-core/secp256k1/blob/452d8e4d2a2f9f1b5be6b02e18f1ba102e5ca0b4/src/ecmult_impl.h#L278 10:47 <@gmaxwell> With blinding it might actually become worthwhile to make the scalar multiply faster. 10:57 -!- ken2812221 [~User@1.200.203.30] has quit [Ping timeout: 256 seconds] 10:58 -!- ken2812221 [~User@1.200.203.30] has joined #secp256k1 11:05 -!- Louis26 [~Louis@170.84.11.98] has joined #secp256k1 11:11 -!- Louis26 [~Louis@170.84.11.98] has quit [Ping timeout: 256 seconds] 11:36 -!- subo [~subo@KD027082060222.ppp-bb.dion.ne.jp] has joined #secp256k1 11:37 -!- subo [~subo@KD027082060222.ppp-bb.dion.ne.jp] has quit [Read error: Connection reset by peer] 11:42 -!- Globalirc16 [~Globalirc@185.150.94.157] has joined #secp256k1 11:43 -!- Globalirc16 [~Globalirc@185.150.94.157] has quit [Killed (Sigyn (Spam is off topic on freenode.))] 12:45 -!- Guest439871 [~Guest4398@41.207.103.110] has joined #secp256k1 12:46 -!- Guest439871 [~Guest4398@41.207.103.110] has quit [Killed (Sigyn (Spam is off topic on freenode.))] 13:31 -!- limbo9 [~limbo@109.201.56.97] has joined #secp256k1 13:32 -!- limbo9 [~limbo@109.201.56.97] has quit [Remote host closed the connection] 13:58 -!- TReK23 [~TReK@190-77-117-67.dyn.dsl.cantv.net] has joined #secp256k1 13:59 -!- TReK23 [~TReK@190-77-117-67.dyn.dsl.cantv.net] has quit [Remote host closed the connection] 14:31 -!- richardjohn [~richardjo@211.196.217.51] has joined #secp256k1 14:32 -!- richardjohn [~richardjo@211.196.217.51] has quit [Remote host closed the connection] 14:50 -!- Zanzibar16 [~Zanzibar@170.84.11.98] has joined #secp256k1 14:56 -!- Zanzibar16 [~Zanzibar@170.84.11.98] has quit [Ping timeout: 240 seconds] 14:59 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 15:00 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 15:07 -!- adiabat [~adiabat@63.209.32.102] has quit [Ping timeout: 244 seconds] 15:55 -!- maaku_ [~maaku@173.234.25.100] has joined #secp256k1 16:01 -!- TD--Linux [~Thomas@2604:a880:1:20::173:1001] has joined #secp256k1 16:02 -!- Netsplit *.net <-> *.split quits: maaku, TD-Linux 16:05 -!- TD--Linux [~Thomas@2604:a880:1:20::173:1001] has quit [Changing host] 16:05 -!- TD--Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #secp256k1 16:05 -!- TD--Linux is now known as TD-Linux 17:18 -!- Vlad14 [~Vlad@89-64-17-54.dynamic.chello.pl] has joined #secp256k1 17:19 -!- Vlad14 [~Vlad@89-64-17-54.dynamic.chello.pl] has quit [Remote host closed the connection] 18:21 -!- ken2812221 [~User@1.200.203.30] has quit [Read error: Connection reset by peer] 18:22 -!- ken2812221 [~User@1.200.203.30] has joined #secp256k1 18:44 -!- Guest31250 [~alyptik@89.148.166.167] has joined #secp256k1 18:45 -!- Guest31250 [~alyptik@89.148.166.167] has quit [Remote host closed the connection] 20:55 -!- r3m17 [~r3m@190.200.65.115] has joined #secp256k1 21:00 -!- r3m17 [~r3m@190.200.65.115] has quit [Ping timeout: 240 seconds] 21:30 -!- ken2812221 [~User@1.200.203.30] has quit [Read error: Connection reset by peer] 21:38 -!- foamz18 [~foamz@211.46.87.128] has joined #secp256k1 21:40 -!- foamz18 [~foamz@211.46.87.128] has quit [Remote host closed the connection] 22:03 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds] 22:03 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 23:31 -!- MobileMatt [~MobileMat@156.212.254.251] has joined #secp256k1 23:37 -!- MobileMatt [~MobileMat@156.212.254.251] has quit [Ping timeout: 256 seconds]