--- Log opened Mon Feb 13 00:00:10 2023
--- Day changed Mon Feb 13 2023
00:00 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
01:01 -!- Netsplit *.net <-> *.split quits: cfields, sebx2a, realtbast[m], FelixWeis
01:01 -!- sebx2a [sid356034@2a03:5180:f:5::5:6ec2] has joined #secp256k1
01:02 -!- FelixWeis [sid154231@2a03:5180:f:4::2:5a77] has joined #secp256k1
01:07 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has joined #secp256k1
01:25 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
02:47 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
03:31 -!- roconnor_ [~quassel@coq/roconnor] has joined #secp256k1
03:35 -!- Apocalyptic_ [~Apocalypt@user/apocalyptic] has joined #secp256k1
03:36 -!- Netsplit *.net <-> *.split quits: Apocalyptic, roconnor
04:40 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
05:55 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
06:01 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
06:01 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
06:16 -!- roconnor_ is now known as roconnor
07:00 < nickler_> hi
07:00 < sipa> Meetin' time?
07:00 < nickler_> topic suggestion: summer of bitcoin
07:00 < real_or_random> hi
07:00 < siv2r> hi
07:01 < sipa> hi
07:02 < nickler_> siv and I agreed to co-mentor an SoB participant and we would like to know if you have ideas for project ideas.
07:02 < nickler_> we've already looked at quite a few possibilities, with an emphasis on projects that would be interesting to a student
07:02 < nickler_> our favorites are so far 1) implementing Schnorr adaptor signatures in secp-zkp and 2) address (some of the) outstanding musig issues: https://github.com/ElementsProject/secp256k1-zkp/issues/155
07:02 < nickler_> People regularly ask about an implementation of Schnorr AS. Presumably because this is one of the ways to implement PTLCs in the LN (the other being musig adaptor sigs).
07:02 < hebasto> hi
07:02 < nickler_> It Shouldn't be too hard to implement given that secp-zkp already has  ecdsa and musig adaptor sigs.
07:03 -!- joschisan14 [~joschisan@2a02:3032:20f:4f0e:7d05:179:10c2:a0f4] has joined #secp256k1
07:03 < nickler_> there'd be bonus points for writing a spec (draft).
07:03 -!- joschisan14 [~joschisan@2a02:3032:20f:4f0e:7d05:179:10c2:a0f4] has quit [Client Quit]
07:03 -!- joschisan12 [~joschisan@2a02:3032:20f:4f0e:7d05:179:10c2:a0f4] has joined #secp256k1
07:03 < real_or_random> Both ideas sound very useful to me
07:04 < nickler_> cool
07:04 < siv2r> This document contains all the possible ideas we considered: https://www.notion.so/siv2r/dd6c7f6f1695452f9f8092a4d19717b3?v=6b9aced4ad8a4acbbb4dc6f7eb2cedef&pvs=4
07:05 < real_or_random> nickler_: we should think about PR'ing musig to here at some point. At what stage do we want to do this? 
07:05 < sipa> A concern with something like this for students is that even if they do everything right, the project may not make much progress within the time they work on it, and afterwards the student may just disappear due to other obligations.
07:07 < nickler_> sipa: I think the project is reasonably self contained that the student can make progress on their own. But yeah, it should be made clear that if they disappear someone else might take over.
07:07 < real_or_random> that may be (a bit) less of an issue in secp-zkp
07:08 < siv2r> sorry sent the wrong link earlier. this is the correct one: https://siv2r.notion.site/libsecp256k1-Project-Ideas-4cbce73978ca414aae5e358ff30cfa5d
07:08 < nickler_> real_or_random: I don't know
07:08 < sipa> Maybe, yes, but ultimately we want real-world adoption, and that depends on more than just having code available.
07:09 < nickler_> real_or_random: the musig code is still quite fresh for what it's worth + the issue I linked to has a bunch of useful improvements. So I guess "now" wouldn't be the greatest time.
07:10 < real_or_random> nickler_: yes,I think I agree
07:10 < nickler_> sipa: not sure I see your point. Having code available for people to play with (even if just a toy) seems like a good first step towards adoption.
07:10 < real_or_random> sipa: Do you think an "assurance" project would be better in that regard? 
07:11 -!- nickler_ is now known as nickler
07:11 < sipa> Yeah, certainly, I just worry that if a project is pushed by a student, who at some point just disappears, the project (even if there is code) may lose steam and not go anywhere.
07:11 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
07:12 < sipa> More narrowly-scoped things like say developing a fuzz target, or modernizing the test framework, or investigating some optimization or algebraic technique ... may be better in that regard (but depending on the student, may be less interesting too).
07:12 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
07:13 < nickler> sipa: I don't think that having a toy implementation increases the probability that the adaptor signature project goes nowhere
07:13 < real_or_random> I understand what you're saying. It depends a bit on the project though. I don't think musig will lose steam, there's too much interest from others
07:13 < sipa> Ok.
07:14 < real_or_random> For adaptor sigs, that's indeed more risky. See for example the anti-exfil PR, which is a similar state. I'd love to spend time on this but I don't have the time right now and I can't tell when I'll have time to look into this
07:14 < nickler> the downside with these types of assurance projects is that most of the work is rather boring, e.g. dealing with the build system, and often seem to require a lot more hand holding
07:14 < sipa> Yeah, agree with that.
07:15 < nickler> s/boring/frustrating
07:15 < real_or_random> siv2r: What do you think? Your batch verification PR doesn't get a lot of attention either. Not sure if it so much fun to have another one in a similar state 
07:16 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
07:16 < real_or_random> But again: I don't see this problem with musig, so maybe that's the better project from that point of view.
07:18 < nickler> real_or_random: batch verification is a bit different because it's in secp and purely internal. if we manage to merge schnorr AS into -zkp then people could use it (experimentall)
07:19 < real_or_random> indeed.
07:20 < nickler> Anyway, thanks for your feedback. I'll see if I can translate the various musig improvement bullet points into a single project.
07:20 < sipa> FWIW, I do plan to review the batch verification code, but it's currently fairly low priority for me (in part because making it actually useful relies on a fairly invasive refactor in Bitcoin Core to introduce multi-input or multi-transaction script validation).
07:20 < real_or_random> One important question is obviously what siv2r feels is more motivating. ^^ So I'd like to hear his opinion.
07:21 < siv2r> I think student are less likely to take on project that majorly involves testing and build systems. But more interested towards implementing cryptography scheme. Atlest that's I felt from my peers who are looking to participate in SoB'23. 
07:21 < siv2r> Getting the PR merged to the codebase depends on the maintainers ig. I enjoyed working on Bath verification. It not getting merged doesn't affect my interest toward cryptography.
07:21 < real_or_random> nickler: ok, sounds good. I'm certainly either of the two  project ideas will be useful in some form in the end.
07:22 < real_or_random> siv2r: makes sense, I understand that point
07:23 < siv2r> real_or_random: are you asking my pref between musig vs adaptor sig? If so, Both looks equally interesting to me.
07:24 < real_or_random> yep my question was about i) your pref as co-mentor because that's relevant too for motivation and ii) what you think students will prefer
07:24 < real_or_random> but you've covered both aspects now :)
07:25 < siv2r> Also, When I applied to SoB'22. The people I have talked to chose libsecp mainly to learn more cryptography.
07:26 -!- joschisan12 [~joschisan@2a02:3032:20f:4f0e:7d05:179:10c2:a0f4] has quit [Ping timeout: 260 seconds]
07:27 < nickler> Ok, so siv2r and I will submit one of the two projects. Thanks again. I have nothing else on that SoB topic.
07:27 -!- joschisan7 [~joschisan@2a02:3032:20f:4f0e:7d05:179:10c2:a0f4] has joined #secp256k1
07:27 < nickler> other topics?
07:28 < real_or_random> one I wanted to bring up a few times
07:29 < sipa> In Bitcoin Core, there is the "high priority for review" list, where everyone can nominate one PR that they or others are blocked on. Would it be useful to have a discussion topic like that here?
07:29 < sipa> Maybe just informally, as it gives an idea of what people are working on.
07:29 < real_or_random> ok, let's discuss this first
07:30 < real_or_random> i don't think. I think we had this topic a few useful in an informal manner and it made sense
07:30 < real_or_random> s/i don't think//
07:30 < sipa> Hmm, I still can't parse your sentence I'm afraid.
07:31 < real_or_random> sorry I'm too stupid to type
07:31 < real_or_random> I think we had this topic (high priority for review ) a few times in an informal manner and it was useful and it made sense to discuss it
07:32 < real_or_random> though I don't think a more formal list would help a lot because most of the relevant contributors read here 
07:33 < sipa> Agree.
07:33 < nickler> does it need to be more formalized than informally attempting to discuss this in every meeting (if necessary)
07:33 -!- hg [~halosghos@user/halosghost] has joined #secp256k1
07:33 < real_or_random> and sometimes we can agree about priorities but still noone finds time :P but sure, let's discuss
07:34 < sipa> Yeah.
07:34 < nickler> fwiw I still would like to get back to reviewing the jacobi symbol PR as promised (sorry)
07:35 < sipa> That's my biggest blocker currently, so I'd appreciate it :)
07:35 < real_or_random> the big projects that I wish to see merged soon is cmake and jacobi (because they're pretty mature and have been around for a long time now), in no particular prio  
07:35 < sipa> Oh yes, I'll play around more with cmake this week.
07:35 < hebasto> sipa: real_or_random: cool!
07:37 < sipa> Anyone else want to mention what they're working on, or what they're blocked by?
07:38 < nickler> somewhat secp related: I need review on the PR that updates the musig implementation to v1 of the BIP, but I already have a review promise :)
07:38 < sipa> I should first review the BIP itself, I think.
07:38 < real_or_random> I don't have anything for a high prio list. There's still this small PR where it would make sense to get a second ACK because it has one ACK already https://github.com/bitcoin-core/secp256k1/pull/1078 
07:39 < siv2r> I have been reviewing Jacobi PR. The last two commits are remaining.
07:39 < real_or_random> (or benchmarks actually...) but that PR is not a big deal. Maybe I'll ping Peter Dettman for review. sipa: If you want to benchmark this, this would also make sense.
07:40 < sipa> real_or_random: Will do.
07:40 < sipa> Maybe andytoshi is interested in #1078 as well?
07:40 < sipa> siv2r: You're through the hardest part already in that case.
07:40 < real_or_random> nickler: yeah, I'll promise to come back to that musig PR next week
07:42 < andytoshi> sipa: sure, i'll take a look
07:43 < real_or_random> more topics?
07:43 < sipa> real_or_random: Didn't you have a topic you wanted to bring up before I mentioned the high-priority PR idea?
07:43 < siv2r> pieter: oops, last three. not through hardest part ig. Haven't started the review of Jacobi implementation yet.
07:44 < sipa> Ah!
07:45 < real_or_random> sipa: yeah, ok, but let's make sure to keep that discussion short then :)
07:45 < real_or_random> we talked about issue/PR labels a while ago
07:46 < real_or_random> then I started to add labels to existing issues/PRs but I stopped after three or four because adding labels "touches" the timestamps
07:47 < real_or_random> so it screws up things for people who use "sort:updated-desc"... and it may even trigger notifications 
07:47 < hebasto> adding labels won't trigger notifications
07:47 < sipa> I do use sort:updated-desc, but I honestly don't care about a one-time mass-reset of everything, if the labels are useful.
07:47 < real_or_random> (though docs seem to suggest that notifications are not triggered.) 
07:48 < real_or_random> I can try to update them in the "right" order so that order is preserved 
07:49 < real_or_random> which is what I would have done if I had to decide on my own. but I wanted to ask here first to make sure I don't get in the way of people's workflows
07:49 < nickler> another option would be to add labels when there's new discussion (not great either)
07:50 < nickler> updating in the "right" order would be fine for me
07:51 < real_or_random> (I think batch assigning labels adds them in the wrong order but that's a big deal. We have just a few open issues/PRs, so it will take maybe take an hour or two more not to use batch processing and I'm happy to spend the additional time.)   
07:51 < real_or_random> ok
07:52 < real_or_random> then I'll do that once I find time again :)
07:52 < real_or_random> more topics?
07:54 < sipa> i guess not
08:04 < real_or_random> end of meeting, to state the obvious ^^
08:05 -!- joschisan7 [~joschisan@2a02:3032:20f:4f0e:7d05:179:10c2:a0f4] has quit [Ping timeout: 260 seconds]
08:19 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
08:20 -!- jon_atack [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.8]
08:23 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
10:13 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:16 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
10:33 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
11:01 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:38 -!- scg [~scg@227.2.196.181.static.anycast.cnt-grms.ec] has joined #secp256k1
11:38 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
11:48 < scg> scary part of wiki https://en.bitcoin.it/wiki/Address_reuse#Security which basically states that address reuse is not just privacy concern but also security one. If I sign multiple messages with same key and all signatures are public is it "trivial" or "maybe possible" to get back to the signing key from those multiple signatures? more sauces: 1.
11:48 < scg> https://crypto.stackexchange.com/questions/83891/can-one-extract-a-private-key-from-a-series-of-care...  2. https://crypto.stackexchange.com/questions/75463/is-ecdsa-signature-strongly-euf-cma/75467#75467 (cross-posted from #bitcoin)
11:51 < sipa> No, there is no known practical way to compute the signing key from ECDSA or BIP340 signatures, even when there are multiple signatures per key, assuming the signatures were created by a correct implementation.
11:52 < sipa> There are certainly implementation pitfalls which could make this easier (in particular, broken nonce generation) for an attacker, and in some cases practical, but that would mean the implementation is broken.
11:55 < scg> thanks for clarification! I;m planing to sign exported address list with first address/key from the list - was not sure if I'm not throwing users under the bus
12:09 < real_or_random> I think the wiki is badly worded here. Both ECDSA and BIP340 are designed to be secure when the same key is used to sign multiple messages. That's still not a great idea for privacy but it's perfectly okay for signature security. 
12:16 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
12:46 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
12:51 -!- scg [~scg@227.2.196.181.static.anycast.cnt-grms.ec] has quit [Ping timeout: 260 seconds]
12:52 -!- scg [~scg@227.2.196.181.static.anycast.cnt-grms.ec] has joined #secp256k1
13:02 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
14:54 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
15:19 -!- hg [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.8]
15:29 < andytoshi> done reviewing #1078. This is really nice!
15:31 < andytoshi> oh, nice, i can't test because my arch copy of valgrind is broken again. need to reboot to fix that, which i generally only do on weekends
15:39 < sipa> you can test with msan now :)
15:39 < sipa> clang CFLAGS="-fsanitize=memory" --disable-asm
15:39 < andytoshi> cool, thanks!
15:39 < andytoshi> do you know if it covers everything valgrind can?
15:40 < sipa> as far as constant-timeness goes, i believe it is identical or very close
15:41 < andytoshi> nice. and i assume it'll catch accesses to NULL pointers or flagrantly-invalid pointers
15:41 < andytoshi> "subtle" invalid pointers like arrays out of bound might be harder without the kind of slowdown that valgrind has
15:41 < sipa> it's different as sanitizers operate closer to source code
15:44 < sipa> msan will generally catch those too
15:44 < sipa> it's just that valgrind can operate on actual production library code
15:44 < andytoshi> ah gotcha. nice
15:45 < sipa> rather than on a specially instrumented compilation
15:47 < sipa> sanitizers can be more powerful actually, as say a nullptr dereference in some cases could be optimized out, so valgrind wouldn't catch it
15:47 < sipa> but a sanitizer would notice, as it operates at the source code semantics
15:58 < andytoshi> so, if i just run ctime_tests outside of valgrind, i get a msan error
15:58 < sipa> did you disable asm?
15:58 < andytoshi> ah nope, thanks
15:59 < andytoshi> i ran ./configure CC=clang CFLAGS="-fsanitize=memory" --disable-asm
15:59 < andytoshi> and then just `make -j88` like usual .. and i'm still getting it
16:00 < andytoshi> oh, config.log shows asm is enabled, i think i just need to tweak syntax
16:00 < andytoshi> --with-asm=no maybe
16:01 < andytoshi> it works!
16:01 < sipa> it's --without-asm, not --disable-asm, sorry
16:02 < andytoshi> super cool that we have that convenient "leave asm enabled" test, otherwise i'd have spent forever poking at it trying to see if msan was really on
16:03 < andytoshi> also, did we merge the --all-modules flag or whatever that was called?
16:03 < sipa> perhaps we can emit a compile error if you combine asm with msan
16:05 < sipa> don't think so
16:06 < sipa> but all modules except recovery are default on
16:06 < andytoshi> oh nice
16:11 < andytoshi> oh, lol, #1078 predates the ctime tests
16:14 < sipa> really?
16:17 < andytoshi> oh maybe it used to be called ctime_test without the s
16:18 < sipa> it was called valgrind_ctime_test
16:18 < andytoshi> ah yep there we go
16:20 < andytoshi> oh man, msan is awesome
16:21 < andytoshi> i'm using it on elements now to poke at roconnor's simplicity code and it's finding all the things we forgot to initialize
16:22 < sipa> msan is a pain to make work for any nontrivial codebase, unfortunately
16:22 < sipa> because it needs all dependencies compiled with msan
16:22 < andytoshi> ah, damn
16:23 < sipa> otherwise all memory modified by non-covered libraries is seen as uninitialized
16:24 < sipa> valgrind works for bitcoin core very wellz though
16:25 < andytoshi> ah, ok
16:25 < andytoshi> frustrating, because my valgrind is broken, it has some debuginfo path thing
16:26 < andytoshi> which almost certainly menas "you need to update your valgrind and glibc" which usually means rebooting the whole system
16:32 < sipa> probably, yeah
16:33 < sipa> bitcoin core's CI does run tests in an msan-compiled version, i believe, but it relies on a docker environment with lots of things specially compiled, and a curated exception list etc
17:04 -!- scg [~scg@227.2.196.181.static.anycast.cnt-grms.ec] has quit [Quit: Client closed]
22:40 < fanquake> andytoshi: what’s the valgrind debug issue?
23:22 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
--- Log closed Tue Feb 14 00:00:44 2023