--- Log opened Wed Jun 30 00:00:52 2021
04:29 < real_or_random> after having written the CI stuff for testing on other platform, the way this can be done on rust is just impressive https://github.com/rust-bitcoin/rust-secp256k1/pull/317 https://github.com/rust-embedded/cross#usage
05:24 < elichai2> real_or_random: yeah cargo-cross is amazing. I've used it a lot to ease cross-compilation and generate binaries (as well as run tests)
06:38 -!- roconnor [~roconnor@host-192.252-165-177.dyn.295.ca] has quit [Ping timeout: 256 seconds]
08:36 -!- roconnor [~roconnor@host-45-58-197-229.dyn.295.ca] has joined #secp256k1
08:38 < roconnor> real_or_random: I was (and sort of still am) amazed that cross-compiling issues is even a thing.  As a theoretical computer scientist, I figured that surely compilers implement a pure function from source code to binary and just have a flag that says what architeture they should produce a binary for.
08:39 < sipa> roconnor: that part is the easy one, i think
08:39 < sipa> the hard part is that cross compiling requires the target environment to be available on the host
08:47 < roconnor> I mean, nothing I said so far requires that.
08:50 < sipa> at lesst system .h files in C differ based on the target environment
08:51 < sipa> if you could linking as part of compilation, the libraries you link with (even if they end up being shared libraries at runtime) also affect the build result
08:51 < sipa> then apply this recursively for all dependencies
08:52 < roconnor> Right, this is sort of where, from what I can tell, UNIX gets into a design whereby you cannot not even build software that will run on another computer at all, let alone another architecture.
08:53 < sipa> right, that's fair
08:53 < roconnor> Back in my day, every disk came with its own copy of the operating system.
08:54 < sipa> it is more a problem with building for other systems at all, that system being for another platform just worsens it
09:07 < real_or_random> one  issue is that GCC does not even make the easy part easy 
09:07 < real_or_random> I think it's better for clang
10:20 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
10:22 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
11:12 -!- belcher_ is now known as belcher
13:01 < nickler_> q
13:05 < sipa>     r
13:07 < nickler_> s :|
13:23 < gmaxwell> t
13:26 < roconnor> real_or_random: was it your intention to completely remove the execution of gen_pre_g from the make process, even with devtools enabled?
13:28 < gmaxwell> My understanding of the prior discussion is that there would be an additional make target, like "make tables"  which wouldn't run normally (e.g. not by make/make all).
13:29 < gmaxwell> But would be tested by CI by a check that makes sure the files in the tree are the same as the ones that get generated.
13:30 < roconnor> Right.  I think we want that, but it isn't what https://github.com/real-or-random/secp256k1/commits/static_ecmult_ctx_20210625 currently does.
13:31 < sipa> do we want to keep them generated using C code? i think there is some part of the codebase that's only used for context generation; replacing it with python code would simplify that even further
13:31 < sipa> (and in a setting where it's only performed explicitly by developers, the python dependency isn't an issue)
13:31 < roconnor> I'm not a cross compiling expert, but I don't understand why having a python toolchain on the host side is more likely than having a C compiler on the host side.
13:31 < sipa> that can be done as a follow-up off course
13:32 < sipa> the cross-compiling issue goes away with your approach already
13:32 < sipa> as there is no more cross-compilation involved for gen_pre_g
13:32 < roconnor> unless you want to both cross compile and increase the window size for some reason.
13:33 < gmaxwell> I don't have a strong opinion. I have a general opposition to language proliferation, but the table generation is so trivial that I don't think it matters.  I would say that maintaining the tool in C simplifies life for someone who did want to switch it back to runtime generation for whatever reason.  (or, e.g. for supporting other generators, etc)
13:37 < gmaxwell> I guess one point would be that the unit test I suggested wouldn't be cheap anymore: I suggested the tests just include the generation code, so they can test the the static table in memory is the same as the one the generation code builds.  ... but that is a not very useful test, and doesn't request functionally testing the tables.
13:38 < roconnor> gmaxwell: I've pushed some tests for the tables.  I chose to make the tests completely independent of how the table is generated.
13:38 < gmaxwell> There you go.
13:38 < roconnor> The testing code isn't quite as nice as I had imagined; however it is *very* different from how it is generated, so that aspect is good.
13:39 < roconnor> I think it is overall better this way, but that is, of course, subject to review.
13:39 < sipa> roconnor: have you seen https://github.com/bitcoin-core/secp256k1/pull/920 ?
13:39 < sipa> that was intended to increase coverage of precomputed tables
13:39 < roconnor> I don't think so.
13:40 < roconnor> You can review my tests, they way they work is that they check that (1) every point on the table is on curve through the is_valid function.
13:40 < sipa> oh, that's independently useful
13:41 < roconnor> (2) check that the points pre_g[i], -pre_g[i+1] and twice the generator are all distinct and colinear.
13:41 < roconnor> where "the generator" is pre_[0].
13:42 < roconnor> then there is a check that pre_g[0] is the expected value, either g or 2^128*g depending on which table we are talking about.
13:42 < gmaxwell> My long term goal was that the codebase be immune to mutation, that any simple modification that isn't functionally equivilent, will make the test fail... excepting changes like if(input=specific_256_bit_value){do_something_bad()}.  One of the things required to get there is that all constants need to be tested.
13:42 < sipa> #920 is just a whole bunch of EC multiplications of structured scalars with G, checked against known-correct results
13:44 < gmaxwell> So, e.g. #920 would be good, but since (IIRC) it's not guarenteed to check every table entry, it's not sufficient.  However, even if all table entries are tested, tests like #920 are important, because they won't need to be modified if the structure of the table changes.  Never good to only test with tests so tightly coupled that they must change when the implementation changes.
13:44 < sipa> right, agree
14:15 < roconnor> I've updated https://github.com/bitcoin-core/secp256k1/pull/956  Still a little bit of work to be done on the Makefile.
14:16 < roconnor> I guess the commit comments also need updating..
15:00 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has quit [Changing host]
15:00 -!- meshcollider [meshcollid@user/meshcollider] has joined #secp256k1
15:08 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Write error: Connection reset by peer]
15:09 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #secp256k1
15:56 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 265 seconds]
16:04 -!- ariard [~ariard@167.99.46.220] has joined #secp256k1
16:47 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
17:21 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
17:24 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
17:25 -!- roconnor_ [~roconnor@host-45-58-213-173.dyn.295.ca] has joined #secp256k1
17:25 -!- roconnor [~roconnor@host-45-58-197-229.dyn.295.ca] has quit [Ping timeout: 272 seconds]
17:27 -!- roconnor_ is now known as roconnor
18:27 -!- roconnor [~roconnor@host-45-58-213-173.dyn.295.ca] has quit [Ping timeout: 258 seconds]
21:12 < gmaxwell> https://phyro.github.io/grinvestigation/schnorr.html#schnorr-multi-sig  ... hasn't taken long for people to start publishing insecure multisig schemes.
--- Log closed Thu Jul 01 00:00:53 2021