--- Day changed Sat Jul 09 2016
02:13 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 252 seconds]
02:22 -!- afk11 [~afk11@109.255.154.81] has joined #secp256k1
02:22 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
02:22 -!- afk11 [~afk11@unaffiliated/afk11] has joined #secp256k1
02:37 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 258 seconds]
02:43 -!- afk11 [~afk11@109.255.154.81] has joined #secp256k1
02:43 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
02:43 -!- afk11 [~afk11@unaffiliated/afk11] has joined #secp256k1
04:41 < gmaxwell> lol
04:41 < sipa> ?
04:42 < gmaxwell> so I was reading andrews exaustive test patch backwards, and solve_discrete_log function name made me respond
04:42 < gmaxwell> /* hee hee hee */
04:42 < sipa> hahah
04:42 < gmaxwell> so I think the comment is apt.
04:43 < sipa> i don't see that comment?
04:43 < gmaxwell> https://github.com/bitcoin-core/secp256k1/pull/310/commits/e6c659fbe05f341012bf761930477f0aaafb3409#diff-e7c9e609b20b2ebe6eef2ed115fc4676R179
04:44 < sipa> oh, it's removed in a later commiut
04:48 < gmaxwell> funny that andrew observes that ECDSA (nor effectively schnorr as its usually constructed) are zero knoweldge. (except for curves of trace 1)
04:49 < gmaxwell> (supersingular curves, I guess)
05:01 < andytoshi> sipa: yeah, sadly i removed it because it did not do exactly what i wanted. it would learn a k value from a r value
05:01 < andytoshi> but there are multiple k's per r .. which is part of why ecdsa is not zero knowledge
05:03 < andytoshi> the more general reason is that scalars and field values have different ranges, so there are multiple R.x values that give the same r
05:03 < sipa> is there a faster modular square root than the power ladder?
05:04 < sipa> if allowed to be variable time
05:04 < andytoshi> gmaxwell: does schnorr fail to be 0knowledge because it uses a 256-bit hash as a scalar?
05:06 < gmaxwell> andytoshi: yea, since the hash isn't perfectly to the group order.
05:08 < andytoshi> gotcha. it's frustrating, i really wanted that to be able to test that.
05:09 < sipa> i think for p=3mod4, the fastest algorithm is indeed just the power ladder for sqrt?
05:10 < andytoshi> it's the _only_ algorithm i know of, sorry
05:11 < sipa> apart from exhaustive search, i guess
05:11 < andytoshi> hah, yeah
06:04 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #secp256k1
06:07 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 276 seconds]
06:14 -!- arubi_ is now known as arubi
06:27 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]
06:28 -!- arubi [~ese168@unaffiliated/arubi] has joined #secp256k1
06:47 -!- fifth_ [~fifth@80.215.178.37] has quit [Ping timeout: 258 seconds]
09:51 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #secp256k1
10:46 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds]
15:31 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has quit [Ping timeout: 246 seconds]
16:10 -!- aburan28 [~androirc@static-108-45-93-74.washdc.fios.verizon.net] has joined #secp256k1
16:51 -!- aburan28 [~androirc@static-108-45-93-74.washdc.fios.verizon.net] has quit [Read error: Connection reset by peer]
17:35 -!- aburan [~androirc@static-108-45-93-74.washdc.fios.verizon.net] has joined #secp256k1
17:41 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #secp256k1
19:16 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has joined #secp256k1
19:49 -!- aburan [~androirc@static-108-45-93-74.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]
19:49 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has quit [Quit: Leaving.]
22:00 -!- Netsplit *.net <-> *.split quits: TD-Linux, sipa, luke-jr
23:35 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 272 seconds]
23:44 -!- arubi [~ese168@unaffiliated/arubi] has joined #secp256k1
23:49 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 252 seconds]