--- Day changed Sat Sep 05 2015
00:28 < sipa> oops, forget to remove branch
01:46 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1
05:33 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #secp256k1
07:02 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
08:14 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds]
09:21 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
09:37 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
09:42 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
10:38 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1
10:50 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
12:09 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]
12:17 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
12:36 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]
12:40 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
13:50 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds]
14:07 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 268 seconds]
14:08 -!- gmaxwell [greg@mf4-xiph.osuosl.org] has joined #secp256k1
14:08 -!- gmaxwell is now known as Guest65733
14:13 -!- Guest65733 [greg@mf4-xiph.osuosl.org] has quit [Changing host]
14:13 -!- Guest65733 [greg@wikimedia/KatWalsh/x-0001] has joined #secp256k1
14:13 -!- Guest65733 is now known as gmaxwell
17:28 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #secp256k1
18:06 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]
18:52 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #secp256k1
19:24 < phantomcircuit> sipa, was the schnorr batch validation code removed?
19:25 < phantomcircuit> i know it wasn't secure but it looks like it's just missing now
19:26 < andytoshi> is it just that it's behind a configure option now? (--enable-module-schnorr)
19:26 < gmaxwell> it's there.
19:27 < gmaxwell> uh I thought.
19:28 < gmaxwell> seems not.
19:28 < gmaxwell> multiparty signatures are still there.
19:32 < phantomcircuit> gmaxwell, i mean it seems like it shouldn't be in a release until the random number thing is implemented
19:32 < gmaxwell> I still want to figure out what Pippenger's algorithim looks like.  It appears that bos-coster might be ~20% faster (vague guestimate from counting group operations) than what pieter had implemented.
19:32 < phantomcircuit> which reminds me we should repeat our conversation about that
19:33 < phantomcircuit> i was thinking that using an actually random number was dangerous for consensus, but gmaxwell pointed out that it's equivalent to the risk from cached signature validations
19:34 < gmaxwell> phantomcircuit: yes, I repeated that in here already.
19:34 < phantomcircuit> ah ok
19:35 < gmaxwell> (According to DJB, et. al. Pippernger's algorithim is asymtoptically 2x faster; but I wasn't able to extract something I could implement from the 1970s (or whatever) paper on it.)
19:35 < gmaxwell> may require stupidly large batches to see much speedup however.
19:35 < phantomcircuit> gmaxwell, is there already rng input or is that something that would need to be supplied during the function call?
19:36 < gmaxwell> phantomcircuit: the batch verify function would need a secret input.
19:36 < gmaxwell> alternatively, a secret could be provided during context construction.
19:37 < gmaxwell> (I'm not aware of any reason the randomness would need to change across multiple verify calls; except to perhaps guard against an attacker that can view your memory)
19:39 < gmaxwell> oh okay, I just thought of a reason you'd want it to change per verify operation.
19:40 < gmaxwell> If bos-coster or pippernger's algorithims are used, the verify timing will leak substantial amounts of information about the blinding factors to an adaptive attacker who can submit lots of failing batches to you and time the results. though there are probably ways to harden against that without needing a random value per verify.
19:41 < phantomcircuit> gmaxwell, random value per verify should be super cheap though
19:41 < gmaxwell> e.g. generate the blinding factors with H(secret|signature).
19:41 < gmaxwell> phantomcircuit: yes, its just an api question.
19:41 < phantomcircuit> supply a seed for a prng at context creation
19:42 < phantomcircuit> and then have each batch verify use the prng
19:42 < phantomcircuit> csprng*
19:42 < gmaxwell> phantomcircuit: no that makes the context mutate on verification which means no concurrent use by multiple callers.
19:43 < phantomcircuit> gmaxwell, H(seed||signatures)
19:43 < phantomcircuit> ?
19:43 < phantomcircuit> oh
19:43 < phantomcircuit> ha you just suggested that
19:43 < gmaxwell> in fact if all the data that goes into the verify is hashed, then technically no randomness is needed.
19:44 < phantomcircuit> gmaxwell, that's what i was suggesting before
19:44 < gmaxwell> though we need to be mindful of the hashing costs.
19:45 < phantomcircuit> well... technically xor of the seed and the signatures should be safe
19:47 < phantomcircuit> but well yeah probably not a good idea
19:47  * gmaxwell gives phantomcircuit a job working on ethereum.
19:47 < phantomcircuit> gmaxwell, BUT ITS FASTER
19:48 < gmaxwell> Thats a bit underdefined, but I can pretty much promise that no version of that is safe. :)
19:48 < phantomcircuit> :P
19:48 < gmaxwell> for the same reason that ethereum using secret xor message_hash for nonces was very not safe.
19:52 < phantomcircuit> gmaxwell, lol they were using xor for the nonce?
19:52 < gmaxwell> they were using secretkey xor message_hash, yes.
19:53 < gmaxwell> This was somewhat our fault: we required the caller to provide a secure nonce.
19:53 < gmaxwell> We knew that most users lacked the low level cryptographic understanding to do this competently, and we predicted this kind of failure.
19:54 < gmaxwell> We also changed the interface so that they not only weren't required to, but couldn't just provide a nonce.  Unfortunately they were using some go-secp256k1 library that had an old fork of our repo.
19:55 < gmaxwell> So yea, sure it's fun the poke fun at ethereum, but really I think the mistake was ultimately ours. To our defense we predicted it and fixed it before knowing that it caught anyone, and our library is explicitly pre-release with huge warnings on it.
19:55 < phantomcircuit> that certainly makes it their fault
19:55 < phantomcircuit> using a pre-release crypto library in production is pretty obviously a bad idea
19:56 < gmaxwell> I don't know about that. Life is complicated. We know lots of people have been using libsecp256k1 in production though we've warned against it.
19:56 < gmaxwell> And _we_ use it in production in bitcoin core; though we think its safer for us to do because .. having written it and all..
19:57 < gmaxwell> Ultimately our responsibility is to not make changes to the state of the universe which cause harm to others, especially not when we could have predicted and prevented it.
19:58 < gmaxwell> Putting up a bunch of warnings might let us shift /blame/ but if we could have known that it would have happened anyways, then I think the fault must still be ours.
19:58 < gmaxwell> I don't really see an alternative, we couldn't have realistically kept the library secret until it was done.
19:59 < gmaxwell> Esp since we wouldn't have recieved the insanely valuable contributions of Dettman, and the help of many others that made the interface and build systems mature and highly usable.
20:00 < gmaxwell> So I don't think me saying it was ultimately our fault is a bad mark, but its a lesson we can learn from, at least a little. And learning from it is important.
20:00 < gmaxwell> (Though I think mostly what we learned was something we knew-- users won't listen to warnings, and users will misuse interfaces if its easier to do so than to use them safely.)
20:01 < gmaxwell> I guess the best lesson is that the time for safe interfaces is now, not later.
20:02 < phantomcircuit> gmaxwell, fair enough
20:03 < gmaxwell> Vaguely related, I highly recommend this very long comic about having sympathy for the harm we inevitably create on the road to progress: http://www.viruscomix.com/page588.html
20:14 < gmaxwell> (Also, to those who read that comic-- most miss that the adult woman in the non-past scenes is the speakers daughter, and the varrious other implications of that)
20:24 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
20:26 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
22:13 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]
22:53 < gmaxwell> This sounds useful: https://software.intel.com/en-us/articles/intel-architecture-code-analyzer/
22:54 < gmaxwell> Given a code chunk it finds instructions that stall the pipeline and such.
22:57 < midnightmagic> There's stuff like that for AMD arch too.
23:04 < midnightmagic> It works well in combination with machines that have their GPU installed. It was clean and worked well the last time I used it, which admittedly was a couple years ago.
23:05 < gmaxwell> it's easy to use
23:05 < gmaxwell> https://people.xiph.org/~greg/x86_64_asm_fmul_latency.png
23:06 < gmaxwell> http://0bin.net/paste/EXBDYsT8oUHfrqBn#65Q0i7PPRHQYVhQ9NiVCbxOpoTaQk2sbOHVzWJi9qUk
23:07 < gmaxwell> I appears to suggest that we could potentially get a 5% speedup on our x86_64 fmul inner if we're able to eliminate all the stalls on the critical path.
23:08 < gmaxwell> er, it not I.
23:08 < gmaxwell> I have no idea. I am just a button pushing monkey.
23:18 < midnightmagic> Whoah dude, all that time ago, I stopped reading that comic right before the gutpunch line.