--- Log opened Thu May 07 00:00:14 2020
00:26 -!- x1ddos [~alex@213.144.147.16] has joined #secp256k1
01:23 -!- roconnor [~roconnor@host-45-58-197-21.dyn.295.ca] has quit [Ping timeout: 264 seconds]
01:48 < waxwing> sipa, i saw you posted this: https://bitcoin.stackexchange.com/questions/95762/k-selection-for-schnorr-signatures/95763#95763, i'm curious about "secp256k1 has the interesting property that its group order is negligibly close to 2^256" - given the hasse bound isn't that basically always true for a curve of that size?
01:48 < waxwing> like it'd be within 2^128 crudely
02:01 < sipa> waxwing: oh no
02:01 < sipa> waxwing: the hasse bound is a relation between group order and field size
02:01 < sipa> but secp256k1's field size is unusually close to a power of two
02:02 < sipa> plus it has no cofactor
02:02 < sipa> (cofactor is usually a power of two, so that would 't actually pose any problems)
02:57 < elichai2> waxwing: you can see that secp256k1 order is: n=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 so `1/(2^256-n)` is 1/2**129 (the chances of finding anything between the order and 2^256)
03:01 < elichai2> hmm I think I got it wrong. ok. so `2^256-n` is the amount of numbers between the order and 2^256, and in secp256k1 that's 2^129 numbers, so (2^129)/(2^256) is the probability of finding one, which is `1/(2^127)`
03:02 < elichai2> but in secp256r1 `n = 0xFFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551` so `(2^256)-n` is 2^224. and then `(2^224)/(2^256)` it's `1/(2^32)` which is quite probable
03:25 < waxwing> oh just close to a power of 2, of course. not sure why i confused that.
04:22 < real_or_random> elichai2: how did you manage to get that speed up on mac os?
04:22 < real_or_random> (in the travis PR)
04:22 < elichai2> the travis homebrew plugin is buggy and took wayyy too much time
04:23 < elichai2> instead I'm using homebrew itself, and it's fast so I also don't need caching anymore which also shaves a few minutest
04:24 < real_or_random> oof
04:24 < elichai2> real_or_random: you can see here the conversation: https://travis-ci.community/t/macos-build-fails-because-of-homebrew-bundle-unknown-command/7296/31?u=elichai2 (linked to my comment but you can read above it)
04:24 < real_or_random> just saw the comment... hm the tooling around travis is really not great
04:25 < elichai2> Yeah... I feel that a docker based CI where we can deploy our own prebuilt images will work really better
04:25 < elichai2> that way we can update / install packages  once for the docker image and that's it
04:25 < real_or_random> "and there’s no need for caching" yeah it was actually timing out during packing the cache
04:25 < real_or_random> kind of sad
04:25 < elichai2> yeah, the caching there is seriously bad
04:26 < elichai2> I've seen people do `after_script` and in there they tar gz everything themselves and push to an aws bucket
04:26 < real_or_random> lol
04:26 < real_or_random> your travis_wait workaround is also nice
04:26 < real_or_random> I mean it's hack but it's the cleanest hack I can think of
04:27 < elichai2> nvm docker, you can't do osx inside docker
04:27 < elichai2> yep it's pretty nice and clean :) I'm conflicted about the fact that it doesn't have an upper bound, but travis will terminate after 60 minutes anyway so....
04:28 < elichai2> thanks
04:30 < real_or_random> I think I've seen a version of this that kills the printing loop after the other thing exited
04:31 < real_or_random> this nit is still open https://github.com/bitcoin-core/secp256k1/pull/750#discussion_r419442096
04:39 < real_or_random> maybe try "kill %keep_alive" as a last command in the travis script?
04:40 < elichai2> real_or_random: oh yeah hmm should I replace these with something like this? `SECP256K1_BENCH_ITERS=$ITERS $EXEC ./bench_verify >> bench.log 2>&1`
04:41 < elichai2> real_or_random: well it auto terminates it if everything else finish
04:42 < real_or_random> ah you mean by having ITERS in travis and SECP256K1_BENCH_ITERS inside? that would work, this self-contained code has the same effect as a comment ^^
04:42 < real_or_random> auto terminates?
04:50 -!- jonatack_ [~jon@37.164.233.66] has joined #secp256k1
04:51 < real_or_random> ah yes, I see... nevermind
04:53 < real_or_random> I may be still better to run the kill.. otherwise you may get orphaned processes etc.. probably not relevant on travis but seems to right thing to do in general
04:54 -!- jonatack [~jon@37.173.38.62] has quit [Ping timeout: 264 seconds]
04:57 < elichai2> real_or_random: hmm I think for that I need to keep the PID in a variable, and kill it at the end
04:57 < real_or_random> there is no pid
04:58 < real_or_random> I mean.. there may be a PID, but you can use the bash jobspec
04:58 < real_or_random> just "kill %keep_alive"
04:58 < elichai2> ha
04:58 < real_or_random> kill is a bash built-in
05:02 < elichai2> real_or_random: it seems to work, which is pretty cool I just can't find it in any docs
05:03 < elichai2> found it " are a number of ways to refer to a job in the shell. The character % introduces a job specification (jobspec)."
06:27 -!- roconnor [~roconnor@host-45-58-197-21.dyn.295.ca] has joined #secp256k1
08:08 -!- SofiFlor [54e8e4e8@gateway/web/cgi-irc/kiwiirc.com/ip.84.232.228.232] has joined #secp256k1
08:11 -!- SofiFlor [54e8e4e8@gateway/web/cgi-irc/kiwiirc.com/ip.84.232.228.232] has quit [Client Quit]
08:18 < elichai2> it seems like most of the time with macOS is waiting for machines to be freed, so a lot of time is spent not runing any job. but I do not believe it's a problem since it's not like the repo is super active
08:24 < real_or_random> hm yeah we could remove a few entries from the matrix but that's arbitrary too
08:25 < real_or_random> it's certainly better to test on MacOS and buy some waiting time instead of not testing ^^
08:38 < real_or_random> another thing we could do is to run more configs in the same job
08:39 < real_or_random> unfortunately that conflicts with the build matrix design
08:44 < real_or_random> do you know if people looked into ms azure for CI?
08:52 < elichai2> I don't know. I know for a while a lot of rust projects(and rustc itself) used azure, until github actions became a thing
08:52 < elichai2> That's the only comment I could find on the topic: https://github.com/bitcoin/bitcoin/issues/16148#issuecomment-504084172
08:53 < sipa> we looked into using github actions for bitcoin core too; i don't remember why it was abandoned
09:13 < real_or_random> sipa: github actions was abandoned due to security concerns, I think the issue was that the CI has commit access
09:14 < real_or_random> elichai2: yep I found that one too. "but they seem to require a microsoft account" is not really a strong argument, so I guess we should have a look
10:01 -!- jonatack_ [~jon@37.164.233.66] has quit [Quit: jonatack_]
10:01 -!- jonatack [~jon@37.164.233.66] has joined #secp256k1
11:25 < elichai2> real_or_random: good idea! suggestion of a subtle way to make it non ct? (I could replace `secp256k1_ecmult_const` with `secp256k1_ecmult` in ecdh or replace some the ecdsa inverse with inverse_var or just add a simple if on the seckey)
11:32 < elichai2> I changed a cmov into an if, it catches it locally, let's see now that travis fails
11:36 < elichai2> just thought of something, after you integrate the ctime test into make check I think we should enable in Bitcoin core a way to run secp's `make check` so that users can make sure everything is fine before installing it on their machines (ie if they have a weird processor or if some future processors/compiler/OS break things)
11:38 < elichai2> that's fun to see hehe, I only broke the 5x52 field impl so you can see in travis that FIELD=32bit is passing while the rest are failing hehe https://travis-ci.org/github/elichai/secp256k1/builds/684392980
11:39 < sipa> elichai2: Bitcoin Core's make check already runs make check of the secp256k1 subtree
11:40 < elichai2> sipa: really? never not noticed that somehow
11:41 < sipa> if you're running with high enough parallellism, it's s the slowest part even
11:48 < elichai2> trying now
11:50 < elichai2> ok, I realized why I never noticed, I always run `./src/test/test_bitcoin` + `./test/functional/test_runner.py`  and not `make check`
11:50 < elichai2> I should use `make check` more often
11:50 < sipa> make check is a lot faster
11:50 < sipa> as it runs the unit tests in parallel
11:52 < elichai2> ha, good to know it does feel faster ( and I definitely feel it slower on `make check -j16`  )
11:52 < elichai2> *slower on libsecp
12:26 -!- AlinaBaikof [54e8e4e8@gateway/web/cgi-irc/kiwiirc.com/ip.84.232.228.232] has joined #secp256k1
12:29 -!- AlinaBaikof [54e8e4e8@gateway/web/cgi-irc/kiwiirc.com/ip.84.232.228.232] has quit [Client Quit]
13:22 < real_or_random> oh one more reason to improve our `make check`
13:32 < real_or_random> we could actually add a ct test with an inverted result that just has a branch on purpose, to make sure valgrind does its job
13:33 < real_or_random> may be overkill, idk
16:46 -!- x1ddos [~alex@213.144.147.16] has quit [Ping timeout: 258 seconds]
16:51 -!- jonatack_ [~jon@37.165.219.151] has joined #secp256k1
16:54 -!- jonatack [~jon@37.164.233.66] has quit [Ping timeout: 260 seconds]
17:11 -!- jonatack_ [~jon@37.165.219.151] has quit [Quit: jonatack_]
17:11 -!- jonatack [~jon@213.152.180.5] has joined #secp256k1
17:58 -!- jonatack [~jon@213.152.180.5] has quit [Ping timeout: 246 seconds]
--- Log closed Fri May 08 00:00:19 2020