--- Log opened Tue Jun 16 00:00:53 2020
00:03 -!- jonatack [~jon@185.206.225.51] has joined #secp256k1
00:03 -!- jonatack [~jon@185.206.225.51] has quit [Read error: Connection reset by peer]
00:09 -!- jonatack [~jon@37.166.203.124] has joined #secp256k1
00:23 -!- jonatack_ [~jon@37.164.151.149] has joined #secp256k1
00:27 -!- jonatack [~jon@37.166.203.124] has quit [Ping timeout: 260 seconds]
01:49 -!- jonatack_ [~jon@37.164.151.149] has quit [Ping timeout: 258 seconds]
02:01 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
02:07 -!- jonatack [~jon@37.164.151.149] has joined #secp256k1
02:44 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
02:49 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
03:36 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-yvsarhdonpbbrarj] has quit [Ping timeout: 256 seconds]
03:38 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-qyjrcajygahqozgu] has joined #secp256k1
03:47 -!- jonatack [~jon@37.164.151.149] has quit [Ping timeout: 260 seconds]
04:26 -!- jonatack [~jon@37.164.151.149] has joined #secp256k1
04:31 -!- jonatack [~jon@37.164.151.149] has quit [Ping timeout: 256 seconds]
04:32 -!- jonatack [~jon@134.19.179.235] has joined #secp256k1
06:42 -!- jonatack [~jon@134.19.179.235] has quit [Read error: Connection reset by peer]
07:12 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
07:14 -!- Apocalyptic_ [~Apocalypt@unaffiliated/apocalyptic] has joined #secp256k1
07:16 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Quit: Quit]
07:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]
07:16 -!- Apocalyptic_ is now known as Apocalyptic
07:16 -!- CodeShark___ [sid126576@gateway/web/irccloud.com/x-bsuypremvluwtcpt] has quit [Ping timeout: 256 seconds]
07:17 -!- lukedashjr is now known as luke-jr
07:18 -!- CodeShark___ [sid126576@gateway/web/irccloud.com/x-gplexnieuwjdwore] has joined #secp256k1
09:24 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #secp256k1
11:38 -!- gmaxwell [~procyonid@wikimedia/KatWalsh/x-0001] has joined #secp256k1
11:41 < gmaxwell> real_or_random: is that a paper that says that shortened hashes are okay for RO+GGM or something like that? (and has the problem that the result is insecure against 'self-forgery')
11:41 < sipa> gmaxwell: indeed
11:41 < sipa> actually not even RO
11:42 < sipa> but variants of preimage and collision resistance
11:42 < gmaxwell> right, CRH. ! vaguely remember now.
11:42 < sipa> rpp and rpsp
11:42 < sipa> random prefix preimage resistance and random prefix second-preimage resistance
11:44 < gmaxwell> also short hashes bust batch validation.
11:45 < sipa> yup
11:46 < gmaxwell> 'secure'
11:47 < gmaxwell> and for 128 bits it's actually computationally tractable to do that.
11:48 < sipa> yup
11:50 < gmaxwell> also, for catching up when you've been offline.
11:50 < gmaxwell> there is also a speedup for single big transactions but it's not that huge.
11:52 < gmaxwell> the fact that it makes it weak to self-forgery is really the killer IMO. if it werent' for that it might be worth it.
11:54 < gmaxwell> yep no caching in blocks only.
11:54 < gmaxwell> but also single txn have an average of what .. 4 signatures? batch is still a speedup there, just a much smaller one.
11:54 < elichai2> which of the papers did you mean (with regards to ECDSA proof) this https://hss-opus.ub.ruhr-uni-bochum.de/opus4/frontdoor/deliver/index/docId/6080/file/diss.pdf or this? http://library.usc.edu.ph/ACM/SIGSAC%202017/ccs/p1651.pdf
11:56 < gmaxwell> elichai2: http://www.neven.org/papers/schnorr.pdf is the paper we were talking about.
11:56 < gmaxwell> I believe.
11:57 < sipa> indeed, that one
11:57 < elichai2> gmaxwell: I meant earlier when sipa talked about the proof for ECDSA assuming some properties on the point coordinates
11:57 < sipa> ah
11:57 < sipa> https://nbn-resolving.de/urn:nbn:de:hbz:294-60803
11:58 < elichai2> yeah that links to my first link via the `Dissertation`, but someone just sent me the other one in response so I thought maybe I'm wrong (they're both written by the same author (diff in co-authors hehe))
12:00 < gmaxwell> yeah the difference is at most two finite field operations total. (a negation on the pubkey, and a negation of the resulting secret)
12:00 < sipa> indeed
12:01 < sipa> but the reason is because you can use the structure of negation (and its efficient homomorphism) already, even when computing DL of a full pubkey
12:01 < sipa> otherwise the difference between the two would be more than additive term
12:02 < gmaxwell> real_or_random: FWIW, a new world record ecdl breaking was just achieved on bitcointalk. https://bitcointalk.org/index.php?topic=5244940.msg54628409#msg54628409
12:02 < gmaxwell> (they solved a 114 bit DL problem in secp256k1)
12:03 < gmaxwell> sipa: the change was the syntehtic nonce priority and putting the pubkey in.
12:04 < sipa> sure, but there was a huge discussion about the exact scheme, and i don't remember all details there
12:04 < gmaxwell> feel free to talk about the motivations! refer people to the bip for the order.
12:04 < gmaxwell> it's actually an interesting point that you don't remember the exact order, because it's kind of minutia.
12:08 < gmaxwell> sipa: might want to mention these schemes are non-normative.
12:08 < gmaxwell> it's just important to have a good recommendation
12:08 < gmaxwell> BIP340
12:08 < gmaxwell> If you let people "choose a random nonce" we know they do it poorly.
12:09 < gmaxwell> e.g. early version of libsecp256k1 did that, and then ethereum made it privkey xor message.
12:09 < gmaxwell> The application writer isn't a cryptographer 99% of the time.
12:11 < gmaxwell> pretty close to what I wrote!
12:13 < waxwing> join next time gmaxwell :)
12:14 < gmaxwell> meh.
12:15 < gmaxwell> I mean no harm in using synthetic nonces.  At least recommending synthetic nonces makes someone who implements musig incorrectly a little more likely to be safe in practice. :P
12:15 < sipa> unless they reuse the very carefully synthetic nonce across sessions :p
12:16 < real_or_random> hey, now reading here too
12:16 < gmaxwell> waxwing: that would require I get dressed. not worth it. :P
12:17 < real_or_random> sipa: you were right of course with the x-only reduction
12:18 < real_or_random> it just adds two negation to the running time
12:19 < gmaxwell> sipa: it can be merged without activation (and probably should be if its waiting on that!)
12:19 < gmaxwell> just like bip32 was in the codebase for like 5 years before it was used. :P
12:19 < sipa> of course
12:20 < gmaxwell> I think just batch was removed.
12:21 < gmaxwell> Batch verification also requires structural changes in bitcoin validation. (esp to get more than trivial gains)
12:21 < sipa> and the keypair type added
12:21 < real_or_random> yep
12:21 < real_or_random> gmaxwell: you should start a twich stream commenting the call and see if its get more viewers than the yt stream
12:21 < sipa> wahaha
12:22 < gmaxwell> Who's speaking right now?
12:22 < waxwing> heckling stream. PogChamp.
12:23 < gmaxwell> waxwing: you've never seen heckling unless you've done IETF meetings.
12:24 < gmaxwell> ITS ALSO FAAST.  oh well. :P
12:26 < gmaxwell> it's weird to be a speaker in the IETF big room with 1500 people, all on laptops and 80% in the heckling channel, and then most of the audience laughs at a random time because of some sick burn in the heckling room.
12:26 < sipa> elichai2: aaaargh
12:26 < gmaxwell> thats elichai2 talking?
12:26 < elichai2> yeah
12:26 < sipa> yes
12:27 < elichai2> I hope no one would get angry on me bashing parity lol
12:27 < sipa> i doubt that :p
12:28  * gmaxwell #include <standard_grumble_about_rust_crypto_reimplementations_all_sucking.h>
12:29 < sipa> i think that applies that pretty much *re* implementations of cryptography is most languages :)
12:29 < gmaxwell> yeah absolutely, it's just rewriting things in rust is a big fad now.
12:29 < elichai2> gmaxwell: I do believe the problem is mainly with developers not familiar with cryptography just translating without understanding, not a problem with rust in particular :)
12:29 < elichai2> yep
12:29 < gmaxwell> Javascript too, but it's bad for everything not just reimplementations. :P
12:31 < elichai2> I think that after C Rust is the next best language for cryptography, although even there there it's easy to misuse language features in ways that create footguns (similar problem to crypto in C++)
12:31 < gmaxwell> I think opensource in general has a common problem with people reimplementing needlessly (and doing a bad job, because transliterating feels easy but doesn't actually result in correct software),  but the introduction of new languages makes it worse because it gives people an excuse. :)
12:31 < elichai2> definitely :)
12:33 < gmaxwell> C just has a wealth of tools for formal analysis (e.g. compcert formalism, frama-c, etc) that is probably >10 years off for rust, if ever. Also things like libsecp256k1 are small and simple enough that there is propect of using these tools.
12:34 < gmaxwell> so you get real results like roconnor being able to prove a simplicity ECC validation implementation is exactly equal to 32-bit libsecp256k1.
12:35 < elichai2> if you really want formality you can use fiat-crypto and friends
12:35 < gmaxwell> lol
12:35 < gmaxwell> good luck with that.
12:36 < sipa> fiat-crypto is very cool, but its secp256k1 code is not efficient :)
12:36 < elichai2> yeah, I opened an issue for them, their API suckss
12:36 < elichai2> I wanted to do cross tests for the field and scalar operations
12:36 < gmaxwell> It's cool but it's narrow.
12:38 < gmaxwell> huh did elements drop schnorr signatures?
12:38 < gmaxwell> it was a launch feature.
12:38 < sipa> yes
12:38 < gmaxwell> real_or_random: you're wrong. :P
12:38 < gmaxwell> it's an older variation
12:38 < gmaxwell> right.
12:38 < real_or_random> but then I'm right :P
12:39 < gmaxwell> OH okay.
12:39 < elichai2> so what are all the cryptographers in blockstream do in their day to day? lol, (just curious)
12:39 < gmaxwell> well the CT proofs are an e,s schorr signtature too. :P
12:40 < sipa> ha, good point
12:41 < elichai2> (I always assumed there's a lot of work on Elements/Liquid)
12:42 < gmaxwell> I reconize waxwing's voice.
12:42 < gmaxwell> ?
12:42 < real_or_random> yep
12:43 < gmaxwell> ECDSA would have this problem too but it would be an multiplicative alternative to bip32, no?
12:43 < sipa> indeed
12:52 < gmaxwell> sipa: real_or_random: good talk!
13:14 < gmaxwell> sipa: so 1 bit per element savings starts at a range of 14, which would allow a smaller table.
13:14 < gmaxwell> about half the size.
13:15 < sipa> gmaxwell: wrong channel?
13:15 < gmaxwell> oops
13:50 -!- harding [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
13:52 -!- harding [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has joined #secp256k1
14:30 -!- gmaxwell [~procyonid@wikimedia/KatWalsh/x-0001] has left #secp256k1 []
15:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
15:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
15:34 -!- Netsplit *.net <-> *.split quits: luke-jr, CodeShark___, dkrm, lightningbot, Cory, meshcollider, TD-Linux, wallet42, stackingcore21_, niftynei,  (+33 more, use /NETSPLIT to show all of them)
15:37 -!- Netsplit over, joins: GAit, waxwing, Lightsword, jnewbery, elichai2, nsh, stackingcore21_
15:37 -!- Netsplit over, joins: BlueMatt, TD-Linux
15:37 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-ncldrsilsbytwleo] has quit [Ping timeout: 265 seconds]
15:37 -!- Netsplit over, joins: Cory, ariard, midnight, andytoshi, jonatack, felixweis, dkrm, dongcarl, belcher, luke-jr (+1 more)
15:38 -!- Netsplit over, joins: instagibbs, RubenSomsen, kcalvinalvin, aj, real_or_random
15:38 -!- Netsplit over, joins: kanzure
15:38 -!- Netsplit over, joins: jonasschnelli, lightningbot
15:38 -!- Netsplit over, joins: fjahr, zmanian_, Madars, ensign_
15:38 -!- Netsplit over, joins: sipa, afk11`
15:39 -!- Netsplit over, joins: harding, meshcollider, digi_james, windsok, kallewoof, CodeShark___, wallet42, cfields
15:39 -!- stackingcore21_ [~stackingc@157.230.135.166] has quit [Read error: Connection reset by peer]
15:40 -!- stackingcore21 [~stackingc@2604:a880:2:d0::1bda:1001] has joined #secp256k1
15:41 -!- digi_james [sid281632@gateway/web/irccloud.com/x-doxceqxpvlfgpgsj] has quit [Ping timeout: 260 seconds]
15:41 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-ozlyifiugrtfpnrc] has quit [Ping timeout: 256 seconds]
15:42 -!- digi_james [sid281632@gateway/web/irccloud.com/x-fjepoohrzcwjyqay] has joined #secp256k1
15:42 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #secp256k1
15:43 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-rsypnxenjsanfspo] has joined #secp256k1
15:44 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-axwjvfwwthppwdgd] has joined #secp256k1
16:10 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
16:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
16:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
17:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
17:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
--- Log closed Wed Jun 17 00:00:53 2020