--- Log opened Mon Apr 10 00:00:28 2023
04:58 -!- jonatack1 [~jonatack@user/jonatack] has joined #secp256k1
04:59 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
06:13 -!- jonatack2 [~jonatack@user/jonatack] has joined #secp256k1
06:13 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
07:04 -!- jonatack2 [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
07:05 -!- jonatack2 [~jonatack@user/jonatack] has joined #secp256k1
07:38 -!- preimage [~halosghos@user/halosghost] has joined #secp256k1
08:01 < nickler> hi
08:01 < hebasto> hi
08:02 < sipa> hi
08:03 < nickler> topic suggestion: high priority for review
08:04 < sipa> I guess I'd like to prioritize 1129.
08:04 < nickler> good, that's what I thought :)
08:06 < sipa> Great.
08:07 < real_or_random> hi
08:08 < real_or_random> or should we deal with 1129 when we're on the same continent?
08:09 < sipa> Yeah, perhaps. Though that probably applies to any PR...
08:09 -!- jonatack3 [~jonatack@user/jonatack] has joined #secp256k1
08:10 < nickler> that's still a long time away, I think
08:10 < real_or_random> true
08:12 -!- jonatack2 [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
08:15 < real_or_random> any other high prio things?
08:16 < real_or_random> or another, a bit more general way to ask this: what do we want in the next regular release?
08:18 < real_or_random> we could add stuff to the milestone. I'd like to work on https://github.com/bitcoin-core/secp256k1/issues/1095 
08:19 < sipa> we do have a few "new protocol/API" things: batch schnorr, anti-exfil, ellswitt
08:20 < real_or_random> yep, I think it would be good to talk about something like a roadmap here... like what "big changes" would we want to have included, in what order
08:21 < sipa> and a few performance improvements: sdmc, sd ecmult const, faster divsteps, ...
08:22 < real_or_random> I suggest ellswift goes first for new protocols as we're already working on it and BIP324 needs it. I don't think that's controversial... but for the others, idk
08:22 < real_or_random> nickler: does anti-exfil touch the SoB project in any way?
08:23 < sipa> Batch schnorr isn't actually useful without accompagnying code in Bitcoin Core to make use of it, and it's a rather invasive change that probably doesn't make sense to prioritize until there are lots of BIP340 sigs on chain.
08:23 < sipa> The anti-exfil stuff is probably actually useful to its author, so I'd schedule that after ellswift.
08:24 < real_or_random> on the performance track, I feel SDMC should be the next big thing. It's a bit overdue. Not in the sense that we need it but it has been around for so long, we should get it off the table
08:25 < sipa> It's only the 3rd PR in 4.5 years.
08:25 < sipa> ;)
08:25 < real_or_random> maybe move it to the 2.0 milestone :P
08:26 < sipa> heh
08:26 < real_or_random> and yes, anti-exfil would be nice as a next thing to look at. I think we should also PR musig2 then.
08:26 < sipa> agree
08:27 < real_or_random> but I'd still like to know if it's related to the SoB project.
08:27 < real_or_random> (do you mind me adding 1095 to the 0.4 milestone?)
08:28 < nickler> real_or_random: not sure why it would be
08:28 < sipa> sure, go ahead
08:29 < nickler> 1095 is pretty useful I agree
08:31 < sipa> do we want to be more proactive and pick a few more things for 0.4 already?
08:31 < sipa> like SDMC or so
08:31 < nickler> Who are the biggest beneficiaries from faster signing?
08:31 < sipa> probably lightweight devices
08:31 < sipa> but SDMC also decreases the binary size
08:32 < sipa> which may be useful even to users that don't actually sign often, or care much about its speed
08:32 < nickler> do we have numbers on how long signing typically takes on lightweight devices?
08:32 < real_or_random> nickler: my thinking was that both use s2c, no?
08:33 < nickler> sipa: do you have an idea how much smaller the binary would be?
08:34 < nickler> real_or_random: yes maybe they can share a little bit of code for some reason but they are not interfering
08:35 < sipa> The new default table size after #1058 (SDMC) is 22 KiB. The current table is 64 KiB by default.
08:35 < sipa> Not all that much of a relative change when default ecmult tables (~1 MiB?) are used.
08:37 < nickler> ok, interesting
08:38 < real_or_random> if you ask me for the number 1 prio then I'd say external SHA256 
08:38 < real_or_random> but noone is working on it right now, it's too boring :P 
08:38 < real_or_random> *number 1 prio for performance
08:38 < sipa> Or more generally, the currently supported ecmult_gen table sizes are 32 KiB, 64 KiB, 128 KiB. After #1058 the options are 2 KiB, 22 KiB, 86 KiB.
08:39 < real_or_random> this reminds of the possibility to compile without one of the tables  (e.g., if your app uses only signing or only verification)...
08:39 < sipa> real_or_random: Yeah, I think that's a different question. (a) What should we as contributors prioritize to implement and (b) What should we as reviewers prioritize among things that are already implemented.
08:40 < nickler> I think we also agreed (at some point) that we somehow would like to make group and scalar operations available to users. This would be a larger project as well.
08:41 < real_or_random> sipa: right. both sides make sense. given the large amount of things in the pipeline, my feeling is that we should try to put a bit more emphasis on review
08:41 < nickler> At least this seems to be one of the most highly requested features of the library.
08:41 < real_or_random> right now
08:41 < real_or_random> nickler: good point
08:41 < real_or_random> I think we should take a step back and make this a separate meeting / call 
08:42 < sipa> Yeah.
08:42 < real_or_random> our daily work is driven by the PRs around but it makes sense to think about what we want (a), not only what's in the queue (b)... and then try to find a balance here. 
08:43 < real_or_random> and maybe make an ordered list of things (which won't be written in stone). the project is small enough that we can still do this. 
08:44 < real_or_random> (I assume it's very hard in core for example, with so many different people and interests etc)
08:44 < sipa> Right. Priorities ultimately apply to people, not to the project, except to the extent that people working on the project are aligned.
08:44 < real_or_random> (I'll also add  https://github.com/bitcoin-core/secp256k1/pull/1129 / ellswift to the milestone?) 
08:45 < nickler> sgtm
08:45 < sipa> It seems we have agreement on that.
08:53 < real_or_random> end of meeting?
08:54 < nickler> milestone looks good to me so far! productive meeting :)
08:59 < real_or_random> fyi, I canceled CI on https://cirrus-ci.com/build/6414465390870528 to have more resources for the release PR
09:20 -!- pakaro [~quassel@cst2-172-111.cust.vodafone.cz] has joined #secp256k1
09:25 -!- pakaro [~quassel@cst2-172-111.cust.vodafone.cz] has quit [Client Quit]
09:50 < sipa> What's the status now on 0.3.1?
10:24 < real_or_random> merge merge?
10:24 < nickler> let me add the [unreleased] line to the follow-up PR
10:25 < nickler> but yeah let's merge 1266
10:26 < real_or_random> ok
10:26 < sipa> sgtm
10:27 < real_or_random> can you merge? I need to leave for dinner now...
10:27 < sipa> I'm extremely tired and kind of concerned I may make a stupid mistake.
10:27 < nickler> I can
10:28 < real_or_random> ok, sgtm
10:28 < sipa> go for it
10:28 < fanquake> 👀 💤
10:28 < nickler> But I also have a dinner appointment in 2 minutes :) Someone still needs to tag and make the GH release
10:28 < real_or_random> nickler: can you also do the tagging then?
10:28 < real_or_random> ah okay, I can try to do it when I'm back
10:29 < sipa> A few hours won't hurt.
10:29 < nickler> I should be back soon as well.
10:29 < nickler> should we merge 1268 now?
10:29 < real_or_random> sipa: could you try to prepare a few sentences for an announcement? 
10:30 < sipa> Yeah, will do.
10:30 < real_or_random> nickler: let's first do the tagging, then merge 1268 
10:30 < nickler> hm ok, just need to remember that we don't want to merge anything until 1268 is merged
10:35 < sipa> Do we know if the clang 14 issue only affects x86_64, or also other platforms?
10:37 < sipa> https://gist.github.com/sipa/d3486284e34728ca3677a003844f117a
10:38 < real_or_random> oh good point. we don't know... and I know clang does cmov to branch conversions in early and in very late stages, so this could totally be x86-only
10:39 < real_or_random> ah I screwed up the "0.3.1" link in https://github.com/bitcoin-core/secp256k1/blob/master/CHANGELOG.md ... -.-
10:40 < real_or_random> forgot to update the footnotes
10:42 < real_or_random> a) I can add a PR on top but then we have two commits with IS_RELEASE=true (who cares, source code hasn't changed), b) re-do the PR and force push to master (ugh), c) ignore it for now and fix it after the release
10:42 < real_or_random> I tend to do a) ...
10:42 < sipa> @real_or_random Oh I noticed that but assumed it was due to 0.3.1 not being tagged yet. I should have said something.
10:42 < sipa> I vote (a).
10:43 < real_or_random> I just had the same thought ... "wait is that an automatic github thing?! ah no, footnotes -.-"
10:44 < real_or_random> announcement looks good. maybe s/encourage/highly recommend/ ^^
10:45 < sipa> Changed to "strongly recommend"; sounds better than highly IMO.
10:45 < real_or_random> makes sense
10:46 < real_or_random> sipa: do we have any quick way to test this on different platforms? I don't have an ARM machine here... I guess we should just assume that it's on multiple platforms unless we know better, and don't say anything
10:46 < sipa> Valgrind supports arm64 no?
10:46 < sipa> And it's a CPU emulator already.
10:47 < real_or_random> also, now that I think about it, the fact that volatile helps hints at earlier optimization stages here. this is not simple CMOV rewriting in the assembly output
10:48 < real_or_random> yeah but you can't "cross-run" with valgrind
10:48 < real_or_random> there's a reason why we have disabled cttimetests for arm64 in CI on qemu
10:49 < real_or_random> if you have an ARM64 machine here, then you could run valgrind
10:49 < sipa> Not right now.
10:49 < real_or_random> (really need to leave now for dinner, sorry...)
10:50 < fanquake> i can run something on arm if need be
10:50 < fanquake> actually working on moving our (Core) CI to using a valgrind built from source, to solve a number of issues I've seen on aarch64
10:52 < sipa> fanquake: Checkout 0.3.0, configure with ctime tests enabled, and then run "libtool --mode=execute valgrind ./ctime_tests". See if it fails.
10:52 < sipa> Then do the same with master.
10:52 < sipa> Oh, using >= clang14
10:57 < fanquake> yea it fails with 0.3.0
10:57 < fanquake> does not with master
10:57 < fanquake> tried with clang 15.0.7 and valgrind 3.20 on a aarch64 box
10:57 < sipa> Cool, thanks!
10:58 < fanquake> https://gist.github.com/fanquake/5e8bd3fb9cf7ab6870532cf8a519300f
10:58 < sipa> Exactly the same as on x86_64.
10:59 < sipa> I'm going to assume all platforms are affected then, and not mention anything in the announcement.
11:56 < real_or_random> https://github.com/bitcoin-core/secp256k1/pull/1269
12:04 -!- roconnor [~quassel@coq/roconnor] has quit [Ping timeout: 250 seconds]
12:05 -!- roconnor [~quassel@coq/roconnor] has joined #secp256k1
12:13 < real_or_random> sipa: should we wait for nickler? or just merge and tag?
12:14 < sipa> I think we can merge and tag.
12:14 < sipa> He reviewed the preparation PR.
12:24 < real_or_random> ok
12:24 < real_or_random> let me merge 1269
12:27 < nickler> hi
12:32 < nickler> ok merged
12:34 < nickler> should I tag the release?
12:34 < real_or_random> oh :D 
12:35 < real_or_random> nickler: yes, can you tag it?
12:38 < sipa> ACK
12:39 < nickler> done
12:40 < real_or_random> does https://github.com/bitcoin-core/secp256k1/pull/1268 need to be rebased now?
12:41 < nickler> should I do the github release as well?
12:41 < sipa> I think it's best if 1268 is merged cleanly.
12:41 < nickler> rebased it
12:45 < sipa> At which point in the process is a PGP signature involved again?
12:46 < nickler> only when tagging the commit
12:47 < sipa> Right.
12:47 < sipa> Yeah, you can do the github release.
12:47 < real_or_random> grrr
12:47 < real_or_random> [unreleased]: https://github.com/bitcoin-core/secp256k1/compare/v0.3.0...HEAD
12:47 < sipa> ?
12:48 < real_or_random> should be v.0.3.1 ... can you fix that in your PR?
12:48 < nickler> "Clang 14 and later became smart enough to optimize out a specific timing sidechannel protection mechanism in the code"
12:48 < nickler> sipa: This may not necessarily imply to reader that there are in fact timing sidechannels (i.e., the reader could believe that there are other protections).
12:49 < sipa> nickler: Not sure what you mean.
12:49 < sipa> Can you suggest other language?
12:50 < nickler> real_or_random: done
12:51 < nickler> should mention this in the release process as well
12:51 < real_or_random> yep
12:53 < nickler> Maybe "Clang 14 and later became smart enough to optimize out a specific timing sidechannel protection mechanism in the code that could leave applications vulnerable to a sidechannel attack"
12:54 < sipa> updated in gist
12:54 < nickler> gist ACK
12:55 < nickler> published the github release https://github.com/bitcoin-core/secp256k1/releases
12:55 < sipa> Ok, I'll mail the list?
12:56 < nickler> thanks fanquake btw!
12:56 < fanquake> no worries
12:56 < nickler> sipa: sgtm
12:58 < real_or_random> ACK
13:00 < sipa> sent
13:01 < nickler> real_or_random: you ack'd the wrong commit in 1268
13:03 < real_or_random> ...
13:03 < sipa> I'm sure it was a test.
13:03 < nickler> haha that's why I didn't ignore it for this trivial PR :)
13:03 < real_or_random> ok fixed
13:04 < real_or_random> a lot of mistakes for a single release / evening ^^
13:05 < nickler> I definitely underestimated how foolproof the release process doc has to be
13:05 < real_or_random> by the way, I also had the idea of enabling the ctimetests in dev mode
13:05 < real_or_random> make it idiot proof and someone will build a better idiot
13:05 < real_or_random> happy to help
13:08 < sipa> :D
13:13 < real_or_random> nickler: should we include one or two sentences in the GH release description this time?
13:29 < sipa> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021553.html
13:36 < roconnor> https://github.com/bitcoin-core/secp256k1/blob/master/src/modinv64_impl.h#L771
13:37 < roconnor> At this line we reduce the size of the vectors of f and g if their top bits are zero.
13:38 < roconnor> however, there is effectively an invarient that all the coefficents other than the last one are always in the range [0..2^62).
13:38 < roconnor> Therefore the vectors can only ever reduce in size when f and g are postive (and small enough).
13:39 < roconnor> which seems like an unfortunate and possibly unintended requirement.
13:40 < roconnor> I don't know how much of a speed boost we would get if we were to also reduce when the top coefficent is -1.
13:42 < sipa> I don't think it can go negative, as only positive coefficients are involved.
13:42 < roconnor> sorry by coefficents I mean values of the f.v and g.v array.
13:43 < sipa> I understand.
13:43 < sipa> But f and g cannot become negative in this jacobi-oriented function.
13:43 < real_or_random> sipa: do you want to tweet about the release?
13:43 < roconnor> oh my link is wrong.
13:44 < roconnor> I meant https://github.com/bitcoin-core/secp256k1/blob/master/src/modinv64_impl.h#L681 and it works fine.
13:44 < roconnor> I was so confused, because I could have sworn it worked with -1.
13:45 < roconnor> and indeed it does.
13:45 < roconnor> I just looked at the wrong function when I went to look because I'm not used to the jacobi source code being there.
13:46 < sipa> real_or_random: Oh sure.
13:47 < sipa> Hmm, website doesn't load for me.
13:47 < sipa> I haven't logged into twitter in weeks...
13:50 < hebasto> sipa: want to update the subtree in Bitcoin Core repo (before branch v25.0 off)? If not, I can do it
13:50 < sipa> There it is.
13:52 < sipa> real_or_random: https://twitter.com/pwuille/status/1645529919609352192
14:10 < sipa> @hebasto I'd say there is no urgent need (it's already at 0.3.0, right?), but at some point it's good to get it in (self-compiled binaries with clang 14+ will happen somewhere sometime...).
14:11 < hebasto> sipa: ok
14:13 < hebasto> fwiw, the recent ubuntu kinetic and upcoming ubuntu lunar has default clang-15
14:13 < hebasto> * have
14:14 < sipa> Yeah, but Bitcoin Core's guix env has clang hardcoded to an earlier version for now IIRC (and I assume it'll update libsecp256k1 to 0.3.1 before upgrading clang that much).
14:15 < hebasto> I mean, self-compiling
14:16 < hebasto> you are right, no hurry at all
14:27 < real_or_random> well if we can  get it, then why not
14:27 < real_or_random> *then why not early
14:28 < real_or_random> some people will self-compile
14:28 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.8]
17:45 < sipa> https://github.com/bitcoin/bitcoin/pull/27445
17:58 < sipa> uh, bitcoin core CI fails to (re)create the wycheproof .h file: https://github.com/bitcoin/bitcoin/pull/27445/checks?check_run_id=12646977847
20:19 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
20:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
20:28 -!- BlueMatt_ [~BlueMatt@ircb.bluematt.me] has quit [Quit: Quit]
20:28 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has joined #secp256k1
20:39 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has quit [Quit: Quit]
20:40 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has joined #secp256k1
21:22 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
21:22 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
--- Log closed Tue Apr 11 00:00:29 2023