--- Log opened Fri Nov 08 00:00:03 2019
01:22 < elichai2> gmaxwell: I tested if it's viable to run valgrind in travis. took 24 minutes just for that job *without* recovery and ecdh https://travis-ci.org/elichai/secp256k1/jobs/608937548
01:23 < elichai2> I just looked at it and it reports dozens of errors? weird. i'll look into it locally
01:36 < gmaxwell> they're running with a garbage copy of openssl (not compiled with -DPURIFY)
01:37 < elichai2> ohh rightt, forgot about that, i'll add `-DPURIFY` but it's still 24 minutes... (and I wasn't sure if I should add `-DVALGRIND` or is that something valgrind do by itself)
01:37 < gmaxwell> damn, travis is slow. I think travis does a lot of harm to projects by not providing them with much computing power, discouraging agressive testing.
01:38 < elichai2> honestly? I think a lot of projects cheap out to travis instead of running a self hosted thing
01:38 < gmaxwell> elichai2: using -DPURIFY requires recompiling OpenSSL.
01:38 < elichai2> (like most enterprise projects)
01:39 < gmaxwell> elichai2: yes, but a lot of projects that would otherwise have significant amounts of computing power don't because travis just gets itself made a default.
01:39 < gmaxwell> elichai2: you can disable the openssl based tests in libsecp256k1 for the valgrind run.
01:39 < elichai2> gmaxwell: arghh, so i'll disable opensssl. i'm wondering what takes more time in valgrind, allocations+freeing or general computation but slower (i.e. should I increase the windows and precisions or decrease)
01:40 < gmaxwell> It should be much faster without those errors in any case (any error valgrind detects slows it down a lot).
01:40 < elichai2> gmaxwell: yeah. but even when you pay it's not really proportional to computation power
01:40 < elichai2> i'll give it a try without openssl
01:40 < gmaxwell> elichai2: yea, no, travis is always slow even if you're paying for it.
01:41 < gmaxwell> I'm not sure which libsecp256k1 config would be fastest, in any case where it's only going to be testing one config, testing something closest to a default is better.
01:41 < gmaxwell> libsecp256k1 tests compiled with -DVALGRIND is best, as that turns on the valgrind specific instrumentation.
01:41 < elichai2> i.e. https://github.com/bitcoin/bitcoin/pull/17402. I agree with them, but it sucks. we need powerful machines, I wonder how people would react if I tried to push azure pipelines
01:45 < gmaxwell> What we use with xiph is just a copy of jenkins, and it can run jobs on anything that can be SSHed into.  The problem you run into is that what people are doing w/ travis is testing of arbritary pull requests, not of commits.. which means that random malicious people can upload code for you to run, which is kind of insane if you think about it. :)  so obviously no one wants that running on their own
01:45 < gmaxwell> infrastructure.
01:46 < gmaxwell> I think bitcoin and libsecp256k1 and stuff should have a second set of automated tests that run only on commits and can just run on other random hardware, e.g. BE PPC.
01:47 < gmaxwell> and such an enviroment can also do stuff like collect performance over time-- something you can't really do in a multiuser virtualized enviroment because the performance is too random.
01:49 < elichai2> well we can have some bot that reads github comments and if a maintainer right `JENK TEST` it will run the test on that PR
01:50 < gmaxwell> Thats true too, I've never used the jenkins github integration but its likely that it can do that.  It's not too hard to automate triggering tests in any case-- like you can just go to the jenkins webui and press a button.
01:55 < gmaxwell> the other nice thing about jenkins is that no one is trying to avoid it being used as a file host,  so there is no problem getting access to the build products.
01:56 < gmaxwell> So you can easily get the output of analysis builds that generate reports, e.g. https://mf4.xiph.org/jenkins/job/opus-scan-build/ws/scan-build/2019-09-04-161159-27770-1/index.html
01:57 < gmaxwell> Or render documentation: https://mf4.xiph.org/jenkins/view/opus/job/opus/ws/doc/html/index.html
01:59 < gmaxwell> meanwhile, in travis we struggle to get out a 256 bit random seed value. :P
02:01 < elichai2> The problem with jenkins is that we have no infra guy to manage AWS spots etc.
02:02 < elichai2> I want to give azure pipelines a try because at start it's free, but you can scale it however you want
02:02 < gmaxwell> bitcoin core project actually has hardware, hosted by chaincode... (also, aside, AWS is really cost ineffective for non-neglgible amounts of computing power running all the time)
02:03 < gmaxwell> like 3-9 months of AWS cost pays for the hardware outright, depending on which configuration you're talking about.
02:07 < gmaxwell> In any case, you're right that a missing part seems to be someone to manage it.
02:07 < gmaxwell> In any case, the end result in that is that the software does not end up tested to high level of assurance.
02:18 < gmaxwell> FWIW, running on a 3.4GHz zen2 core, -DVALGRIND --enable-openssl-tests=no  takes 3m34s to run ./tests 1   thats not exceptionally long but it used to be quite a bit faster, I suspect that some of the newer tests aren't as well calibrated for tests 1.
02:19 < gmaxwell> It would probably make sense to do some test rebalancing so that tests 1 remains comfortably fast even on really slow hardware.
02:19 < gmaxwell> I think I noticed the same thing when testing the different window sizes on arm...
02:25 < elichai2> what's `test 1`?
02:26 < elichai2> gmaxwell: btw about arm, have you tested the asm impl? I get weird problems trying to emulate arm to test it
02:27 < gmaxwell> elichai2: of course I have.
02:27 < elichai2> the CI currently doesn't test it at all
02:28 < gmaxwell> Not sure if you've picked up on it, but I don't think very highly of travis.  I've tested every commit I've merged on arm (well probably skipped some of the doc only-ish ones and such).
02:29 < gmaxwell> Also, I noticed that travis wasn't testing the arm asm previously: https://github.com/bitcoin-core/secp256k1/issues/598
02:30 < gmaxwell> The problem I see with the CI stuff is that people have a tendency to only set it up half assed and then somehow it ends up replacing actually good testing.  Obviously automating testing is really good, but automating a subset then forgetting to do any other is pretty bad.
02:33 < elichai2> I feel in big projects the oposite. there's feature explosions both in secp and in core, and I almost always forget to test some feature just to see the CI is failing when SCALAR=32bit
02:33 < gmaxwell> As far as testing in an emulator goes-- it's absolutely better than not testing at all, but often the emulator is so slow that it really gets in the way of doing a sufficent amount of testing.  So you end up with things like every or almost every javascript secp256k1 implementaion has had horrible bugs that could make it compute incorrect pubkeys with non-neglgible probablity because it runs so slow
02:33 < gmaxwell> that even if you run the tests on fast hardware you run out of patience before you find the bugs, and as a result the developers do little to no randomized testing.
02:35 < elichai2> as for emulating arm, too bad there's no project like this for C https://github.com/rust-embedded/cross
02:35 < gmaxwell> elichai2: you wouldn't have that problem if you just remembered to test on each 'obvious' supported platform :). Compile time options are evil and should be minimized for a bunch of reasons, including testing impact..  Stuff like the window sizes are indeed annoying and better tested by ci.
02:35 < gmaxwell> elichai2: standard gcc install on fedora is pretty much that, assuming you've installed the additional packages.
02:36 < gmaxwell> Though I don't particularly like to use cross compilation for testing hosts that are otherwise self-hosting because you miss the oppturnity to test the build process with a different compiler and toolchain.
02:37 < elichai2> yeah, but then you need to have access to 5 different arch and that's not easy
02:39 < gmaxwell> ::shrugs:: the tests take a little bit to run, so I just ssh into a couple hosts.  I test windows with wine and mingw builds though.
02:40 < gmaxwell> In any case, it's not that I think that automating isn't valuable, it's very valuable. But if it causes you to go broad not deep because its done on a shitty platform which is slow and where the tests taking an hour would be a problem .... or where you just don't go broad or deep, than thats not great.
02:41 < elichai2> yep :)
02:42 < gmaxwell> like libsecp256k1 should have some test sequence that takes a whole day to run, because why not?  the project often goes weeks without a commit. plenty of oppturnities to run an extensive test.  But thats just unthinkable when /the/ CI platform has tight time limits.
02:45 < gmaxwell> aside with all the options turned up, modules on, etc. ./tests (default, 64) takes 12 minutes in valgrind on the 3.4GHz zen2.
02:49 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
02:49 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1
02:51 < elichai2> arm-linux-gnueabihf vs arm-linux-gnueabi ?
02:54 < gmaxwell> the difference between the two is hardware floating point vs software floating point.  (A lot of embedded arm exists without a fpu, though the rise of android smartphones seems to have resulted in all higher end arm having a FPU)
02:55 < gmaxwell> Hm HP9000 stuff is surprisingly expensive on ebay for being old junk.
03:31 < elichai2> gmaxwell: that's similiar to what i've been seeing locally https://travis-ci.org/elichai/secp256k1/jobs/609184343
03:34 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer]
03:34 < gmaxwell> The screensays Arm64 ... the arm assembly is 32-bit.  Those error messages are extremely unhelpful, but could be the result of it using the wrong assembler.
03:51 < elichai2> yeah, but I tried setting everything, `--host`, `--build`, `--target` but it always seem to choose the wrong assembler :/ i'll try also installing `gcc-arm-linux-gnueabi`
03:53 < gmaxwell> unfortunately, on like... standard arm hosts running debian or ubuntu it JustWorks(tm)-- like rpi, novena, or odroid, so I don't have a lot of advice to give.
03:54 < elichai2> back to valgrind, not sure what's that line https://travis-ci.org/elichai/secp256k1/jobs/609182368#L452 but it seems to finish without errors in 22 minutes
04:10 < gmaxwell> elichai2: thats just a standard line, as it says on the line below there are no errors.
04:11 < elichai2> I think I might PR this with allow failure true, such that the long time wont stop from merging but will still always run (Altough there are so little PRs and they're usually open for weeks so maybe another 20 minutes isn't bad)
04:12 < gmaxwell> make it run with tests 1
04:13 < gmaxwell> It should be 4x faster or so. And since it'll get run over and over again, there isn't a particular need to run it with a high tests count.
04:32 < elichai2> What does `test 1` does?
04:32 < elichai2> Didn't even know you can pass args to the tests binary lol
05:14 < nickler> elichai2: not sure if you've seen this but I posted a link to a valgrind-updated travis config yesterday: https://github.com/bitcoin-core/secp256k1/pull/687#issuecomment-551223533
05:14 < nickler> for example `./tests 8` works without endo and with schnorrsigs
05:17 < nickler> gmaxwell: "andytoshi: good point that simple KOSK actually lets someone slip in a taproot script." not if you're following the BIP.
05:17 < nickler> "If the spending conditions do not require a script path, the output key should commit to an unspendable script path [...]" also reflected in the python code.
05:17 < elichai2> nickler: nope hehe, Altough I did most of the work before you commented so that wouldn't have helped ???
05:21 < nickler> elichai2: I said "I'll open an alternative PR with a more cleaned up version [...]", but I haven't done so yet and don't plan to do it today. So if you have a nice version feel free to PR it.
05:22 < elichai2> OK heh, I have a tendency lately to do duplicate work others are already doing/done :)
05:24 < gmaxwell> elichai2: it's good practice in any case.
05:38 < gmaxwell> nickler: re KOSK, absolutely. The context here is that this person saw the original bip-schnorr when it was first posted. Saw the mention of musig and has eversince been spamming any discussion of bip-schnorr  with cranky claims that shamir secret sharing solves all problems and that there is no need for any of this stuff.  His claims have included things like saying that he can do totally
05:38 < gmaxwell> non-interactive multisigs... and suggesting totally nonsense alterntives.
05:44 < nickler> Yeah, I remember earonesty's foolish mailing list posts. I just wanted to point out that the bip is compatible with KOSK (if it is actually implemented that way, which is obviously more demanding than just using MuSig)
05:51 < gmaxwell> now he keeps saying "signing a public key" and I can't tell if he has started thinking rogue-key means something like a MITM has replaced your key.
07:30 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
07:31 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: No route to host]
08:51 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 276 seconds]
08:53 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
09:08 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #secp256k1
09:08 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
09:08 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1
10:55 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #secp256k1
10:58 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
10:59 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
11:01 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has joined #secp256k1
11:03 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 250 seconds]
11:05 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 245 seconds]
11:32 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
11:58 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 276 seconds]
12:34 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer]
12:40 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1
12:44 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
12:53 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1
12:59 -!- reallll is now known as belcher
14:16 -!- jtimon [~quassel@22.133.134.37.dynamic.jazztel.es] has joined #secp256k1
17:29 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
17:33 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 245 seconds]
18:02 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
18:06 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 276 seconds]
18:48 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
18:52 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 252 seconds]
19:27 -!- echonaut2 [~echonaut@46.101.192.134] has quit [Remote host closed the connection]
19:27 -!- echonaut [~echonaut@46.101.192.134] has joined #secp256k1
20:17 -!- jtimon [~quassel@22.133.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
21:16 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 276 seconds]
21:45 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
21:45 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
--- Log closed Sat Nov 09 00:00:03 2019