--- Day changed Thu Feb 01 2018
01:23 < andytoshi> i like this
01:23 < andytoshi> for some things i'll bet there's roconnor magic that could use coq to actually prove program equivalence. i bumped into him the other day and asked but he didn't have anything off the top of his head
01:23 < andytoshi> other than that he didn't want to think about it before checking the literature because this sounds solved :P
01:24 < gmaxwell> yes, thats a thing too-- but I don't think I'd want to skip just a dumb smt step, after all you might prove it equivient to a dumb program that admits trivial solutions.
01:24 < andytoshi> ah yeah, this is neat in that it'll also fuzz the program itself
03:09 -!- midnightmagic_ [~midnightm@unaffiliated/midnightmagic] has joined #secp256k1     
03:11 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 276 seconds]     
03:11 -!- nsh [~lol@wikipedia/nsh] has quit [Excess Flood]     
03:13 -!- nsh- [~lol@wikipedia/nsh] has joined #secp256k1     
03:21 -!- midnightmagic_ is now known as midnightmagic     
04:13 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]     
05:26 -!- nsh- is now known as nsh     
10:24 -!- hdevalence [~hdevalenc@52.119.117.17] has joined #secp256k1     
11:40 < gmaxwell> sipa: we have a small stack of obvious improvements for libsecp256k1 queued up, e.g. gitignore change, openssl forward/backwards compat thingy.
11:40 < gmaxwell> sipa: would you like me to start merging stuff?
11:40 < gmaxwell> 01:20:48 < kallewoof> I think at least gmaxwell doesn't think this function belongs there at all.
11:41 < gmaxwell> My comment about that is basically that we intentionally don't offer bare buildings blocks, but only "complete cryptosystems" becuase an objective for us is to only offer interfaces that are hard to misuse and you generally can't do that with a bare building block.
11:42 < gmaxwell> Having a combine that does musig like derandomization might be okay though.
11:43 < sipa> gmaxwell: i'll have a look soon
11:46 < gmaxwell> (and part of the argument for that is that our internal interfaces are VERY clean and simple, more so than most crypto libraries external interfaces... so if you want to do some custom crypto you can add a module yourself... and hopefully realize that what you're doing is potentially quite dangerous)
12:19 < gmaxwell> andytoshi: the bullet proof batch verify is an equals zero check, right?  e.g. we could merge it with batch signature verification?
12:20 < andytoshi> gmaxwell: yeah
12:20 < andytoshi> :P     
12:20 < andytoshi> i'll keep this in mind when i refactor the BP code, to make the batching more generic if i can
12:21 < andytoshi> (though the generator sharing makes it much harder to abstract this)
14:08 -!- hdevalence [~hdevalenc@52.119.117.17] has quit [Remote host closed the connection]     
18:31 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #secp256k1     
19:05 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has quit [Ping timeout: 246 seconds]     
19:05 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has joined #secp256k1     
19:20 < kallewoof> gmaxwell: without an interface for combining pubkeys how would it be used to combine pubkeys e.g. in bitcoin core, when musig etc. is in place? the musig doc talks about generating and sharing stuff with the other participants, which i assume will have to use combine-stuff (X^~ for one)
19:21 < sipa> kallewoof: right, there would be MuSig interface to libsecp256k1
19:21 < kallewoof> I guess there could be a higher level "MuSig take array of pubkeys and stuff and give back result" thing
19:22 < sipa> yes, exactly
19:22 < sipa> that would be much more efficient too
19:22 < sipa> as it could be implemented as a multiexp internally
19:23 < kallewoof> Not sure what a multiexp is, but yeah, I guess that makes more sense.
19:24 < sipa> kallewoof: computing a*A + b*B + c*C + ... (with a,b,c scalars and A,B,C points
19:24 < kallewoof> The interactive parts (e.g. sending R_i to participants) sounds like it needs at least two calls (one to make Rs and one to take them and do the musig thing) though?
19:24 < kallewoof> sipa: oh is that the thing you explained when you were here? I gotcha!
19:24 < sipa> yes, there are two interaction rounds
19:24 < sipa> kallewoof: indeed!
19:25 < kallewoof> ok, cool.. I look forward to seeing this. I actually understand the paper (so far.. up to chapter 3) which is a first for me.
19:25 < sipa> kallewoof: don't worry, i don't understand the rest either
19:26 < kallewoof> haha
19:46 < gmaxwell> by an interface for musig, yea, as sipa says.
20:30 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
20:32 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has joined #secp256k1     
22:08 -!- veleiro [~sleeper@fsf/member/veleiro] has quit [Quit: Leaving.]     
23:29 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #secp256k1     
23:34 -!- veleiro [~sleeper@fsf/member/veleiro] has quit [Ping timeout: 256 seconds]     
23:47 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #secp256k1     
23:57 -!- veleiro [~sleeper@fsf/member/veleiro] has left #secp256k1 []