--- Day changed Mon Oct 26 2015 00:32 < Luke-Jr> sipa: for libblkmaker, I bundled an example that used libgcrypt for SHA2 00:32 < Luke-Jr> no reason examples need to be minimal-dependency IMO 00:33 < Luke-Jr> probably would need libbase58 also anyway 04:20 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] 04:46 < waxwing> reading this makes me idly wonder what would happen if someone knew the private key for the point on the curve with x=0 https://github.com/bitcoin/secp256k1/blob/master/src/ecdsa_impl.h#L270-L271 04:47 < waxwing> i mean, obv not a problem there, just generally curious :) 05:42 <@andytoshi> waxwing: there's no point on our curve with x = 0; but it is possible to get r = 0 (but as the comment says, computationally infeasible) 05:42 <@andytoshi> fwiw i have actually tested that branch on the field of order 43 and it works 05:43 < waxwing> andytoshi: isn't there? i thought i just worked it out :) 05:43 <@andytoshi> you'd need y^2 = 7 and there is no sqrt of 7 in our field 05:44 < waxwing> yes i understand but doesn't 7 **(p+1)/4 mod p work? 05:45 <@andytoshi> no :) 05:46 <@andytoshi> that gives a square root of -7 05:46 <@andytoshi> oh, derp, you are right 05:46 <@andytoshi> no, you're not :). the curve eqn is y^2 = x^3 + 7 05:46 <@andytoshi> not -7 05:46 < waxwing> yeah i got confused as heck, i see it now 05:49 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #secp256k1 07:48 < gmaxwell> waxwing: There are curves where 0 is on the curve, you might even choose it as your generator, so you'd know it's discrete log. 07:49 < gmaxwell> Nothing special would happen--- ECDSA would reject it as r, because ECDSA depends on using the x coordinate mod n as a hash to the multiplicative group of F(n). 08:06 < waxwing> gmaxwell: thanks, yes i understood it's not a problem there, i was just wondering about any special significance of a point on the curve with xcoord 0. maybe there isn't any, generally. 08:06 < waxwing> feel free to ignore my mental doodling, a bit OT, sorry :) 08:23 < gmaxwell> waxwing: there isn't any, really. It's not special except for ECDSA and even for ecdsa the other point at P.x % N (which secp256k1 does have, though we don't know the discrete log) is just as 'special'. 09:10 <@andytoshi> sipa: can we rename the laxder files from .h to .c? 09:10 < sipa> andytoshi: why? 09:10 < sipa> they're intended as snippets to include in your own codebase 09:11 < gmaxwell> they're static, if you link them it won't work. 09:11 < gmaxwell> sipa: because in the world of C code in headers is considered bad form. 09:12 <@andytoshi> sipa: when i try to link them into a static lib i get an error «member /home/apoelstra/dload/code/rust-secp256k1/target/debug/build/secp256k1-bf76a8ba6cad1feb/out/libsecp256k1.a(lax_der_parsing.o) in archive is not an object» 09:12 <@andytoshi> sipa: i'm investigating a deeper "why" 09:13 < gmaxwell> andytoshi: presumably because it if you just compile it you get no symbols, as I said, everything is static. 09:13 <@andytoshi> "my own codebase" is not C, i've gotta wrap it in a library before linking. i can do this if the .h is a .c, otherwise i've gotta create a .c file that has literally one line «#include "laxder_whatever.h"» 09:14 <@andytoshi> gmaxwell: ah, ok, then i'll get link errors when i try to use the functions 09:14 <@andytoshi> i hadn't gotten that far yet 09:14 < gmaxwell> but yes, I think these should be C files, and not static. (and have seperate.h files) 09:16 < sipa> you shouldn't try to compile it 09:17 < sipa> you should copy it into your own codebase and make the necessary changes if needed 09:17 < sipa> they're examples 09:17 < gmaxwell> Which is why they don't use any libsecp256k1 internals. 09:18 <@andytoshi> ok, but the necessary changes are (a) removing the static decorators, (b) renaming the .h to .c 09:18 < sipa> perhaps :) 09:18 < sipa> but that depends on the use case 09:18 < gmaxwell> I think thats actually a prudent thing to do, in any case. As I said, code in .h has bad smell. It's fine in libsecp256k1 internally, we have good reason for it. 09:19 < gmaxwell> there is no reason for it here, no one wants this code inlined. :P 09:19 < sipa> fair enough 09:19 < gmaxwell> and for people who just want to use the code from another language, it'll make their lives easier too. 09:20 <@andytoshi> eg all my sharp-edge-removal happens in rust, but i need a library to link against to access the C code in the first place 09:32 <@andytoshi> i'll submit a PR for that once #342 is settled 09:32 < gmaxwell> when you do, split out prototypes and extern C them. yadda yadda. 09:36 <@andytoshi> yup 11:20 <@andytoshi> i'm having some trouble validating testnet 8ccc87b72d766ab3128f03176bb1c98293f2d1f85ebfaf07b82cc81ea6891fa9, the sig in the third input parses but fails validation 11:20 <@andytoshi> with laxder 11:20 < sipa> can you paste the signature? 11:21 <@andytoshi> 3046022100839c1fbc5304de944f697c9f4b1d01d1faeba32d751c0f7acb21ac8a0f436a72022100e89bd46bb3a5a62adc679f659b7ce876d83ee297c7a5587b2011c4fcc72eab4502 11:21 <@andytoshi> (that's a bitcoin sig, the last byte is the sighash) 11:22 < sipa> looks like a totally ordinary signature 11:22 <@andytoshi> it does, yes 11:22 < sipa> i would say it's DER even 11:23 <@andytoshi> regular parse_der rejects it 11:23 < sipa> you are stripping the last byte before parsing, right? 11:24 <@andytoshi> oh lol, not in my rust-secp unit tests 11:24 <@andytoshi> ok, regular parse_der is fine with it 11:24 <@andytoshi> but it's still failing in the rust-bitcoin unit tests, where it didn't used to 11:24 < sipa> laxder should parse and validate, even with the 0x02 byte at the end... 11:28 <@andytoshi> ok, the probelm is probably somewhere in my code then 11:29 < sipa> well if it changed compared to the old normal parser in libsecp256k1, something is wrong 11:29 < sipa> the laxder parser now should be more permissive 11:30 <@andytoshi> i'm actually unsure which commit changed things, i updated the rust-bitcoin libsecp after a few weeks 11:30 <@andytoshi> laxder was the most obvious culprit (and indeed replacing strictder with laxdir did fix 2 of 6 newly-failing unit tests) 11:44 <@andytoshi> o.O there is actually a change depending on the version of libsecp256k1 i use with rust-secp256k1. (smart money is still on my code, but at least it's not a problem in my script parser, thank god) 11:44 <@andytoshi> sig: 3046022100839c1fbc5304de944f697c9f4b1d01d1faeba32d751c0f7acb21ac8a0f436a72022100e89bd46bb3a5a62adc679f659b7ce876d83ee297c7a5587b2011c4fcc72eab45 11:44 <@andytoshi> pk: 031ee99d2b786ab3b0991325f2de8489246a6a3fdb700f6d0511b1d80cf5f4cd43 11:44 <@andytoshi> message hash: a4965ca63b7d8562736ceec36dfa5a11bf426eb65be8ea3f7a49ae363032da0d 11:45 < sipa> define change? 11:45 <@andytoshi> that signature used to validate, now it doesn't 11:46 < sipa> both with laxder and der? 11:46 <@andytoshi> passed back in b2eb63b2, fails now with 131afe5 (which is is two commits ago, that's right before rusty's change) 11:46 <@andytoshi> unsure about laxder 11:46 <@andytoshi> gonna bisect first 11:46 <@andytoshi> but with der, yes 11:48 <@andytoshi> oh, derp, it's 0c6ab2ff "require low-S" 11:48 <@andytoshi> i need to normalize for bitcoin 11:48 < sipa> oh, yes! 11:49 <@andytoshi> phew!! 16:07 < sipa> rebased my bitcoin secp256k1 branch + updated to current master + reindexing testnet 16:14 < gmaxwell> sipa: remember to checkpoints=0 (not that it matters, due to other bugs, but a good practice) 16:41 < sipa> gmaxwell: done, all good 16:44 < gmaxwell> Unsurprising. Does your implementation switch to not using the lax parser after BIP66? 16:45 < sipa> no 16:46 < sipa> that would be invasive to do... bip66 is done at the script validation level 16:48 < TD-Linux> a libbase58 would be nice. I've seen several base58.c's floating around. some with security fixes. 16:52 < gmaxwell> even more fun than the ones that pull in a 1MB bignum library to do it. 16:57 < TD-Linux> I think all the python implementations I've seen use bignum 16:58 < gmaxwell> well if you're already in python the nmegabytes are already paid. 17:00 < gmaxwell> sipa: if we want to discourage people from using the contrib code we should just say so explicitly, not make it especially sketchy. Even if people are copying it into their code tree, they'll want it in a seperate file, with its own header, for software maintance reasons. 17:01 < gmaxwell> sipa: also, if they actually do need it... what else would you have them used? completely untested parser code that they found on the internet which is exploitable and what not? There is nothing wrong with the der lax parser AFAIK, only that it impements no particular standard beyond "sufficient for bitcoin" 17:08 < TD-Linux> maybe you need a companion library, libbitcoinkitchen 17:13 < sipa> gmaxwell: i'm not trying to discourage using it 17:13 < sipa> gmaxwell: it's pretty well tested code 17:14 < sipa> gmaxwell: but if you start to use it, you're committing to a particular set of standard violations that it supports 17:14 < sipa> gmaxwell: if the contrib file is changed to support other violations, you should keep using the old code 17:14 < gmaxwell> sipa: right, so lets just treat it like proper code and not do weird things like shoving it all in a header, or leaving it without a header. :) 17:15 < sipa> if it didn't make things hard to test, i'd just put it in a .txt file instead 17:17 < gmaxwell> haha 17:18 < sipa> i'm serious 17:18 < gmaxwell> we could pass it through a C to english translator. 17:19 < gmaxwell> sipa: we should add a message at the top that tells people how to use it then. 17:22 < TD-Linux> what is this, tsundere code? 17:25 < gmaxwell> sipa: I don't think forcing everything into a .h file meaningfully accomplishes what you're trying to accomplish. The signal it sends is that we don't understand the norms for C programming, not "you should copy this into your code." :) 17:26 < TD-Linux> also the names being prefixed with secp256k1_ enforces the idea that they are library functions 17:27 < sipa> TD-Linux: good point! 17:27 < sipa> gmaxwell: ok, better suggestions? 17:27 < TD-Linux> also is the "violations are chosen arbitrarily and do not follow or establish any * standard." a ridiculous way to not say the word "bitcoin" in the codebase? 17:28 < sipa> it's interesting that you interpret it that way 17:29 < sipa> but i think it's a bad idea whatsoever to commit to a particular implementation with undefined standards it implements 17:29 < gmaxwell> TD-Linux: well they're not equivlent to whats needed for the historic chain, they're a superset of that. 17:31 < TD-Linux> gmaxwell, oh okay, andytoshi using it to parse bitcoin signatures misled me :) 17:31 < gmaxwell> TD-Linux: since BIP66 all bitcoin signatures will parse with the standard strictder parser... so something lax is only needed for 'historic' signatures. 17:32 < TD-Linux> gmaxwell, yes I know, so I assumed this was for pre-bip66 17:33 < TD-Linux> also in the comments on that code, I would put the "Do not use" paragraph first 17:34 < gmaxwell> sipa: I suggest we take andrews patch, we put a comment at the _top_ of each source file; telling people not to use it in new applications, to copy it when used. And we (me I guess?) write an application guide. E.g. "Using libsecp256k1 for Bitcoin applications" that (0) that the library is intended for more than just bitcoin applications but it was constructed with bitcoin's needs foremost in our mind 17:34 < gmaxwell> (1) tells you about the contrib/ parser and instructs you to copy it, (2) tells you about the signature canonicizer, (3) tells you that strict-der and BIP66 are not exactly the same. (whatever else). 17:34 < sipa> OKAY 17:36 < gmaxwell> (other suggested app guides, are "libsecp256k1 in embedded enviroments" and "constructing cryptographic 'like' buttons for fun and profit") 17:38 < gmaxwell> (less jokingly "libsecp256k1 with MSVC" would be a popular title, https://bitcointalk.org/index.php?topic=1208474.0 ) 17:42 <@andytoshi> i agree with TD-Linux's point that having secp256k1_ on the functions is misleading, we should drop the prefixes 17:43 <@andytoshi> as for "people shouldn't be linking this directly", this is only useful for parsing the bitcoin blockchain and linking it directly is sufficient to do that 17:44 <@andytoshi> it's 180 lines of almost-rust, i'm happy to just port it to rust if you feel i'm setting a dangerous example by linking it this way 17:45 < sipa> andytoshi: or copy it to a .c file in your source 17:46 <@andytoshi> sipa: i've actually got the whole secp256k1 tree in my source now 17:46 <@andytoshi> which has a file laxder_shim.c added to it which just includes the .h 17:46 < sipa> ok 17:50 <@andytoshi> sipa: i get where you're coming from. i'll sleep on this. in the morning i might agree with you 18:01 -!- fkhan [weechat@gateway/vpn/mullvad/x-yjxxwavjvubkbjnz] has quit [Ping timeout: 250 seconds] 18:11 < gmaxwell> andytoshi: it's always useful to divide up issues. How you/users use the code is mostly distinct from how we lay it out and store it. 18:13 < sipa> i'm fine with gmaxwell's solution 18:15 -!- fkhan [weechat@gateway/vpn/mullvad/x-fpuzdzgceqhznkgv] has joined #secp256k1 21:42 -!- fkhan [weechat@gateway/vpn/mullvad/x-fpuzdzgceqhznkgv] has quit [Ping timeout: 250 seconds] 21:56 -!- fkhan [weechat@gateway/vpn/mullvad/x-slnmaxmiuwdufown] has joined #secp256k1