--- Log opened Wed Oct 17 00:00:39 2018 00:02 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 00:02 -!- echonaut14 [~echonaut@46.101.192.134] has joined #secp256k1 00:05 -!- lexyon [uid324840@gateway/web/irccloud.com/x-ypwyqmjrksgwjvvf] has joined #secp256k1 00:08 -!- instagibbs [~instagibb@pool-100-15-136-249.washdc.fios.verizon.net] has quit [Ping timeout: 250 seconds] 01:28 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #secp256k1 01:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 01:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 01:54 -!- deusexbeer [~deusexbee@080-250-075-064-dynamic-pool-adsl.wbt.ru] has joined #secp256k1 01:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 01:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 02:32 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds] 02:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 276 seconds] 02:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 06:22 -!- lexyon [uid324840@gateway/web/irccloud.com/x-ypwyqmjrksgwjvvf] has quit [Quit: Connection closed for inactivity] 06:34 -!- ken2812221 [~ken281222@110.50.135.178] has joined #secp256k1 07:34 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 256 seconds] 07:36 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 256 seconds] 07:38 -!- harding_ [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has joined #secp256k1 07:49 -!- Netsplit *.net <-> *.split quits: Taek 07:50 -!- Netsplit *.net <-> *.split quits: harding 08:32 -!- deusexbeer [~deusexbee@080-250-075-064-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!] 08:33 -!- deusexbeer [~deusexbee@080-250-075-064-dynamic-pool-adsl.wbt.ru] has joined #secp256k1 09:24 -!- Taek [~quassel@2001:41d0:1:472e::] has joined #secp256k1 09:56 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 09:58 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1 11:36 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 256 seconds] 11:36 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1 12:21 < sipa> gmaxwell: can you review #553 and #557? 12:26 < sipa> andytoshi: in #557, can you add a test that secp256k1_ge_set_all_gej_var works correctly when some of the inputs are infinity? 12:31 < andytoshi> yep sure 12:32 < sipa> it seems a significant part of the new function's complexity is dealing correctly with infinity, so we better test it 12:32 < andytoshi> fwiw the existing tests have the first point be infinity 12:32 < sipa> oh 12:32 < andytoshi> all the `4 * runs + 1` stuff is +1 because it adds this extra infinity 12:33 < andytoshi> but i can add a better test that makes half the points be infinite or someting 12:33 < sipa> yeah 12:34 < sipa> oh yes, gej is this special 17 element array with various amounts of crazy relations between them 12:35 < andytoshi> yeah, that test is really hard to read :P 12:36 < andytoshi> and infuriating to modify .. i think i had an earlier version that did break infinity, and i re-added the infinity logic because that was easier than changing the test 12:36 < andytoshi> because i think our only use of that function is for initializing the context, which i think involves no infinities 12:53 < andytoshi> added a unit test, confirmed that it passes (and that it's being run :)). running in valgrind now 13:32 < gmaxwell> But did you confirm that it fails if you break infinity handling? 13:33 < andytoshi> ah, no, one sec 13:34 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1 13:35 < andytoshi> yep, it fails if i remove the infinity check 13:35 < andytoshi> the first 2 of the 3 infinity checks -- the last one is just an efficiency thing 13:36 < andytoshi> also fails if i remove the infinity-setting line 14:01 < andytoshi> this has a very different writing style from the original tom jedusor paper, and has very broken incentives, and is obviated by CT, and would have much worse privacy than CT even if it did work 14:01 < andytoshi> oops, wrong channel 14:02 < andytoshi> i wish irssi would clear the send buffer when i switched channels .. weechat would do this 14:03 < sipa> there's an option for that, i think 14:06 < sipa> hmm, maybe not 14:06 < sipa> i was thinking of window_history, but that doesn't apply to the input buffer 14:06 < andytoshi> i'm not even sure what to google for .. ah "input buffer" 15:26 -!- harding_ is now known as harding 15:40 < gmaxwell> I like being able to reuse the send buffer though. 16:01 < andytoshi> sometimes it's convenient, yeah .. i guess i could just be more careful 16:15 -!- deusexbeer [~deusexbee@080-250-075-064-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!] 16:27 -!- deusexbeer [~deusexbee@080-250-075-064-dynamic-pool-adsl.wbt.ru] has joined #secp256k1 20:00 -!- ken2812221 [~ken281222@110.50.135.178] has quit [Read error: Connection reset by peer] --- Log closed Thu Oct 18 00:00:40 2018