--- Log opened Wed Nov 03 00:00:22 2021
01:11 < real_or_random> sounds good :)
01:11 < real_or_random> this -zkp WIP WIP PR is interesting to secp too. https://github.com/ElementsProject/secp256k1-zkp/pull/153
01:14 < real_or_random> We had this discussion of having some way of exposing internals a few times. That would help others build their own modules more easily.
01:16 < real_or_random> What was the reason to have make the library a single compilation unit? Just to enable compiler optimization or are there other reasons? 
01:57 < sipa> yeah, optimization
03:18 -!- kallewoof [~quassel@user/kallewoof] has quit [Remote host closed the connection]
03:20 -!- kallewoof [~quassel@user/kallewoof] has joined #secp256k1
04:01 < nickler> would be really interesting to have some data on how much that matters
04:01 < nickler> With andytoshi stepping down we'll need to update SECURITY.md and the forwarding rules of secp256k1-security@bitcoincore.org.
04:01 < nickler> I didn't want to be a security contact before because three is enough, but now I'd be happy to be nr 3.
04:27 < real_or_random> nice
05:10 < sipa> nickler: for field logic i can imagine it matters a lot
05:11 < sipa> for things like field addition/negation, function call overhead + lack of ability to inline at least feels very relevant
05:41 < nickler> One interesting test case would be the vanity pubkey generator. But OTOH in something like FROST scalar and field (check y even and negate?) operations should be rather negligible.
07:06 < elichai2> FWIW, I thought for a while of forking libsecp and exposing the internals to rust FFI, so rust cryptographer could use it to build their own stuff, (that way avoiding unfortunate things like the silly bugs that were in https://github.com/paritytech/libsecp256k1 attempt at translating libsecp)
07:06 < elichai2> BTW, with LTO and cross-language LTO I imagine there should be very low overhead
07:06 -!- roconnor [~roconnor@host-45-58-217-8.dyn.295.ca] has quit [Ping timeout: 260 seconds]
07:08 < elichai2> currently there's a single rust library that gets close to the perf of libsecp(It's called k256) but it's still behind in terms of perf and also it's not nearly as battle tested as libsecp is
07:16 -!- roconnor [~roconnor@host-45-58-217-8.dyn.295.ca] has joined #secp256k1
07:17 < roconnor> FWIW, I did fork libsecp256k1 for my Simplicity work to get access to internals; however I would have done that no matter what since I need consistent jacobian coordinate computations.
07:21 < real_or_random> not sure how good cross-language LTO works
07:22 < real_or_random> elichai2: you could also transpile it to rust (and add a more idiomatic wrapper). then it's all rust
07:24 < elichai2> real_or_random: yeah but currently the transpiler has some inherit UB in rust under the currently proposed aliasing model for rust. but that might've gotten solved lately (cc https://github.com/immunant/c2rust/issues/301)
07:26 < elichai2> also, IIRC it generated some non-rust code (an init section for the globals with a linker attribute so it will initialize the globals at init time)
07:26 < elichai2> But I should prob give it another try, it was helpful for me in running rust-secp256k1 under `miri`, but that's a different topic
07:27 < elichai2> roconnor: consistent as in platform independent? or something else?
07:27 < roconnor> consistent as in consensus critical?
07:27 < real_or_random> ah nice
07:30 < real_or_random> elichai2: if you tried this in the past, did you run the benchmarks?
07:30 < elichai2> roconnor: oh so consistent as in "they might change in libsecp without breaking the public API and I need them to never change"?
07:31 < roconnor> Yep.
07:31 < elichai2> real_or_random: using c2rust I got the exact same perf as with libsecp in C
07:31 < real_or_random> that's awesome
07:34 < real_or_random> tbh, that sounds more attractive then, at least once the UB issue has been resolved 
07:35 < real_or_random> or even now... any toolchain/compiler has bugs, this is just another bug.
07:39 < elichai2> well, it's not really "rust rust" per-se(you can see the lax_der_parsing for example here: https://github.com/elichai/rust-secp256k1/blob/c2rust/c2rust_out/src/contrib/lax_der_parsing.rs), but yeah might be more attractive than bindings, as if there's no UB it shouldn't be worse than C
07:46 < real_or_random> sure the output won't be nice code but one could maintain a wrapper on top on it
07:46 < real_or_random> (as you would do with bindings)
07:50 < elichai2> Unrelated question, Why do fields have magnitudes but scalars don't?
07:52 < sipa> because scalar performance doesn't matter as much
07:53 < sipa> the magnitudes are there to reason about non-normalized numbers
07:53 < sipa> scalars are just always normalized
07:54 < andytoshi> public "i am stepping down" issue https://github.com/bitcoin-core/secp256k1/issues/1003 feel free to close
07:54 < sipa> the reason for having non-normalized numbers is just because the cost of normalization is nontrivial, and you can sometimes do multiple operations without them
07:56 < elichai2> andytoshi: Thank you for your contributions as a maintainer! :)
07:58 < elichai2> ha, so it's because each EC operations is dozens of field operations, while most protocols have only a handful of scalar operations then it's not worth it to optimize the scalars in the same manner
07:59 < sipa> elichai2: right
07:59 < sipa> also, more field-specific optimizations are possible, because the field modulus is far more structured
08:23 < sipa> but say, an ECDSA verification involves thousands of field ops, but only a few scalar ops
08:44 < roconnor> I think the fact that scalars are always normalized is the more relevent fact.
08:45 < roconnor> the way the field operations are used is to very carefully allow for non-normalized values that still manage to fit within the limb structures.
08:46 < roconnor> Though I suppose the ultimate reason for this is to make the operations fast by not doing field normalization everywhere.
08:56 < sipa> right, the magnitude reasoning is there because field elements are kept in (potentially) non-normalized representation
08:57 < sipa> and the reason why field elements aren't, but scalars are, always normalized is just because it's a lot of extra effort to make non-normalized representations work, and for scalars it's not worth it (both because their performance matters less, and because there is less to gain)
13:15 < sanket1729_> super basic question. Why is the infinity field in the libsecp256k1 represented as an int, when it is meant to only capture boolean values?  
13:15 < sanket1729_> for secp256k1_gej and secp256k1_ge
13:16 < sanket1729_> Is there some efficiency reason? Maybe it does not matter because of memory alignment?
13:19 < sipa> sanket1729_: C89 has no bool type :)
13:19 < sanket1729_> :) 
20:33 -!- gnusha [~gnusha@user/gnusha] has quit [Ping timeout: 264 seconds]
--- Log closed Thu Nov 04 00:00:23 2021