--- Log opened Thu May 23 00:00:21 2019
02:53 < gmaxwell> real_or_random: Thanks for picking up that PR activity and for the report on memcpy. Do you actually get a santizer report on it?  Valgrind is clean on the tests for me right now.
05:44 < real_or_random> gmaxwell: I was just reading the code
05:46 < real_or_random> this should not be an issue at the moment because hopefully `len_der != len_der_lax` holds
05:46 < real_or_random> ehm `len_der == len_der_lax` holds
05:47 < real_or_random> the thing is ... if it didn't hold (and the test is supposed to test this), then we'd run into UB before we fail
05:49 < real_or_random> it's really a minor issue but I wanted to write it down somewhere
05:51 < gmaxwell> yeah makes sense. I didn't even look in detail, I was just concerned that the existing instrumentation wasn't catching something.
11:51 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 245 seconds]
11:51 -!- gmaxwell [gmaxwell@mf4-xiph.osuosl.org] has joined #secp256k1
11:52 -!- gmaxwell is now known as Guest58856
12:24 -!- Guest58856 [gmaxwell@mf4-xiph.osuosl.org] has quit [Changing host]
12:24 -!- Guest58856 [gmaxwell@wikimedia/KatWalsh/x-0001] has joined #secp256k1
12:24 < Guest58856> andytoshi: https://eprint.iacr.org/2019/550.pdf  ZKP in plain DL, with sublinear verification cost (in particular they can achieve sqrt verifier operations and sqrt communication)
12:28 -!- Guest58856 is now known as gmaxwell
12:39 < andytoshi> yeah, i still haven't read it
12:39 < andytoshi> is it limited to sqrt? the asymptotics seem to suggest i can jack this `c` parameter all the way up
12:39 < andytoshi> and get basically constant size
12:39 < andytoshi> \verify time
12:41 < sipa> it looks like there's a tradeoff between size and verification time such that the product of the two is linear in the size of the proof
12:42 < sipa> but verification time is at least sqrt(n)
12:44 < gmaxwell> what sipa said.
12:44 < gmaxwell> you can also get a log() sized proof with n time-- basically back to bulletproofs.
12:45 < sipa> c > 2 looks much less interesting (you get n^(1/3) proof size, but n^(2/3) validation time)
12:46 < gmaxwell> thats why I only mentioned the c=2 case. :)
12:47 < andytoshi> yeah, i skimmed it and thought i could get c < 2, and got very exciting
13:11 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #secp256k1
13:17 < gmaxwell> So, ccomp says: Stuck state: calling memmove(<ptr>, <ptr>, 41LL)
13:21 < gmaxwell> which is complaining about memmove(ptr+pos,ptr+pos+1,len-pos-1)  basically moving the tail end of a char arry one byte back.
13:21 < gmaxwell> since when is memmove not allowed to overlap?
13:57 < real_or_random> gmaxwell: no, you need to implement memmove :P
13:57 < real_or_random> it's a call to an undefined function. this is UB :P
13:58 < gmaxwell> ooohhhh! lol
14:02 < real_or_random> (I was confused too by "UB" in memcpy and memcmp at first...)
16:15 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Quit: gone]
17:54 < gmaxwell> sipa: so should bip-schnorr be changed to 32 byte public keys?
17:58 < sipa> gmaxwell: i'm not sure we want to do it at the bip-schnorr level or in bip-taproot
17:59 < sipa> because higher-level constructions will still want to work with points that have a well-defined Y coordinate
18:00 < sipa> having a distinction between public keys and points is of course possible, but maybe more confusing; i don't know
18:02 < gmaxwell> Maybe bip-schnorr could define a verifier that can take a 32-byte pubkey?
18:03 < gmaxwell> One thing that comes to mind is that if our scheme doesn't make it easy to "unwrap" a 32 byte pubkey into a 33 byte one, so that an unmodified bip-schnorr verifier can handle it... that is suboptimal.
18:04 < sipa> you mean if we'd use quadratic residue?
18:04 < sipa> i think it's easier to just use even Y as tiebreaker for public keys
18:04 < gmaxwell> Or really anything other than "first byte of the 33byte rep is always 0x02 if it's 32 bytes"
18:05 < sipa> the quadratic residue tiebreaker makes sense for R, as there are operations on it in jacobian coordinates
18:05 < sipa> but public keys are always known in affine form
18:06 < gmaxwell> I think thats correct (though, we should take care to think through S2C and the delinearization in batching)
18:26 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 252 seconds]
18:26 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1
20:28 -!- instagibbs_ [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 258 seconds]
--- Log closed Fri May 24 00:00:22 2019