--- Log opened Mon Nov 21 00:00:23 2022
00:09 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
01:02 -!- hebasto [sid449604@2a03:5180:f:5::6:dc44] has quit [Read error: Software caused connection abort]
01:02 -!- hebasto [sid449604@id-449604.uxbridge.irccloud.com] has joined #secp256k1
01:53 -!- sipa [~sipa@user/sipa] has quit [Read error: Software caused connection abort]
01:53 -!- sipa [~sipa@user/sipa] has joined #secp256k1
02:27 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
02:43 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
03:39 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
03:41 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
04:13 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
05:35 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
07:00 < real_or_random> meeting sipa nickler 
07:00 < sipa> Hi.
07:01 < nickler> hi!
07:01 < nickler> topics?
07:02 < real_or_random> now that int128 is merged, we should discuss which "big" PR should we focus on next
07:02 < sipa> Maybe real_or_random and I can give a summary of the stuff we talked about/worked on last week.
07:03 < real_or_random> sipa: do you want to give it a try?
07:03 < nickler> real_or_random: yep was about to say this
07:03 < nickler> sipa: sounds good!
07:04 < sipa> Let's see.
07:04 < sipa> We discussed the BIP340 varlength BIP and implementation; I think I left some comments there.
07:05 < nickler> oh yes, I saw that
07:05 < real_or_random> yes, I'll address these this week
07:06 < sipa> We talked about #1066 (abstracting out field interface/assumptions/constraints from implementation), and relation with #1032 (group verification).
07:07 < sipa> Lots of ideas about CI/testing (moving to ARM64 macOS, lack of valgrind but discovering ctime/memcheck testing is possible with -fsanitize=memory on clang).
07:08 < sipa> The possibility of using compute credits for macOS testing as they're pretty slow to start often (but also pretty expensive). We also figured out that Cirrus now has native Linux ARM64 infrastructure, so we can probably reduce the amount of configurations tested on macOS if they get offloaded to Linux ARM64.
07:08 < real_or_random> oh yep
07:09 < nickler> Ah yeah, I looked briefly into compute credits but never really figured out how they work. If it speeds up the macOS jobs, that would be great.
07:09 < sipa> So it's several USD per PR push right now, if we want to run all macOS jobs with credits.
07:09 < real_or_random> it seems to you can skip the queue when you pay
07:09 < nickler> that sounds pretty expensive
07:10 < sipa> Which seems kind of high to me, but also... it's not like we have hundreds of PRs.
07:10 < nickler> also seems easy to abuse
07:10 < sipa> It only runs when an org member opened the PR, I think.
07:10 < nickler> is #1152 ready for review? I saw some force pushes.
07:10 < nickler> ok, that'd make sense
07:11 < sipa> Yeah, I think 1152 is ready. It does include this use_credits.
07:11 < sipa> I want to work on adding msan testing, but after 1152 is merged, so it can be done on macOS and x86/linux.
07:12 < real_or_random> ok if we merge 1152, we'll have a good incentive to work on the ARM64 linux builds ^^
07:13 < sipa> Oh, we also briefly talked about libfuzzer based testing infrastructure (as the tests I wrote for the int128 would be far more powerful in a coverage-driven fuzzer setting than the random unit test setting we have now).
07:14 < real_or_random> would it make sense to enable credits *only* for MacOS jobs? I'm not sure... the other ones are cheaper, so maybe it's ok to have it on everywhere https://cirrus-ci.org/pricing/#compute-credits 
07:17 < sipa> That's what the PR does.
07:17 < real_or_random> the PR enables it for all platforms, right?
07:17 < sipa> No.
07:18 < sipa> I briefly had it enable it for all platforms, maybe you looked at exactly the wrong time.
07:18 < sipa> But currently the PR only enables the credits for macOS jobs.
07:19 < real_or_random> oh I see
07:19 < real_or_random> I had a look right now but I missed that the snippet is only added to the macos jobs 
07:20 < real_or_random> ok anyway, good to know that it's ready for review
07:21 < real_or_random> adding ARM64 Linux should be rather easy
07:21 < roconnor> ah DST time changes!
07:21 < real_or_random> just copy and paste the boilerplate from the other Linux builds, I can give it a try
07:21 < sipa> Indeed. We may want to bikeshed a bit on exactly how to reduce the macOS jobs.
07:21 < sipa> But adding Linux ARM64 jobs should be trivial.
07:22 < sipa> roconnor: An astute observation.
07:22 < real_or_random> roconnor: hehe :D I'd open to move the meeting to a timezone with DST
07:22 < roconnor> It's fine.
07:22 < real_or_random> sipa: you mean bikeshed now? or on the PR? 
07:22 < sipa> real_or_random: On the PR.
07:23 < sipa> roconnor: I'd be open to getting rid of DST, or making it permanent, but I believe it's out of scope of the libsecp256k1 project.
07:23 -!- jonatack1 [~jonatack@user/jonatack] has joined #secp256k1
07:25 < real_or_random> makes sense
07:26 < real_or_random> any other thoughts on things we discussed last week?
07:26 < sipa> Anyway, I think that's what I have as summary of what we did last week w.r.t. libsecp256k1.
07:26 < nickler> Alright, thanks!
07:28 < nickler> As for review focus on "big" PRs, how about ElligatorSwift. At least I read the paper last week and it was pretty understandable.
07:28 < sipa> I believe the ElligatorSwift PR is ready.
07:29 < sipa> (#1129, together with its dependencies #979 and #1118)
07:29 < real_or_random> though we would first look at the jacobi symbol PR
07:29 < sipa> Ready for review, I mean.
07:29 < nickler> you're testing against the ES authors' sage code right?
07:29 < real_or_random> I see. Do you think we should start with the dependencies or just go ahead with the complete PR?
07:30 < sipa> I think the dependencies are probably easier to review in isolation. Of course, if you review commit-by-commit it doesn't matter much.
07:31 < nickler> ok, I'll have a look at the PRs
07:32 < sipa> nickler: For BIP324 I have code (not published so far) that deterministically generates test vectors for SwiftEC/ElligatorSwift which maximize branch coverage, and those vectors are implemented in the libsecp256k1 ellswift PR, and are tested against the SwiftEC paper's authors' Sage code.
07:32 < sipa> The Sage code is only deterministic in the decode direction (uses randomness for encoding), so it's only tested in that direction.
07:33 < nickler> that's pretty neat and simplifies the review effort quite substantially
07:33 < real_or_random> ok yes, we should just decide on which of the two we want because otherwise we'll comment on different PRs. so let's start with the deps then
07:34 < sipa> The biggest conceptual question around the jacobi PR I think is the fact that a faster, probably simpler, optionally constant-time algorithm exists, but the paper warns it's potentially patented.
07:35 < sipa> But as we have no strict need for a constant-time Jacobi symbol right now, I think it's fine to just start with this approach; nothing prevents us from later implementing the better one if we deem it reasonable.
07:35 < real_or_random> agreed\
07:36 < nickler> ok
07:37 < sipa> For ellswift in general the PR implements a slight modification of the paper's scheme (it remaps the points the paper algorithm maps to infinity to finite points instead); it'd be good to have some eyes on whether that remapping makes sense.
07:38 < real_or_random> but it's clear that jacobi algorithm in the PR is correct, right?
07:38 < real_or_random> in the sense that it's a natural extension of the safegcd algorithm that we already use
07:38 < sipa> Yes, I hope the explanation will you convince you that it is.
07:38 < real_or_random> ok
07:39 < real_or_random> anything else on this topic?
07:39 < sipa> It's much simpler to be convinced, I think, as the algorithm doesn't rely on always terminating (it bails out after a threshold number of iterations, and falls back to computing an sqrt).
07:39 < real_or_random> oh yes, I remember
07:41 < real_or_random> another thing we discussed last is whether it would make to have a secp256k1 focus week in which at least the maintainers commit on making the repo their main activity   
07:42 < sipa> Ah right.
07:42 < sipa> I'm definitely open to that.
07:42 < nickler> I'd be up for that
07:42 < real_or_random> I think this would help everyone because it would minimize context switches and help get PRs actually merged (instead of having just two ACKs and then a rebase need
07:43 < real_or_random> yes me too, I think it's a good idea and we should try it
07:43 < sipa> Yeah, PRs (and reviewers/authors) losing steam is a big contributor to not making progress.
07:43 < real_or_random> we'll "just" need to agree on a week and make sure we'll really be available  
07:43 < sipa> I'm happy to pick a week early december.
07:45 < nickler> so far looks like that'd work for me
07:45 < real_or_random> hm I could do 5th to 9th (or actually 8th ... I won't be there on 9th)
07:46 < sipa> Ideally we're also active around the same hours, which is a bit challenging as we're 6 hours apart.
07:47 < real_or_random> hm I'm not sure actually
07:47 < real_or_random> in the current workflow, it makes sense to be apart a few hours
07:47 < sipa> Yeah we don't need to overlap all of it either, of course.
07:47 < real_or_random> or it's not a problem at least
07:47 < sipa> And we'll naturally have some overlap.
07:48 < nickler> 5th to 8th it is?
07:48 < real_or_random> we could also try to have a week where we meet ^^ but this is probably something for 2023 then ^^
07:48 < real_or_random> yep, let's do 5th to 8th
07:49 < real_or_random> if that's good for sipa 
07:50 < sipa> Yeah, 5-8 it is.
07:50 < sipa> I can't travel outside the US probably for another few months. I'm happy to host either of you in NY any time, but IIRC travelling to the US is annoying for nickler too.
07:52 < real_or_random> ok let's keep that in mind for the future
07:52 < nickler> I'd be comfortable doing it if I don't enter the US again in the same year & get an invitation letter from chaincode mentioning "meetings", "planning", etc.
07:52 < sipa> It'll be for 2023 in any case.
07:53 < roconnor> how about we meet at one of those cafes where the us canada border runs through the table?
07:53 < sipa> Haha.
07:53 < real_or_random> :D let's maybe discuss the details somewhere else
07:54 < nickler> other topics?
07:55 < real_or_random> yep
07:55 < real_or_random> I had this idea of organizing the repo a little bit more, e.g., by adding tags to PRs ...
07:56 < real_or_random> like "performance", "assurance", "CI".  I don't expect anyone to be against this,  I'm happy to give a try 
07:56 < real_or_random> but should we discuss the exact list of tags first? maybe in an issue? or should I just go ahead and we can adjust on the fly 
07:56 < nickler> imo you can just go ahead
07:56 < real_or_random> (these categories would help me prioritize a little, I think)
07:57 < nickler> (presumably we'd also want "enhancement/feature", "documentation", "bug")
07:57 < real_or_random> I can also try to pin the "focus" PR(s), i.e., the ellswift stuff
07:57 < real_or_random> indeed, and the same/similar for issues
07:58 < real_or_random> in the future we could do more fancy tricks, for example run a script that benchmarks all "performance" PRs to see which ones are most beneficial
07:58 < sipa> Any others?
07:58 < sipa> performance / assurance / CI / build system / documentation / new protocol / bug(fix)
07:59 < sipa> We could have separate tags for performance improvements for small/medium/large improvements (expressed in centinepers on the best affected platform) :p
08:00 < real_or_random> I think that's pretty much all of it... I guess CI should be a part of assurance, and then these will be proper categories
08:00 < sipa> Right.
08:00 < real_or_random> otherwise there will be a lot of overlap in CI/assurance. (which is not a problem with tags ^^)
08:00 < sipa> I guess CI stuff generally either overlaps with Assurance, or with Build System.
08:01 -!- jonatack2 [~jonatack@user/jonatack] has joined #secp256k1
08:01 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
08:02 < real_or_random> ok, well, now that I think about it, let's maybe just have "CI" as an additional tag... and those PRs/issues can still belong to other tags of course  
08:02 < sipa> SGTM
08:03 < real_or_random> i may also add "good first issue". we discussed this in the past. I seriously doubt it will help but I think the cost of adding this to a few issues is really negligible ^^ 
08:04 < real_or_random> or "good first review" for PR... if we'll too many drive-by stuff, we can always remove them later
08:04 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
08:06 < real_or_random> ok, we're over the hour already. any more thoughts?
08:06 < real_or_random> one more thing: I know it's *still* on me to update the API docs PR and I made this my main goal for this week (I hope I do more than that this week, but I really get this off the table)
08:08 < sipa> I don't have anything else.
08:10 < real_or_random> done?
08:10 < real_or_random> sipa roconnor 
08:10 < real_or_random> * nickler roconnor 
08:11 < roconnor> nothing from me.
08:11 < nickler> #endmeeting
08:11 < real_or_random> hehe no bot
08:11 < real_or_random> (can we get one? I don't want spend time on this but if we could one, I'd take it)
08:12 < real_or_random> anyway, it's the end of the meeting ^^
08:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
08:21 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
09:21 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
09:23 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
10:09 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:28 -!- halo [~halosghos@user/halosghost] has joined #secp256k1
10:28 -!- halosghost [~halosghos@user/halosghost] has quit [Read error: Connection reset by peer]
10:33 -!- halo [~halosghos@user/halosghost] has quit [Ping timeout: 240 seconds]
10:47 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:04 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
11:21 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
11:55 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
12:12 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
13:14 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
14:43 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
14:44 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.7.1]
14:57 -!- jonatack2 [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
15:21 -!- jonatack2 [~jonatack@user/jonatack] has joined #secp256k1
15:22 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
15:55 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
17:29 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
17:31 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
19:25 -!- jonatack2 [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
19:44 -!- jonatack2 [~jonatack@user/jonatack] has joined #secp256k1
22:04 -!- waxwing [~waxwing@193.29.57.116] has quit [Read error: Software caused connection abort]
22:05 -!- waxwing [~waxwing@193.29.57.116] has joined #secp256k1
--- Log closed Tue Nov 22 00:00:24 2022