--- Log opened Wed Dec 18 00:00:40 2019
00:51 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 252 seconds]
03:34 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer]
03:47 < real_or_random> We still write "This library is a work in progress and is being used to research best practices. Use at your own risk." in the README
03:48 < real_or_random> can we remove this? I think it's not appropriate anymore
03:51 < gmaxwell> because there is almost no work in progress? :P
03:52 < gmaxwell> Maybe add "if this concerns you, beware, because everything else we can find is much worse." ? :P
03:55 < real_or_random> my concern is that it prevents people from using the library. and this is bad because everything else is indeed much worse
03:57 < real_or_random> and bitcoin core relies on it, which is a pretty conservative project when it comes to these things
03:57 < gmaxwell> Yes but the usage in bitcoin core is an intentional subset. It uses it in ways the authors of the library anticipate, rather than in arbritary ways.
03:57 < real_or_random> (you could argue bitcoin itself is WIP and used to research best practices, but I think that's a different discussion)
03:58 < real_or_random> to me this reads as "this is the best secp256k1 library in the world, it's very high quality. please don't use it in practice, it's dangerous"
03:59 < gmaxwell> In the spirit of handling things correctly even if everyone else sucks there is probably a better statement that could be made there, which answers your concern but doesn't contribute to the industry wide practice of sticking stuff out there which is far less robust than the user assumes.
03:59 < real_or_random> which implies "don't use crypto. we're too stupid to get it right" but I don't think that's what we want to say
04:02 < gmaxwell> A lack of frank statements about maturity and the limitations of validation is a strong sign that a library is unsafe to use. Just because many other things which very much should have such statement lack them isn't a reason to match though.
04:02 < real_or_random> re intentional subset: maybe we should make clearer that functions like privkey_tweak_add are indeed rather for people who know what they're doing. whatever that means
04:05 < gmaxwell> A better statement would be along the lines of  "We intend this library to be, and believe it currently is, the highest quality publically available library for cryptography with the secp256k1 curve. However, the primary focus of its development has been for usage in the Bitcoin system and usage unlike Bitcoin's may be less well tested, verified, or suffer from a less well thought out interface.
04:05 < gmaxwell> Correct usage requires some care and consideration that the library is fit for your application's purpose."
04:05 < real_or_random> I think we're setting the bar too high. what would you want to do to make usage outside core safer?
04:05 < real_or_random> that's a nice statement
04:06 < gmaxwell> or at least something along those lines. The important thing is just to be frank and help people approach the library with realistic expectations.
04:07 < gmaxwell> as far as tweak.. man I really wish bip32 used sha256 and not hmac-sha512 or I'd suggest tweak should just be replaced with a hashing interface.
04:11 < real_or_random> right, that will be much easier
04:11 < real_or_random> but would it be too bad to have both a bip32-tweak and a sha256 interface?
04:12 < real_or_random> we need sha512 then.. yeah. well.
04:13 < gmaxwell> One way to think about cryptography is that there is no such thing as a faulty construction. A construtions is a mathmathical thing, inherently perfect. It is what it is, nothing more, nothing less.  What can be faulty is out expectations of a construction-- we think it makes guarentees that it doesn't or it has 'features' which not only have we never thought of but we never even thought of the class
04:13 < gmaxwell> of feature.  So difficult task for making a good general purpose library is aligning the user's expectations with the reality of the constructions. And this is really hard, because even when the user is a cryptographer, even a simple construction like a signature can have way more properties than is easy to keep in your head.  Thus the preference away from 'generic' interfaces that have essentially
04:13 < gmaxwell> infinite properties...
04:14 < gmaxwell> real_or_random: shipping sha512 wouldn't be THAT big a deal, though it only has an efficient implementation if you have an uint64_t.  (I'm not sure-- the library might work where there is no 64-bit type, thats certantly a nice property to have for embedded use).
04:14 < gmaxwell> but I think unfortunately the hashing structure is also an annoying bit of complexity.
04:15 < gmaxwell> like BIP32's unhardened hashes have the pubkey in the hash.
04:16 < real_or_random> indeed but this is rather an argument to provide a good implementation
04:16 < gmaxwell> I think what would probably be best is drop the tweak interface, and add a bip32 _module_. And maybe modules for other things that need tweak.
04:16 < real_or_random> yep, a module would also make SHA512 optional then
04:17 < gmaxwell> right, that sha512 would just be part of that module.
04:18 < gmaxwell> (we also should have some way to at least compile time replace the hashes with caller provided ones-- e.g. why is libsecp256k1 using slow native C sha256 in bitcoin core where there is sha-ni in use otherwise?)
04:19 < real_or_random> oh yes, can you open an issue?
04:19 < real_or_random> (not saying that having more issues implies that we work on them but ok... shrug)
04:19 < gmaxwell> K.
04:21 < real_or_random> :)
04:26 < gmaxwell> in any case, I'm sympathetic to the desire to not shoot usage in the foot unnecessarily.
04:28 < gmaxwell> Years ago, after working on theora (video codec) for a number of years, I eventually found out that a important website made a decision to not use the format almost entirely because libtheora was labled "alpha", and we only learned about it eons after the fact.  The alpha didn't mean much, and mostly referred to the library encoding API not being stable if anything, it certantly didn't refer to the
04:28 < gmaxwell> format itself-- which had a bitstream frozen from essentially its first public release.
04:51 < elichai2> Is there a "right" way to print some scalar so I can use it in tests? (I have something failing and I want to isolate the scalar into a test) there's `SECP256K1_SCALAR_CONST` but that accepts 8 ints which I'm not sure how to produce (without writing a function that does the oposite shifts) and there's the `get_b32` and `set_b32`
04:56 < gmaxwell> elichai2: make a macro which does the matching shifts. Look at how the code that generates the static tables works.
04:56 < gmaxwell> you could do simpler things, but then it wouldn't be portable. :)
04:59 < elichai2> I guess so. I have such weird things going on. when I test the result of a function *inside* of it I get one answer, and when I try to hard code everything (using get/set_b32) and call my function from the tests with the new hard coded vars I get a different result :O
05:11 < gmaxwell> run in valgrind.
05:21 < elichai2> yeah, I also added some check so that hopefully valgrind will give me a stacktrace too
05:24 < elichai2> ohhh found it :) I assumed r and x aren't pointing to the same location lol
05:24 < elichai2> so it screwed with my test at the end of the function but it worked fine outside of the function lol
05:24 < elichai2> gmaxwell: Thanks!
06:51 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-ljnsyxugfwixcbdn] has joined #secp256k1
09:15 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #secp256k1
09:15 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
09:15 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1
09:19 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #secp256k1
13:35 -!- Netsplit *.net <-> *.split quits: nsh, TD-Linux
13:35 -!- Netsplit over, joins: TD-Linux
13:41 -!- nsh [~lol@wikipedia/nsh] has joined #secp256k1
13:48 -!- jtimon [~quassel@22.133.134.37.dynamic.jazztel.es] has joined #secp256k1
14:08 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
14:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 265 seconds]
14:09 -!- jtimon [~quassel@22.133.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
14:13 -!- lukedashjr is now known as luke-jr
14:37 < sipa> elichai2: you know additionchains.com ?
14:41 < elichai2> Not the site. No. But looks quite interesting
14:43 < gmaxwell> There is an algorithim in TACP that gives reasonably good results, should probably check that the chain in the software is at least that good.
15:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
15:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
19:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 245 seconds]
--- Log closed Thu Dec 19 00:00:41 2019