--- Log opened Mon Jan 06 00:00:58 2020
00:41 -!- meshcollider [meshcollid@209.141.50.204] has quit [Read error: error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac]
00:54 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-yykaxgczrolqfbhm] has joined #secp256k1
01:51 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
02:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
03:24 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #secp256k1
07:53 -!- jnewbery [~john@4.53.92.114] has joined #secp256k1
07:54 -!- jnewbery [~john@4.53.92.114] has quit [Quit: leaving]
--- Log closed Mon Jan 06 07:55:11 2020
--- Log opened Mon Jan 06 07:55:11 2020
08:12 -!- jnewbery [~john@4.53.92.114] has joined #secp256k1
08:35 < andytoshi> i'd like to thank everyone for being civil and constructive in the VRF PR discussion :)
08:38 < gmaxwell> any idea why the the 'ietf' construction uses the public key instead of the generator as an input in the hash to curve?
08:39 < gmaxwell> thats the biggest difference in the protocol between that and joinmarket's I think.
09:10 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]
09:11 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1
09:27 < elichai2> andytoshi: I was suprised by that :)
09:28 < elichai2> I now realized it was about VRF not VDF loool. now it all makes sense
09:28  * elichai2 facepalm
09:28 < gmaxwell> clearly I must have been too agressive, or otherwise no one would be thinking being civil was a problem
09:29 < gmaxwell> I also thought it was "VDF" at first an was very confused reading the IETF document.
09:29 < sipa> a pure EC based VDF would be cool :p
09:29 < elichai2> I read the thread from my phone so didn't read the doc. and i'm like "where are the class groups" lol
09:30 < gmaxwell> thats why I was clickly clicky. :P if I realized what it was I probably wouldn't have originally read the PR.
09:30 < gmaxwell> er issue
09:30 < andytoshi> haha i made the same mistake
09:31 < gmaxwell> and then when I realized what it was I thought, why would you even write a spec for this. :P -- not that they aren't useful, but the two couple times I had ideas that needed one I just described an appropriate one without ever considering it as a freestanding construct. :)
09:31 < andytoshi> my comment about civility was because the PR author did not understand crypto and also mentioned algorand :P
09:31 < gmaxwell> thats why In my post I wrote a description of the algorithim hopefully to save someone else the trouble of trying to figure out what it was.
09:32 < gmaxwell> andytoshi: At least he wasn't pumping that nonsense. :)
09:33 < elichai2> andytoshi: There was a cryptography conference at TLV university and half the talks were by Algorand :(
09:34 < gmaxwell> Any idea why something like that wouldn't just use a BLS signature as their VRF? (as in litterally, "use an ordinary BLS signature; a hash of signature is your random value")
09:35 < elichai2> maybe there are still sane people out there who aren't jumping on BLS without thinking? (becuase you can aggregateeee)
09:35 < gmaxwell> Well, I mean, it's a random function. I'd feel fairly safe using BLS to generate random numbers.
09:35 < gmaxwell> :P
09:36 < elichai2> hehe I guess
09:48 < elichai2> Everyone should just use this https://youtu.be/7A_rl-DAmUE verifiable by video :P
10:09 < real_or_random> well yes, so I think a VRF is a great and useful primitive, it's just not in scope
10:10 < real_or_random> but I wouldn't be surprised if tomorrow someone appears and proposes a very useful protocol that really needs a VRF
10:12 < real_or_random> and yep, VRFs and unique signatures are very related. VRFs are a little bit weaker though, because the "proof" that you computed the right value does not need to be unique
10:13 < real_or_random> and this seems to make a real difference here: we know how to build a VRF without pairings but we don't know how to build not a unique signature without pairings
10:14 < gmaxwell> real_or_random: applications for them sure-- we use on in bitcoin land, in fact https://joinmarket.me/blog/blog/poodle/  it's essentially that construction with a fixed 'message'.   an application for a generic function? less obvious to me.
10:14 < real_or_random> civil: I hope it was not harsh to close this only after a few hours. We unresolved issues very rarely...
10:14 < gmaxwell> real_or_random: RSA signatures are unique. :P (well depending on how you handle padding, and how you feel about chosen message attacks)
10:15 < gmaxwell> real_or_random: you did great as far as I'm concerned.
10:15 < real_or_random> maybe. when I say without padding, I mean on dlog and friends :p
10:16 < gmaxwell> without pairing.
10:16 < real_or_random> :X yes
10:16 < real_or_random> and sure, POODLE is related but in the end different
10:17 < real_or_random> s/We unresolved issues very rarely/We close unresolved issues very rarely
10:17 < real_or_random> I should really think before I type lo
10:18 < gmaxwell> real_or_random: I believe it's the same upto niggles about how things are serialized and that poodle has a constant message. (well a small set of messages)
10:19 < gmaxwell> for poodle I would have also recommended a BLS signature, but it was important for that application to use an actual bitcoin key. :)
10:20 < real_or_random> hm I need to think about this
11:07 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
11:32 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
11:43 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
13:08 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
16:33 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
20:07 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
20:07 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1
--- Log closed Tue Jan 07 00:01:02 2020