--- Log opened Mon Jan 16 00:00:16 2023
06:24 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
06:25 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
07:01 < real_or_random> meeting
07:02 < real_or_random> sipa nickler hebasto 
07:02 < hebasto> hi
07:02 < real_or_random> (not sure who's here, it's a US holiday)
07:03 < nickler> hi
07:03 < sipa> hi
07:04 < real_or_random> :)
07:04 < real_or_random> topics?
07:04 < nickler> been busy with updating the musig2 module to v1 of the BIP in libsecp-zkp, so I have no topic to bring up
07:04 < real_or_random>  I'd like to talk quickly about github labels again
07:05 < sipa> ok
07:06 < nickler> I just realized that we have "discussions" now (good!)
07:06 < real_or_random> yes! :)
07:06 < real_or_random> and you can convert issues to discussions
07:07 < sipa> maybe a good question is wether we need all the categories
07:07 < real_or_random> I started adding labels to issues but then stopped again after a few because adding labels "touches" the issue, i.e., the last-modified timestamp is changed  
07:07 < real_or_random> sipa: ok yes, let's first talk about this
07:07 < nickler> ah that's probably why I didn't get notifications for the discussions
07:07 < real_or_random> discussion categories
07:07 < sipa> Q&A i think is definitely useful
07:07 < sipa> as it allows anyone to post
07:08 < real_or_random> yes, I feel Q&A is the only one we only need currently
07:08 < sipa> we could use Ideas for some design discussion that transcends individual PRs, but we really use issues for that now
07:08 < real_or_random> on the other hand, I don't think deleting the others would necessarily make things better 
07:09 < real_or_random> (also because clicking "discussions" gets you to "all discussions")
07:09 < real_or_random> tbh, I'm not sure if we can actually delete them Oo I can add and edit categories but I don't see a delete button
07:10 < sipa> I can delete them.
07:10 < real_or_random> I see
07:11 < sipa> Ok maybe a related question: which categories do we plan to use, and how?
07:11 < sipa> As in we may leave some around without a plan to use them, for now.
07:12 < nickler> Q&A and "other" for everything else?
07:12 < sipa> General, Ideas, and Show and Tell are "general discussion"
07:13 < real_or_random> until now I was only considering Q&A but yeah, using ideas for design discussion could be a useful thing. though I'm not sure. the way I see it is that issues/PRs is dev stuff and discussions is rather interaction with users  
07:13 < sipa> Polls, Q&A, and Announcements are special in who can post etc.
07:13 < sipa> Right.
07:13 < sipa> How about just leaving General and Q&A ?
07:13 < nickler> sgtm
07:13 < real_or_random> so I think having design issues still makes sense to me
07:13 < real_or_random> do we need announcements? probably not?
07:13 < sipa> We can always bring others back.
07:14 < sipa> Ah, could leave Announcements. It may be useful to post about new releases, as it allows users to comment (but not create a topic) there.
07:15 < real_or_random> can users reply to announcements? 
07:15 < sipa> Yes.
07:15 < sipa> > Share updates and news with your community. Only maintainers and admins can post new discussions in these categories, but anyone can comment and reply. 
07:15 < nickler> what kind of comment that's not an "issue" would be useful? questions?
07:16 < sipa> "oh kewl!"
07:16 < sipa> Maybe not.
07:16 < real_or_random> I think this dicussion belongs to the release process
07:17 < real_or_random> where do we want to announce? at the moment we use bitcoin-dev and I feel it's the right place
07:18 < sipa> yeah
07:19 < nickler> yeah
07:20 < real_or_random> so I'd like to keep for sure Q&A and General. I think we could also keep Ideas for now. Some issues are like "I want that feature" and I feel this is not always something that we immediately decide on (e.g., by closing). But having it stick around in issues can also be strange.  
07:20 < real_or_random> Not sure if I have an example in mind right now
07:21 < sipa> I don't know if we have a sufficiently large userbase on github that polls make sense.
07:21 < real_or_random> Polls can certainly go. "Show and tell" ... I don't care to be honest. It would be nice if someone used this but I don't think it will get traffic ^^
07:21 < sipa> I'm remove Polls and Show&Tell.
07:21 < sipa> *I'll ... ?
07:22 < real_or_random> hehe yeah, I mean I'd love to get more in touch with users. I think we have a lot of users but we never hear from them. But I don't think polls is the right way ^^
07:22 < real_or_random> we could have a poll about release intervals :P
07:22 < real_or_random> sipa: sgtm if nickler agrees
07:22 < sipa> Done.
07:23 < sipa> That's a good discussion topic here too, now.
07:23 < real_or_random> (right, it's on  my list for later :P)
07:23 < real_or_random> keep announcement or kill it? I tend to kill it because we have the ml
07:25 < sipa> I'm not sure.
07:25 < sipa> We can always recreate it later.
07:25 < real_or_random> ok, yes, remove it
07:25 < sipa> If we don't plan to post there, it will be unused, as we're the only ones who can post there.
07:25 < real_or_random> indeed
07:27 < sipa> nickler: agree?
07:28 < nickler> Q&A + general makes most sense to me
07:28 < nickler> everything else can be enabled as needed
07:28 < sipa> I need to go soon.
07:28 < sipa> Ok, announcements gone.
07:28 < real_or_random> ok, then I'd say remove announcement. I'd like to keep ideas. If it turns out to be unused, let's remove later
07:29 < real_or_random> sipa: okay then let's move to release schedule? 
07:29 < nickler> ideas is fine with me too
07:29 < real_or_random> (the label thing is low priority)
07:30 < sipa> ok.
07:30 < sipa> My general thinking on release schedule is "whenever we feel there is enough new stuff merged that warrants a release".
07:30 < real_or_random> I don't think I have an opinion currently... we could have a regular schedule, and it will have some advantages. maybe for users but also us. because this forces us to create a release every now and then. and this may be a good thing
07:31 < real_or_random> on the other hand, yes, "whenever we feel there is enough new stuff merged that warrants a release" is certainly a reasonable approach
07:31 < sipa> The overhead for doing a release for us is also pretty low (no binary releases etc), I think.
07:31 < sipa> Except coordination.
07:32 < real_or_random> we could also try to piggyback on the core schedule somehow
07:32 < real_or_random> not sure if that makes sense
07:32 < sipa> I guess it could make sense to certainly do a release a month or so before the Bitcoin Core feature freeze.
07:33 < sipa> Which would currently be march 1st.
07:33 < sipa> (the feature freeze being april 1st)
07:33 < real_or_random> (another advantage of a flexible schedule is that it may make easier to hide critical fixes under the carpet for a few days :P) 
07:34 < real_or_random> maybe let's do "whenever we feel it makes sense +  a month before Core feature freeze (to ensure we'll have a release from time to time)"
07:34 < sipa> sgtm
07:34 < real_or_random> nickler ? :)
07:34 < nickler> I'd be in favor of a fixed schedule. Easier to coordinate and plan.
07:35 < nickler> I haven't thought about hiding critical fixes though
07:35 < real_or_random> nickler: what would be your favorite interval?
07:35 < nickler> 6mo, to be reevaluated at the next release
07:36 < sipa> If we want a fixed schedule, I'd say every 3 months maybe?
07:36 < nickler> that's fine as well, we can always adapt
07:37 < sipa> 6 months is long, causes discussions of the form "oh no we need to get X in, or it's another half year!" which is unproductive for quality
07:37 < sipa> and for Bitcoin Core the release overhead is very high, so it makes sense not to do it too frequently
07:37 < real_or_random>  3 is good. we could still try to sync with core's interval 
07:37 < nickler> I'd be concerned that "whenever we feel like it" is annoying to pinpoint. And a (somewhat) fixed deadline would help with getting stuff done.
07:37 < sipa> but I don't think that applies to us
07:37 < sipa> we did one in december, next one in march?
07:37 < nickler> let's make sure that we keep overhead low then
07:38 < real_or_random> and nothing would stop us from making bugfix releases when we feel there's a need (if critical or non-critical)
07:38 < nickler> Dec 12, so next would be mid-March
07:38 < sipa> indeed
07:39 < real_or_random> syncing with the core schedule is still a good idea I think, so aiming for march 1st or similar sounds good to me for now
07:39 < sipa> agree
07:40 < real_or_random> (then another one after ~3 more months and then another one before the next feature freeze)
07:40 < nickler> ok
07:40 < real_or_random> does this even make sense? has core feature freeze only for major releases?
07:40 < sipa> yes
07:40 < real_or_random> ok
07:41 < sipa> every major release has a feature freeze + branch off + release
07:41 < sipa> and then backport releases for issues when deemed necessary
07:41 < real_or_random> I'll add this to the release discussion issue
07:44 < real_or_random> "Twice as often as a major release of Core (which is every 6-7 months), i.e., every 3-4 months for us. We try to aim to one month before feature freeze of Core major release for every second of our releases."
07:45 < real_or_random> "Of course, we can still create more releases whenever we feel there's need, e.g., for bugfixes."
07:45 < nickler> how do I keep track of Core feature freezes?
07:45 < real_or_random> https://bitcoincore.org/en/lifecycle/
07:45 < nickler> ty
07:45 < real_or_random> well it's out of date lol
07:46 < hebasto> and released schedules in a pinned issue
07:46 < nickler> ...and doesn't really mention feature freezes
07:46 < real_or_random> or I don't know... sipa where do you have the april 1st from?
07:46 < hebasto> https://github.com/bitcoin/bitcoin/issues/26549
07:47 < real_or_random> thanks
07:49 < real_or_random> sounds good? (end meeting?)
07:49 < nickler> As an aside, it would be great to have a summer of bitcoin student this year. Would be good to start thinking about possible projects (no need to discuss it here today).
07:49 < real_or_random> +1
07:50 < real_or_random> though I'm not sure if I'd be willing to take one :P 
07:50 < sipa> I need to go.
07:51 < nickler> I'd say depends on the project and student (plus siv2r volunteered to help)
07:51 < real_or_random> ok end meeting then ^^
07:51 < real_or_random> nickler: yes, makes sense
07:54 < real_or_random> https://github.com/bitcoin-core/secp256k1/issues/1176#issuecomment-1384243952
07:56 < roconnor> How would folks feel about naming all our structs (as their corresponding typedef)?  I don't really want to impose, but it would help my tooling which currently treats our structs as anonymous (which they are).
07:57 < sipa> you mean use: typedef struct secp256k1_fe { ...} secp256k1_fe;
07:57 < sipa> ?
08:00 < roconnor> yes.
11:07 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
11:10 -!- jon_atack [~jonatack@user/jonatack] has joined #secp256k1
11:26 < real_or_random> I don't think we care. If this works better with tooling, then is a good argument. (So far I wasn't aware of any argument for either side...)
11:26 < real_or_random> (Which tooling by the way?)
12:01 < roconnor> VST.
12:02 < roconnor> I'm happy to patch just locally thought
12:02 < roconnor> though.
12:12 < real_or_random> just open a PR :)
12:12 -!- Netsplit *.net <-> *.split quits: sanket1729
12:13 -!- Netsplit over, joins: sanket1729
12:15 < real_or_random> andytoshi: interested in re-reviewing https://github.com/bitcoin-core/secp256k1/pull/1192 ? 
12:16  * real_or_random crazy that we've been working with this group of size 13 since forever but there's in fact smaller one 
12:17 < real_or_random> (Oo not sure how I added "/me" here)
12:25 < andytoshi> real_or_random: sure :)
12:25 < andytoshi> i actually just decided to skip over that one since it looked like you had it :P but i'll take another look. i like this one
12:26 < andytoshi> real_or_random: re "there's a smaller one" .. that's true. there's also one of order 3 i think. 13 was chosen to be the biggest one that was still feasible
12:26 < andytoshi> not the smallest
12:26 < real_or_random> yeah I don't know... it wouldn't be unreasonable to merge it with only one ACK but I'd prefer two ACKs
12:27 < real_or_random> (maybe we should relax the implicit policy a tiny bit for PRs like this that touch only tests but I guess that's a different discussion)
12:28 < andytoshi> yeah. no need in this case, i'm happy to review it
12:29 < andytoshi> it lgtm. i need to run my local CI scripts on it (which is a bit silly because my local CI doesn't even run the sage ... but i guess it'll check that the exhaustive tests still work)
12:29 < andytoshi> i have some rust-bitcoin thing queued ahead of it. might be half an hour or so
12:29 < real_or_random> yep you're right there's also a group of size 3 but it's rejected by the sage script as too small. but the 7 wouldn't have been rejected and apparently noone knew it existed?
12:30 < real_or_random> andytoshi great thanks
12:31 < andytoshi> i feel like i knew it existed :P but ok, i doubt i wrote it down anywhere
12:33 < andytoshi> in the commit message for 83836a95472ab8ddf8c27cf4e9956d4eeed3bdaf i casually mentioned that there was a subgroup of order 14
12:33 < andytoshi> ..which is pretty weird tbh. i say "it won't work because it's composite" but for some reason i left code in place for it, and didn't even mention that the order-7 one could work
12:33 < real_or_random> ok yes, I mean we knew there's one with size 7
12:33 < real_or_random> but it doesn't have an endo
12:34 < real_or_random> but there's a *second* group with size 7 with an endo
12:34 < andytoshi> innnteresting
12:34 < andytoshi> i am surprised that any subgroup wouldn't have an endo
12:34 < andytoshi> because multiplication by beta preserves the group operation
12:35 < andytoshi> so it has to be an endomorphism ... which in turn would have to correspond to multiplication by something
12:36 < andytoshi> in the non-endo subgroup of order 7, what happens if you multiple the x coordinate of a point by beta?
12:36 < real_or_random> cc sipa 
12:37 < real_or_random> this is essentially what the script checks: https://github.com/bitcoin-core/secp256k1/blob/4934aa79958b506a6e9cfcfe30a8f685db3f5f5f/sage/gen_exhaustive_groups.sage#L76
12:38 < real_or_random> where l iterates over the non-trivial cuberoots of 1
12:40 < andytoshi> weeeird. so the implication is that multiplication by beta takes you out of the subgroup
12:40 < andytoshi> IOW the GLV "endomorphism" is actually an isomorphism between different subgroups of order 7
12:40 < andytoshi> in this case
12:41 < andytoshi> that is really fascinating
12:41 < andytoshi> i think previously i had just assumed this was impossible
13:27 < sipa> So I'm still pretty baffled by this actually.
13:28 < sipa> There are two independent subgroups of order 7 on y^2 = x^3 + 1.
13:29 < sipa> Which means that you can find two independent generators g1, g2, and construct a group of order 49 generated by those two, where every element can be written as a1G1 + a2G2, where a1,a2 both in Z7.
13:29 < sipa> So there are actually, I think, 7 distinct groups of order 7, that all share the point at infinity but no other points.
13:30 < sipa> And it appears that two out of these 7 have an endomorphism.
13:31 < sipa> Because there are 12 distinct generators for cyclic groups of order 7 (which I assume are 6 generators for two groups each, excluding infinity).
13:31 < sipa> which are endomorphism-compatible.
13:34 < sipa> Actually, no, I think there are 8 distinct groups of order 7, necessarily.
13:35 < sipa> Those with a1=0, those with a2=0, and those with a1/a2 = c, for c=1..6.
13:35 < sipa> That makes sense, because there are 48 generators for order 7 groups.
13:39 < real_or_random> you mean y^2 = x^3 + 6
13:39 < real_or_random> which has order 2^2 * 7^2 * 10903 * 5290657 * 10833080827 * 22921299619447 * 41245443549316649091297836755593555342121 by the way
13:39 < sipa> Errr yes.
13:40 < sipa> @andytoshi So yes I guess this must mean if you are on the wrong subgroup, the beta multiplication takes you to a different subgroup.
13:41 < sipa> But it must take you to another point of order 7?
13:42 < sipa> So the beta multiplication applied to a1G1 + a2G2 must result in some f1(a1,a2)G1 + f2(a1,a2)G2 ?
15:22 < andytoshi> sipa: yeah, it must take you to a point of order 7 because it's invertible
15:23 < andytoshi> and because it preserves the group operation
15:25 < andytoshi> your counting all seems to make sense to me ... at least, it adds up
15:25 < andytoshi> it's pretty trippy
15:27 < sipa> Just got home, let's experiment with this...
15:43 < sipa> Ok, so all the above seems correct.
15:44 < sipa> Let G1 and G2 be generators of the two endomorphism-compatible order-7 subgroups.
15:46 < sipa> Let C_i be the subgroup consisting of itG1 + tG2 for t=0..6 (with i=infinity for the group consisting of tG1).
15:47 < sipa> Then beta*C_i lands you in C_{2i}.
15:47 < sipa> If i=0 or i=inf, it's an endomorphism.
16:20 < sipa> Ah! And there is a much simpler explanation.
16:21 < sipa> With the same two generators G1,G2 above, beta-multiplying a*G1 + b*G2 gives 2*a*G1 + 4*b*G2.
16:21 < sipa> If you started off with a*G1, you get twice your input, so lambda=2.
16:22 < sipa> If you started off with b*G2, you get 4 times your input, so lambda=4.
16:22 < sipa> But if you started off with a linear combination with non-zero contributions from both, you get a different linear combination that's not a pure multiple back.
16:24 < sipa> Put otherwise, for any independent generators G1,G2 of the order-49 subgroup, if you think of the elements as vectors with basis G1,G2, then beta-multiplication is effectively a linear transformation on those vectors.
16:24 < sipa> That linear transformation has eigenvalues 2 and 4.
16:25 < sipa> The subgroup consisting of eigenvectors corresponding to eigenvalue 2 is the subgroup in which the endomorphism works, with lambda=2.
16:25 < sipa> Same with eigenvalue 4.
16:43 < sipa> Exercise for the reader: why is there only one subgroup of size 13, despite the y^2=x^3+2 order being divisible by 13^2 ?
17:29 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
17:29 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
18:45 < roconnor> https://github.com/bitcoin-core/secp256k1/blob/a7a7bfaf3dc19c2554db6a1da07f7f688af10b30/src/util.h#L254
18:45 < roconnor> should this maybe be rewritten as
18:46 < roconnor> debruijn[(((x & -x) * 0x04D7651FU) & 0xFFFFFFFF) >> 27]
18:46 < roconnor> In some crazy world where this function get compiled where ints are 64 bit, then it won't work as currently written
18:48 < roconnor> There are a couple choices as to how to write the above.  I added U to the constant to make sure it is unsigned, and we are not mixing signs.  I chose the mask in such away that I hope the compiler will notice to optimize it out.
18:53 < sipa> Instead of the & 0xFFFFFFFF, could you cast to uint32_t ?
18:54 < roconnor> yep sure.
18:54 < roconnor> makes sense.
19:21 < roconnor> I've opened https://github.com/bitcoin-core/secp256k1/pull/1194
22:32 -!- siv2r [~siv2rmatr@2001:470:69fc:105::fed3] has joined #secp256k1
--- Log closed Tue Jan 17 00:00:17 2023