--- Day changed Thu Aug 27 2015
00:10 < sipa> platform specific API == epic fun
00:35 -!- jtimon [~quassel@md80436d0.tmodns.net] has quit [Ping timeout: 272 seconds]
02:20 -!- jtimon [~quassel@172.56.30.106] has joined #secp256k1
07:54 -!- jtimon [~quassel@172.56.30.106] has quit [Ping timeout: 260 seconds]
10:44 -!- jtimon [~quassel@172.56.30.106] has joined #secp256k1
11:20 -!- nullbyte [NSA@gateway/vpn/mullvad/x-cmqqpsjuklkdmxzx] has joined #secp256k1
12:15 <@andytoshi> sipa: was there any discussion about separating the signature type into recoverable and nonrecoverable variants?
12:15 <@andytoshi> just curious, you've written all the relevant code, i trust you know what's cleanest..
12:15 < sipa> andytoshi: i decided it while implementing it
12:16 <@andytoshi> cool. in general i'm in favor of moving error paths into the type system
12:16 < sipa> andytoshi: as i don't think it is clean to have recoverable signatures in a separate module, while having the basic signature data type support it (and have unnecessary complication as a result)
12:16 <@andytoshi> ah, that makes sense
12:16 <@andytoshi> strongly agree
12:16 < sipa> i like how the rearlier design unified the two serialization systems
12:16 < sipa> but i think this is still preferrable
12:17 <@andytoshi> yeah, we don't want cruft for modules showing up in the "primary" types
12:17 <@andytoshi> that's asking for extensibility problems
12:19 < sipa> it's unfortunate that there are two separate sign functions now, though
12:26 <@andytoshi> maybe we want conversion functions in both directions rather than separate signing functions?
12:26 <@andytoshi> i dunno, i need to read all the #291 code first
12:26 < sipa> no need, imho
12:26 < sipa> the only "source" of a recid should be the sign function
12:27 < sipa> if you at some point you drop the recid, you can't recover anymore
12:36 <@andytoshi> i gotcha, conversion from noncompact to compact is actually impossible without additional info
12:36 <@andytoshi> and i guess we are saying "recoverable" instead of "compact" now?
12:36 <@andytoshi> since the primary usecase is recoverability, the compactness is just a nice side-effect of us getting to define the serialization format
12:39 <@andytoshi> ok, i've gotten recoverable/nonrecoverable (which describe the signature type) and compact/noncompact (which describe serialization) straight in my head ... i think the proposed API is the Right Thing
12:48 -!- nullbyte [NSA@gateway/vpn/mullvad/x-cmqqpsjuklkdmxzx] has quit [Ping timeout: 246 seconds]
12:50 -!- nullbyte [NSA@gateway/vpn/mullvad/x-ecdweejjxerkmjyx] has joined #secp256k1
12:51 < sipa> the compact representation is an encoding
12:51 < sipa> recoverable is whether it includes a recovery id
12:51 < sipa> before, compact encoding could be recoverable or not
12:51 < sipa> der is never recoverable
12:52 <@andytoshi> cool, that matches my understanding
12:54 < gmaxwell> You could always just try all the combinations.
12:57 <@andytoshi> gmaxwell: only if you've got an address or something to compare to, right?
12:57 < gmaxwell> sure, but how were you goint to verify without that?
12:57 <@andytoshi> well i'm thinking just in terms of ecdsa, not bitcoin script
12:58 <@andytoshi> in particular libsecp256k1 has no notion of addresses
12:58 <@andytoshi> so i think our API pretty-much has to act as though recovery is impossible
12:58 < gmaxwell> sure sure, but thats an API choice.
12:58 < gmaxwell> we could have a recoverable verify with a callback.
12:58 -!- jtimon [~quassel@172.56.30.106] has quit [Ping timeout: 240 seconds]
12:58 < gmaxwell> And a brute force recovery that uses the callback as an oracle.
12:59 < gmaxwell> It would just be slow.
12:59 < gmaxwell> e.g. fn_check_key(void * data, chr * recovered_pubkey);
13:00 <@andytoshi> i wouldn't mind that. i can imagine future usecases along the lines of recovering from communication failure or corrupted wallets or something, and i wouldn't object if somebody wanted us to add that
13:01 < gmaxwell> yea, I'm not suggesting we do that (or at least not now); just pointing out the possibility.
13:01 < gmaxwell> likewise without the callback you could juse the existing thing and just call it up to 4 times.
13:39 -!- nullbyte [NSA@gateway/vpn/mullvad/x-ecdweejjxerkmjyx] has quit [Ping timeout: 245 seconds]
13:40 -!- nullbyte [NSA@gateway/vpn/mullvad/x-fxkvhhmvasaskevr] has joined #secp256k1
13:45 < sipa> andytoshi: sorry for not reviewing your native num yet, but i'd very much like to work towards a~n actual release now first
13:46 -!- jtimon [~quassel@c-24-4-96-213.hsd1.ca.comcast.net] has joined #secp256k1
13:46 <@andytoshi> sipa: it's ok, until this week i was still doing weird things to it for perf reasons. im tired of that (for now at least) and will start working on a jacobi PR on top of it ... which should be much much easier to review
13:47 <@andytoshi> fyi school started for me yesterday so my schedule is going to be high-variance over the next week or so until i adapt
13:47 <@andytoshi> i'm enrolled in an algebraic number theory course which ought to be useful for us
13:47 < sipa> gmaxwell: that's how bitcoin used to produce recoverable signatures... sign, and then try to recover with all 4 possible recids
16:39 -!- nullbyte [NSA@gateway/vpn/mullvad/x-fxkvhhmvasaskevr] has quit [Read error: Connection reset by peer]
19:22 -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 244 seconds]
19:30 -!- roasbeef [~root@104.131.26.124] has joined #secp256k1
20:05 -!- jtimon [~quassel@c-24-4-96-213.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds]
21:56 -!- jtimon [~quassel@c-24-4-96-213.hsd1.ca.comcast.net] has joined #secp256k1
22:00 -!- jtimon [~quassel@c-24-4-96-213.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds]
22:57 -!- jtimon [~quassel@172.56.30.106] has joined #secp256k1
23:41 -!- jtimon [~quassel@172.56.30.106] has quit [Read error: Connection reset by peer]