--- Log opened Wed Nov 24 00:00:41 2021
02:05 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection]
02:05 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined #secp256k1
05:43 < real_or_random> I played around with CFLAGS="-fdata-sections -ffunction-sections -O2 -g" LDFLAGS="-Wl,--gc-sections" and it works with static linkage. The verification table is removed if the program never accesses it
05:44 < real_or_random> If benchmarks show that performance does not suffer (man gcc warns that some optimizations are not possible), do you think we should enable the CFLAGS by default?
05:45 < real_or_random> Or rather document them somewhere, e.g., in an README for embedded (which we should write anyway)  
06:27 < sipa> may be worth benchmarking with -flto too (as it should also permit removing unused parts)
06:47 -!- hg [~halosghos@user/halosghost] has joined #secp256k1
07:02 < hg> hey there everyone; I'm poking around with bulletproofs, and particularly I'm looking at PR #108 on https://github.com/ElementsProject/secp256k1-zkp and I have a few questions. Is it in-scope to ask some questions about that fork here?
07:16 < michaelfolkson> hg: I'd say it is fine. The PR author is in this channel.
07:16 < michaelfolkson> Slightly out of scope for this channel but only just :)
07:17 < hg> I didn't realize the author was in-channel
07:17 < hg> but that does bode well ☺
07:20 < hg> so, I'm trying to get my bearings with bulletproofs and rangeproofs. That PR provides a benchmark, but I'm struggling to understand which line in the bulletproofs verify benchmark run is comparable to the rangeproof benchmark
07:21 < hg> (I recognize that the bulletproofs implementation isn't intended to be optimized, so the comparison isn't necessarily fair; but I want to be comparing different kinds of apples rather than apples to window latches)
07:24 < sipa> iirc they're not comparable, because rangeproofs use a simplified construction compared to generic circuits
07:28 < hg> hmm
07:29 < hg> I had been reading this bulletproof code as if it was specifically the bulletproof variant of rangeproofs, not supporting generic circuits
07:29  * hg has to read a lot more it seems
07:31 < sipa> oh, that's possible
07:31 < sipa> i have not looked at the code
07:33 < hg> well, without looking too much deeper, the implemented function names are secp256k1_bulletproofs_rangeproof_uncompressed_verify_impl and similar
07:34 < hg> having said that, naming things is hard ☺
07:45 < sipa> in that case, ignore what i said
07:47 < hg> lol
08:51 < real_or_random> sipa: but do you have an opinion on whether those space savings should be the default?
08:51 < sipa> real_or_random: i think my opinion will depend on how much performance is impacted by it :)
08:52 < real_or_random> right :D that's why I was asking a hypothetical question. but ok, let's first do the bechmarks
08:53 < real_or_random> I think my question was rather if there's any known issues with these flags except that they can hurt performance
08:54 < sipa> i think function sections / data sections are very safe
08:55 < sipa> they just split the output asm up into separate sections, and then lets the linker drop the unused ones
08:55 < sipa> LTO used to have bugs early on when it was introduced in compilers
08:56 < real_or_random> indeed that's my understanding too
08:56 < real_or_random> do you expect LTO to remove the data without splitting into sections? 
08:57 < sipa> yes
08:58 < real_or_random> oh yes, it does, I've just checked
08:58 < real_or_random> we should always optimize for size. Benchmarking sizes is so much easier :D 
09:05 < sipa> but lto only works when the whole binary uses it
09:06 < sipa> so it isn't really a secp-only choice
09:12 -!- fjahr [sid374480@uxbridge.irccloud.com] has quit [Ping timeout: 245 seconds]
09:13 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has joined #secp256k1
09:16 -!- Netsplit *.net <-> *.split quits: Apocalyptic, FelixWeis, elichai2
09:22 -!- Netsplit over, joins: FelixWeis, elichai2
09:27 -!- roconnor [~roconnor@coq/roconnor] has joined #secp256k1
09:35 < real_or_random> sipa: well but the same is true for the other optimizations because users need to link with --gc-sections then
09:36 < sipa> but i think gc-sections never hurts on its own
09:36 < real_or_random> true
09:39 < sipa> but fair point
09:49 -!- Apocalyptic [~Apocalypt@user/apocalyptic] has joined #secp256k1
15:04 < sanket1729> How to figure out what context object to use to secp256k1_keypair_xonly_pub()? 
15:05 < sanket1729> secp256k1_context_verify or secp256k1_context_sign ? I see instances of both used in bitcoin core
15:05 < sanket1729> AFAIU sign and verify relate to precompute tables, and don't have anything to do with "signing" or "verification"
15:06 < sipa> soon it won't matter :)
15:09 < sanket1729> before the soon :P ? I take it will be a long time till all the libsecp APIs are updated to remove the context objects
15:10 < sipa> this is the function for extracting a pubkey from a keypair? it needs neither
15:20 < sanket1729> Yeah
16:14 -!- hg [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.3]
16:18 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #secp256k1
16:18 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 268 seconds]
16:19 -!- lukedashjr is now known as luke-jr
16:29 -!- ajonas_ [uid385278@id-385278.helmsley.irccloud.com] has joined #secp256k1
17:31 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
17:33 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
19:03 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
19:05 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
19:07 -!- ajonas_ [uid385278@id-385278.helmsley.irccloud.com] has quit [Quit: Connection closed for inactivity]
--- Log closed Thu Nov 25 00:00:42 2021