--- Log opened Mon Nov 11 00:00:04 2019
01:05 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]
01:09 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #secp256k1
01:38 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 276 seconds]
02:29 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #secp256k1
05:56 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 246 seconds]
06:06 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #secp256k1
06:15 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 265 seconds]
06:21 < elichai2> How do people feel about adding a `secp256k1_ec_privkey_inverse`?
08:08 < sipa> i understand that's appealing, but i'd very much prefer not to
08:09 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has quit [Ping timeout: 250 seconds]
08:09 < sipa> we should expose APIs that are high level enough that they're hard to misuse
08:43 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #secp256k1
08:46 < elichai2> sipa: well we already have `_tweak_` functions :)
08:48 < sipa> elichai2: yes, i know
08:48 < sipa> we shouldn't
08:49 < sipa> my hope is that we can replace them with _bip32 and _taproot specific functions at some point
08:50 < elichai2> I just wonder how much we care about 100% bitcoin versus about letting people have a safe library to use (not talking about low level primitives and/or inifinity points etc.)
08:51 < sipa> imho we should implement "protocols" and not "primitives"
08:52 < sipa> and specifically, ones that are used in bitcoin
08:52 < elichai2> hmm
08:55 < elichai2> sipa: I'll tell you where I'm coming from, I saw this: https://github.com/paritytech/parity-common/pull/258, and it's just a shame they're butchering the library and they're not updating it because of it (the rust library has changed a lot over the time  and they're stuck with old stuff just because of it)
08:56 < elichai2> but maybe I'm too nice to them lol, I can see saying "If they're not competent enough to maintain their own libsecp256k1 tey shouldn't do stuff like that"  as a valid thing too
08:57 < sipa> well what do they need "inverse of a private key" for?
08:57 < sipa> afaik  o such thing exists in any common protocol
08:57 < sipa> *no
08:57 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined #secp256k1
09:16 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]
09:33 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #secp256k1
09:45 < elichai2> sipa: they seem to be implementing https://www.researchgate.net/publication/280531698_Robust_Threshold_Elliptic_Curve_Digital_Signature
09:46 < elichai2> IIUC
09:47 < elichai2> which has ` Each  player P_i  computes  his  share  of  x^-1  as  ?_i = e_1*u^-1 on a polynomial of degree 2t.`. so i guess that's the inverse. anyway they should probably implement it *inside* secp if it's secure enough
09:48 < elichai2> (i.e. libsecp-zkp)
09:49 < elichai2> " n/4 malicious  adversaries" so in a 2/3 they can't withstand *any* malicious adversary? :O
10:13 < gmaxwell> right, so their building stuff that won't even be secure (or that useful) in practice.  Craze people gonna crazy. We shouldn't be helping.
10:14 < gmaxwell> The idea of the library is to offer interfaces that a non-cryptographer has a fighting chance of using safely. If someone is a cryptographer competent enough to use an unsafe interface, then they're perfectly capable of just copying the library and adding whatever they need to it.
10:15 < sipa> elichai2: doing it inside secp will likely be faster too, as that avoids converting all points to affine coordinates (or even to normalized jacobian ones)
10:16 < sipa> but especially the normalization requirements are very complex and not something you'd want to expose to an unrestricted API
10:16 < gmaxwell> also exposing internals means tying the library developers hands, making it harder to improve things because it'll break the interface.
10:17 < gmaxwell> E.g. if you expose a projective coord because thats the only way to write any kind of algo with decent performance, .. then later changing the projection in use becomes a breaking change.
10:22 < gmaxwell> I believe that if you were to compile libsecp256k1 with schnorr only (something that might be supported in the future), there wouldn't even need to be a scalar inverse included in the binary at all.
10:22 < gmaxwell> The only thing a scalar inverse is needed for right now is ECDSA verrify, I think.
10:23 < sipa> gmaxwell: i think that's right
10:24 < elichai2> We should obviously never expose projective/jacobian coordinates or anything similiar to a user, I only thought about inverse because we already have a bunch of tweak functions
10:25 < gmaxwell> elichai2: the tweak functions are really just "bip32" functions.
10:25 < gmaxwell> (there is another bip32 like scheme that uses a multiply instead of an add too)
10:26 < sipa> bip38
10:27 < sipa> but i think the tweak functions existed before we gave in and added hashes to the library
10:27 < sipa> without also having access to hashes, the tweak style functions were the best possible abstraction to implement bip32
10:28 < sipa> if we'd add SHA512 to the library, you could natively implement the actual bip32 operations instead
10:28 < sipa> (or add a way for callers to provide their own SHA512 implementations; something we likely want to do for SHA256 and taproot too)
10:30 < gmaxwell> yeah, I have kind of mixed feelings about that, because function pointers are hard to use safely... and other bugs so easily turn them into control flow takeover points.
10:30 < elichai2> yep. we have a long discussion about exposing the function pointers for `ecdh` in the rust bindings
10:31 < sipa> function pointers are one way; a -DEXTERNAL_SHA512_FUNCTION=... is another
10:31 < elichai2> it's not easy to do safely
10:31 < sipa> this problem is easier than the ECDH thing, where you may actually want runtime-dependent functions
10:31 < sipa> SHA512 is SHA512, so a single compile-time instantiation should be sufficient
10:31 < elichai2> the problem with the ecdh thing is that some people use it to expose coordinates
10:32 < elichai2> And also that's it's scary across FFI boundaries :)
10:32 < sipa> elichai2: there is a limit to how hard we can make things; if they really want the coordinates (which may be necessary for some protocols, and safe in some contexts), they'll use whatever way that enables that - including using different software
10:33 < elichai2> (even in C++, passing a function pointer to a function that might `throw`)
10:33 < gmaxwell> sipa: indeed, decent point. The same kind of argument could be used to substitute the internal sha256 for a faster one (or just reuse the builders already existing other copy).
10:33 < sipa> i don't think our goal should be to make dangerous things impossible; it should be to make sure that the easiest way to do things is a safe one
10:34 < gmaxwell> right the point isn't that someone crazy will do something dumb, it's that someone innocent will blow their foot off.
10:34 < sipa> gmaxwell: yes, the reason we can't really provide a taproot specific tweak API is because the result wouldn't really be able to make use of efficient SHA256 code that Bitcoin Core already has, so it would be a performance degradation compared to the slightly more lowlevel tweak API
10:35 < sipa> but if there was a way to pass in an optimized SHA256 function (either at runtime or at compile time), that problem would disappear
10:35 < gmaxwell> sipa: wouldn't apply if we just had a clean way of overriding the hash.
10:35 < gmaxwell> right.
10:36 < gmaxwell> At some time in the future libsecp256k1 might need processor feature runtime autodetection, and if it did, shipping a faster sha2 wouldn't be that big a deal.
10:38 < sipa> maybe, but keeping up with various optimized SHA256 mechanisms for various platforms may be an unnecessary task, especially given that we can reasonable assume that users of the library already have a fast SHA256 implementation (and if they don't, they probably don't care about the gains secp256k1 could get from having access to one)
10:44 < gmaxwell> good point.
10:53 < elichai2> Well, we can just add it as an optional parameter to context creation
10:53 < elichai2> A pointer to a sha2 function
10:54 < sipa> C doesn't have optional parameters
10:54 < elichai2> Well yeah the pointer can be null
10:54 < sipa> but a secp256k1_context_set_sha256_fn or will work just as well
10:54 < elichai2> Or a new function for the context like the randomize one but for adding a sha2 function
10:55 < elichai2> sipa: my point is so you won't need to keep providing it to every call
10:55 < elichai2> But if you link it then sure
10:55 < sipa> elichai2: lol, of course not
10:55 < elichai2> Not sure if linking is better though
10:55 < sipa> i wasn't assuming it would be provided on every call
10:55 < elichai2> Heh OK
10:56 < elichai2> Just thought that the options are probably either linking or providing to the context once, then you can make commitment functions, accept the whole message etc
10:57 < elichai2> The problem is keeping and both simple and usable, because a lot of times we want an engine like sha2, but in C that now requires 3 functions and a state
10:58 < sipa> for simple use cases you can have a sha256(unsigned char* output32, const unsigned char* input, size_t input_len)
10:58 < sipa> that does the whole init/update/finalize in one call
10:59 < elichai2> Yeah I'm just imagining ecdh for example that you feed it 2 variables, it sucks to need a third one to memcpt the others into just to hash but KISS
10:59 < gmaxwell> sipa: for things like computing challenges for batch verify I dunno if you want to prepare the whole input in a single buffer. :(
11:00 < gmaxwell> elichai2: the memcpy of 32/64 bytes is irrelevant compared to the time ecdh takes.
11:01 < elichai2> I know I know it's just an annoying complication the more parameters you have heh
11:02 < sipa> also for bip-schnorr tagged hashes you want a way to provide either precomputed states for certain constants, or provide specialized functions for specific tags
11:02 < sipa> which is annoying
11:03 < gmaxwell> well that fits fine in the normal 'init() / update() / finalize' model for hash functions. ... its just a distinct init.
11:08 < gmaxwell> the other related issue, is that for non-normative hash usage... unless the hardware has sha-ni ... sha2 is pretty annoyingly slow. So for batch verification, for example, hashing the inputs is likely to be a non-trival part of the runtime... and for that you'd want to not use sha2 unless there is hardware sha2 support.   also, in batch verification the challange sha2 is naturally n-way parallel...
11:08 < gmaxwell> which sort of begs for 4/8 way sha2 which the vast majority of hardware has.
11:10 < sipa> good point
11:11 < gmaxwell> (I think one of nickler's batch verify things used chacha to compute the challenges ... which is slower than sha-ni where it exists, though still probably a better default)
11:14 < sipa> it uses chacha to expand the hash into many factors
11:14 < gmaxwell> does it hash the inputs with sha2 then use chacha?
11:14 < gmaxwell> (or are you required to give it a random value?)
11:15 < sipa> i believe it uses sha256
11:15 < gmaxwell> that seems pretty hash-function-soupy. :P
11:15 < sipa> the hash function based on chacha's primitives is called blake
11:22 < gmaxwell> the requirements for the randomness in a batch verify are pretty darn small.
11:23 < gmaxwell> like for really big batches you could probaby get away with using only 32-bits for each R.
11:39 < gmaxwell> I guess you can't go under 64bits while keeping the probablity of false acceptance below 2^128... still, it's not a very strong requirement.
11:50 < sipa> so, siphas
11:50 < sipa> so, siphash?
12:42 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1
12:44 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
13:33 -!- reallll is now known as belcher
21:58 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds]
22:03 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1
--- Log closed Tue Nov 12 00:00:05 2019