--- Log opened Mon Sep 02 00:01:01 2019 07:58 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-qqsfqguftasufopd] has joined #secp256k1 09:05 < elichai2> Weird question, does the rest of the EC equation matter for the legendre/jacobi symbol? I mean when we check jacobi(x,p) does it give correct quad residue result for the full EC equation? (i.e.`y=+-sqrt(x^3+7)`) 09:11 * elichai2 facepalm 09:12 < elichai2> nvm. I need to finish my coffee before blabbing on IRC lol. obviously the symbol is checked on the full equation (on the *Y* not on the X.) 09:13 < elichai2> This sentence confused me `The function jacobi(x), where x is an integer, returns the Jacobi symbol of x / p. It is equal to x(p-1)/2 mod p (Euler's criterion)[6].` too much X's heh 09:17 < sipa> points don't have a jacobi symbol; only integers do 09:20 < elichai2> yes. but what we're trying to determine is, is the integer a quad residue in the function: `y^2 = x^3 + ax + b`. so it needs to be checked over a given y, to see if it's the quad residue of `sqrt(y^2)`. but nvm it's just the reuse of X that confused me for a sec 09:20 < sipa> so i don't understand the question :) 09:20 < sipa> oh right, the x there is no an x coordinate 09:20 < sipa> just a variable 09:20 < elichai2> yeah :) 09:21 < elichai2> it doesn't make sense to check quad residue over X coordinate. becuase we don't have anywhere a quad X to check if it's a residue of 09:28 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 09:28 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer] 09:29 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 09:29 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer] 09:30 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 09:31 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer] 09:31 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 09:36 < elichai2> andytoshi: have you read this by any chance? https://link.springer.com/chapter/10.1007/3-540-47719-5_33 (just found it lately, haven't had the chance to read it yet), if so is it interesting? worth reading? discuss solutions to the secure broadcast? 09:38 < sipa> elichai2: i've heard andytoshi and real_or_random talk about stinson & strobl, so i believe he has :) 09:39 < sipa> i haven't read it myself but i believe it's the paper that introduces threshold schnorr 09:39 < real_or_random> well yeah, we're aware of this 09:39 < real_or_random> I did a lot of reading and thinking on thresholds sigs in the past two weeks 09:40 < real_or_random> sipa: (it's actually introduced in another paper, stinson and strobel only provide a full write up of all the components) 09:40 < sipa> i see 09:41 < elichai2> real_or_random: me too :), do they really cover everything? 09:41 < real_or_random> they don't cover the broadcast, so if you're interested in that one, it's not worth reading 09:42 < elichai2> so basic VSS+schnorr but with distributed key generation so that the dealer doesn't have access to the full privkey? 09:43 < real_or_random> our simplest and best idea for broadcast so far is to run n-t+1 instances of some given scheme, using n-t+1 leaders 09:43 < real_or_random> with the leader implementing the broadcast. one leader will be honest, so that will work... it's just a blowup 09:45 < real_or_random> elichai2: it's VSS of secret key and VSS of nonce 09:45 < sipa> oh of the nonce as well? 09:46 < real_or_random> yes, this has a few advantages, e.g., you don't have to restart when someone drops out 09:47 < real_or_random> but let me stress that the entire situation is much more complicated. so all the schemes in the literature have a few weird assumptions and do weird things that are not reasonable in practice 09:47 < elichai2> honest leader is not fun :/. i'm still going through the literature but in theory with Musig combination every one is kind of a dealer, right? 09:47 < real_or_random> I've spend an afternoon with nickler discussing a lot of the stuff 09:48 < sipa> elichai2: at least one honest leader is easy :) 09:48 < real_or_random> sipa elichai2: you just need to be careful that the attacker can't forge if the broadcast is malicious. 09:49 < elichai2> at least one is a great thing :) the problem is that a lot of the papers suggest 1/2 honest or 1/3 honest :/, though I'm not sure about that yet. still reading, which is hard cause I'm also preparing for a talk in bitcoinedge :/ 09:49 < elichai2> who's coming to Scaling btw? 09:49 < real_or_random> as long as you need the honest leader/broadcast only to ensure proper termination, what I said above with the n-t+1 leaders should work 09:50 < real_or_random> if you want we could have a call and I can explain some of the stuff I figured out. it's just too much for IRC 09:51 < elichai2> would love to have a talk, but maybe after I finish writing my slides and also finish Pederson's VSS (still in the middle of the paper). 09:52 < sipa> elichai2: i'm not going to scaling 10:01 < real_or_random> yeah, let's do this 10:11 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 10:12 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 10:16 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 246 seconds] 10:44 < andytoshi> elichai2: i am going to scaling. i think i may be the only blockstreamer 10:47 < andytoshi> elichai2: i'm also getting in/out of israel pretty quickly ... it's pretty far away and wound up not fitting well into my travel schedule 12:22 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1 12:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 244 seconds] 12:44 -!- MrBusiness3 [~ArcMrBism@2600:6c58:4200:ad9:50dd:627b:a242:9770] has joined #secp256k1 12:47 -!- MrBismuth [~ArcMrBism@2600:6c58:4200:ad9:50dd:627b:a242:9770] has quit [Ping timeout: 264 seconds] 14:40 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds] 14:52 -!- reallll is now known as belcher 20:20 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 20:28 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 252 seconds] --- Log closed Tue Sep 03 00:01:00 2019