--- Log opened Sat Nov 10 00:00:17 2018 01:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 01:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 01:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 01:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 01:43 -!- ken2812221 [~ken281222@110.50.135.219] has quit [Read error: Connection reset by peer] 01:43 -!- ken2812221_ [~ken281222@110.50.135.219] has joined #secp256k1 04:32 < andytoshi> yep, that's our intention, our only worry was a general heuristic against deviating from upstream too much 04:33 < andytoshi> (though we already, for example, use the type system to make every ARG_CHECK impossible to fail, and prevent a couple other error paths related to bad secret keys) 06:59 -!- klot [~klot@188.113.44.221] has joined #secp256k1 07:00 -!- klot [~klot@188.113.44.221] has quit [Remote host closed the connection] 07:00 -!- klot [~klot@188.113.44.221] has joined #secp256k1 07:02 -!- klot [~klot@188.113.44.221] has quit [Remote host closed the connection] 07:02 -!- klot [~klot@188.113.44.221] has joined #secp256k1 07:03 -!- klot [~klot@188.113.44.221] has quit [Remote host closed the connection] 07:04 -!- klot [~klot@188.113.44.221] has joined #secp256k1 07:38 -!- ken2812221_ [~ken281222@110.50.135.219] has quit [Ping timeout: 240 seconds] 10:52 -!- deusexbeer [~deusexbee@079-170-138-074-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 272 seconds] 10:53 -!- klot [~klot@188.113.44.221] has quit [Read error: Connection reset by peer] 10:53 -!- deusexbeer [~deusexbee@095-129-175-208-dynamic-pool-adsl.wbt.ru] has joined #secp256k1 11:43 < gmaxwell> andytoshi: bad secret keys? 11:45 < sipa> gmaxwell: i assume keys equal to 0, or >= the curve order 11:46 < gmaxwell> K, but what do they do with them? 13:18 < andytoshi> gmaxwell: if you try to create a secret key object from an encoding of bad keys, you'll get an error 13:18 < andytoshi> at the time of object creation 13:19 < andytoshi> or deserialization, or whatever 13:19 < gmaxwell> I guess the rust interface can force that you actually handle the error too? 13:19 < andytoshi> yes 13:20 < andytoshi> no function will give you a SecretKey object that doesn't represent a valid secret key 13:20 < andytoshi> anything that creates a secretkey will return a sum type representing either a key or an error 13:22 < andytoshi> this means e.g. that signing can't fail https://docs.rs/secp256k1/0.11.5/secp256k1/struct.Secp256k1.html#method.sign because it's impossible to call the function with an incapable context or invalid secret key 13:51 < andytoshi> oh, and you can tell that it doesn't fail from the type signature - fallible funtions return a Result type 13:54 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 13:54 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1 14:11 < gmaxwell> andytoshi: random rust question, is it possible in the typedef to make it so a faulure to handle the error case gives a useful error message, like "not all 32-byte strings are valid private keys, you should resolve this with a regeneration loop or some other means." 14:20 < andytoshi> sorta .. I can annotate functions with #[must_use = "not all 32-byte strings are valid private keys"] but it looks like if i'm returning the standard Result type then its own #[must_use] annotation takes precedence 14:21 < andytoshi> so the user sees the non-specific message "note: this `Result` may be an `Err` variant, which should be handled" 14:21 < gmaxwell> thats a little sad. 14:21 < andytoshi> yeah, that's annoying .. and kinda surprising, you'd think the function annotation would take precedence 14:22 < gmaxwell> (My thought is that if the user didn't handle the error in the first place they probably believe one isn't possible, and might just dummy-handle the error, assuming it's a typing mistake in the interface) 14:23 < gmaxwell> (dummy handle, like unwrap it, or direct to a branch that goesn't do anything useful) 14:24 < andytoshi> yeah, i see your point 14:24 < andytoshi> i asked on #rust about the precedence of #[must_use] .. this seems like the kinda thing that nobody had really considered and the current behaviour is accidental 14:26 < andytoshi> one open API problem we have is how to deal with conversions to hashes to `SecretKey`s .. then the best thing probably is to just unwrap, because if they're starting from a 32-byte hash then any error path is cryptographically unreachable. but unwrap() is a code smell 14:27 < gmaxwell> well another approach would be a function that coerses a 32-byte value to be in range (reducing mod order, and adding 1 if the value is zero). 14:44 < andytoshi> oh, heh, i think the #[must_use] thing was fixed in a very recent version of rustc .. I get the custom error with nighty, but it doesn't show up with stable 14:48 < gmaxwell> cool 15:32 -!- ken2812221 [~ken281222@110.50.135.219] has joined #secp256k1 15:51 < gmaxwell> nickler: https://github.com/bitcoin-core/secp256k1/pull/572#issuecomment-437631031 15:51 < gmaxwell> (sorry, I just noticed the PR now) 15:52 -!- ken2812221 [~ken281222@110.50.135.219] has quit [Ping timeout: 268 seconds] 15:54 < andytoshi> oops, if you're right that the host commitment isn't put into the rng, that's an oversight .. we did intend to do that (this is why there's a commitment at all) 15:54 < gmaxwell> I see it's setup for it! 15:58 < gmaxwell> oh, actually I'm mistaken I think. secp256k1_nonce_function_bipschnorr_no_s2c( handles it. 15:59 < gmaxwell> I missed that it wasn't calling a (*secp256k1_nonce_function) 16:00 < gmaxwell> (it's hard to read this PR on github because it's collapsing half the changes) 16:01 < andytoshi> yeah :/ that's an extremely annoying behaviour and it seems to trigger on only a couple hundred lines of code 16:02 < gmaxwell> it's not consistent, if I reload the PR half the time the main impl.h is collapsed, half the time it's not 17:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds] 19:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 19:25 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 268 seconds] 19:32 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 19:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds] 19:35 -!- lukedashjr is now known as luke-jr 20:39 -!- echonaut [~echonaut@46.101.192.134] has quit [Read error: Connection reset by peer] 20:39 -!- echonaut17 [~echonaut@46.101.192.134] has joined #secp256k1 21:30 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #secp256k1 22:30 -!- ken2812221 [~ken281222@110.50.135.219] has joined #secp256k1 22:32 -!- deusexbeer [~deusexbee@095-129-175-208-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 264 seconds] 22:32 -!- deusexbeer [~deusexbee@080-250-077-159-dynamic-pool-adsl.wbt.ru] has joined #secp256k1 23:17 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has quit [Ping timeout: 250 seconds] 23:25 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has joined #secp256k1 23:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 23:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 23:39 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 23:39 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 23:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 23:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 --- Log closed Sun Nov 11 00:00:18 2018