--- Log opened Sat May 11 00:00:09 2019 05:54 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 05:55 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 07:05 < nickler> elichai2: doesn't exactly answer your question but I find myself looking up some of the computational techniques used in libsecp in Guide to Elliptic Curve Cryptography by Hankerson, Menezes and Vanstone. 07:05 < nickler> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.394.3037&rep=rep1&type=pdf 08:05 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-zyklzazkmhjxpdga] has joined #secp256k1 08:06 < elichai2> Making sure I understand correctly, if R isn't included in the hash of e the schnorr signature is easily forgeable, right? 08:07 < elichai2> (otherwise I can use the verification equation to calc the value of R using my own e and s) 08:14 < nickler> elichai2: yes 08:21 < elichai2> nickler: thanks. For a second I was scared how I can calc a working e with a preimage to a key that I don't own 10:29 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-zyklzazkmhjxpdga] has quit [Quit: Connection closed for inactivity] 12:16 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-yrtuhccqqjhpmaxd] has joined #secp256k1 12:18 < elichai2> So finished reading the musig paper and watching both Andrew's and Pieter's talks, the only thing I don't like is that because the coefficient is a hash than it's order dependent and all participants must agree on the order too 12:20 < sipa> must agree on the order? 12:21 < sipa> order of the group? 12:21 < elichai2> No order of the keys 12:21 < sipa> oh 12:21 < sipa> just sort them 12:21 < elichai2> You hash all the public keys and the index 12:22 < sipa> you determine the index of every key by seeing where it appeads after sorting the keys 12:23 < elichai2> Now I feel stupid lol. I'm going over all this math and didn't think of a simple sort lol 12:31 < elichai2> Although it's not that straight forward what's the right way to order public keys (which will agree with alla implementations) because it's a point, you can sort by saying x is more significant or y is, you can sort by first serializing(compressed or uncompressed?) and then viewing it as BE or LE and 12:32 < sipa> so the problem is reduced to agreeing on a sort order :) 12:38 < elichai2> Yes :) I'll look at Jonas's implementation to see what sort order he uses 14:46 < nickler> in the secp-zkp implementation there's no sorting. Ensuring that everyone agrees on an order is left to the implementor. But good point ... I'll check if it's mentioned in the doc that the given order is important. 14:50 < nickler> Regarding your earlier comment about hashing R, Dan Boneh's book "A graduate course in applied crypto" is a very good resource for understanding the security proofs of Schnorr signatures. 15:57 < gmaxwell> andytoshi: Thought on finishing PR600? I'd like to get it, 596, 595, and (a finished version of) 614 in relatively soon. 15:58 < gmaxwell> sipa: think we want to do the -fstack-reuse=none in libsecp256k1? I believe our use of strict ansi-c declariations before code actually make us safer with respect to it, but I'm betting stack reuse has essentially no benefit in our codebase either. 16:06 < andytoshi> oops! yeah, i should definitely finish that. maybe before monday .. though it's consensus week so i'm being pulled into (or hiding from) impromptu meetings 16:07 < gmaxwell> I don't know if there are other PRs (or not yet PRs) that impact the usability of the code on embedded devices. 16:11 < sipa> gmaxwell: or at least make the build inside core use it (though i guess we also want to test for it...) 16:17 -!- BlueMatt_ [~BlueMatt@ircb.bluematt.me] has left #secp256k1 [] 16:18 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has joined #secp256k1 16:18 -!- BlueMatt is now known as Guest88190 16:19 -!- Guest88190 [~BlueMatt@ircb.bluematt.me] has quit [Changing host] 16:19 -!- Guest88190 [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1 17:09 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-yrtuhccqqjhpmaxd] has quit [Quit: Connection closed for inactivity] 17:29 -!- Guest88190 [~BlueMatt@unaffiliated/bluematt] has quit [Read error: Connection reset by peer] 17:30 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1 18:42 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds] 18:43 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 264 seconds] 18:48 -!- Netsplit *.net <-> *.split quits: afk11, Madars, roasbeef, gmaxwell 18:58 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #secp256k1 19:45 -!- TD--Linux [~Thomas@kyoko.thomasdaede.com] has joined #secp256k1 19:45 -!- afk11 [~afk11@unaffiliated/afk11] has joined #secp256k1 19:45 -!- roasbeef [~root@104.131.26.124] has joined #secp256k1 19:45 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has joined #secp256k1 19:45 -!- Madars [~null@unaffiliated/madars] has joined #secp256k1 19:47 -!- TD--Linux [~Thomas@kyoko.thomasdaede.com] has quit [Changing host] 19:47 -!- TD--Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #secp256k1 19:47 -!- TD--Linux is now known as TD-Linux 19:57 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has quit [Remote host closed the connection] 20:06 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has joined #secp256k1 --- Log closed Sun May 12 00:00:10 2019