--- Day changed Wed Jan 31 2018
00:34 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 248 seconds]     
00:36 -!- nickler [~nickler@185.12.46.130] has joined #secp256k1     
00:59 < kallewoof> gmaxwell: (regarding secp256k1_ec_pubkey_combine) it's handy when trying out taproot in btcdeb. https://twitter.com/kallewoof/status/958608464577626113
01:14 < andytoshi> heh, this is exactly where that function is dangerious
01:17 < kallewoof> Good point. No alternatives at the moment, though..
01:19 < andytoshi> true, unfortunately
01:19 < andytoshi> i think we should rewrite pubkey_combine to use the musig derandomization so there's a safe go-to for people who want to do this
01:20 < andytoshi> sipa: gmaxwell: thoughts?
01:20 < kallewoof> I think at least gmaxwell doesn't think this function belongs there at all. gmaxwell> it was part of the schnorr code and we forgot to strip it when we removed it.
01:26 < andytoshi> yes, and i agree with that, except that pubkey_combine has been around for a long time and now people are using it..
01:29 < andytoshi> whew, my bulletproof prover is _really_ slow. like 47ms for a 64-bit proof. (verification is 2.6ms)
01:30 < andytoshi> i had estimated a factor 2 slowdown from my bing stupid about the prover, but maybe there's a larger factor
01:30 < kallewoof> Are they? It's completely insecure, though. (I mean, I use it in btcdeb but only for experimenting.)
01:31 < andytoshi> hm maybe not actually, without multisig code anywhere that function is basically useless..
01:36 < kallewoof> Only actual use I can find is jl777 on bitcointalk but he's talking about schnorr stuff. https://bitcointalk.org/index.php?topic=1372916.0
02:33 < waxwing> i used it (combine) but i'd have to check, i guess i could be using the tweak function (in podle/dleq at least)
03:27 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #secp256k1     
03:47 < andytoshi> is the suspected patent on the endomorphism expired? whan?
03:47 < andytoshi> when
14:05 -!- hdevalence [~hdevalenc@52.119.117.17] has joined #secp256k1     
14:38 < gmaxwell> I was thinking some about the challenge of taking ZKP for arbritary circuits into production.  One major issue is that its astonishingly difficulty to tell if your circuit is under-constrained... where you've forgoten some constraint someplace and now there is a place people can inject values and trivially make true proofs.
14:39 < gmaxwell> as soon as the circuit is anything but trivial complexity its very hard to review by eye to make sure all the constraints hold.
14:39 < gmaxwell> And simple checks like fuzzing inputs really only works for the worst cases of underconstraint, e.g. an input being left unwired.
14:39 < gmaxwell> So one thought I had was this, we should be able to take the bulletproof matrix format and convert it to the input for an SMT solver.
14:40 < gmaxwell> It should be unable to satisify it on its own for any actually-interesting ZKP but be able to solve it if you give it 99% of the answer by fixing some of the secret inputs, or be able to solve gimped versions (one round sha2, for example), or be able to solve it if we drop out some constraints.
14:41 < gmaxwell> certantly it won't prove something secure but I think it would catch a much wider class of errors than we can catch otherwise.
18:08 -!- hdevalence [~hdevalenc@52.119.117.17] has quit [Quit: hdevalence]     
18:58 -!- sipa [~pw@2001:19f0:ac01:2fb:5400:ff:fe5b:c3ff] has joined #secp256k1