--- Log opened Tue Aug 06 00:00:31 2019
04:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 245 seconds]
04:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
04:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
04:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
04:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
04:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
07:06 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bsihzsmbdqhsuctf] has joined #secp256k1
07:39 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
07:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1
07:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection timed out]
07:57 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
09:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]
09:44 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1
09:48 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
09:49 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1
10:59 < nkohen> Could anyone point me in the direction of a function (if it exists) that does what `lift_x` does in bip-schnorr (get the right point for a given x value)?
11:06 < nickler> secp256k1_ge_set_xquad(pt, &rx)
11:06 < nickler> (see batch verification in the schnorrsig module)
11:08 < nkohen> sweet :) thanks
11:18 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1
11:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
11:49 -!- reallll is now known as belcher
12:07 < elichai2> nickler: do we have it also in the public api? (if we use x only pubkeys we might need to reconstruct the pubkey) maybe something like `SECP256K1_EC_COMPRESSED` but `SECP256K1_EC_QUAD_RESIDUE`
12:08 < sipa> elichai2: i'd rather not add that until there is a use case in bitcoin for it
12:08 < sipa> libsecp256k1 tries to be high-level
12:08 < elichai2>  just in the middle of doing some taproot key manipulation and saw his question, so if we actually use X only in taproot there'll probably be a use case for it
12:09 < sipa> i don't think there is any need in taproot for it either
12:09 < elichai2> (i.e. creating a CPubkey from the X only)
12:09 < sipa> we only use the quad trick inside schnorr sigs
12:09 < sipa> so it can be encapsulated behind the schnorr api
12:11 < sipa> for 32-byte public keys we'd pick always-even as tie breaker i think; there is no gain from using the quad trick there (as public keys are always in affine coordinates)
12:11 < elichai2> the schnorr api still accept a `secp256k1_pubkey` and for that we'll need to use the `secp256k1_ec_pubkey_parse` and serialize
12:11 < sipa> sure
12:11 < elichai2> oh so always even just means you add 0x02 before the x, that's easy enough to do in bitcoin-core itself
12:14 < sipa> right, or the schnorr api gets a special 32-byte based interface (see https://github.com/sipa/bips/pull/52)
12:18 < elichai2> the problems with that are, A. this breaks the "same public key" argument for ecdsa&schnorr (and mean that APIs might need to provide a different struct\class for that, or enforce even only in the api). B. doesn't this hurt performance that you need to parse/serialize on every operation instead of using gej until you actually want to serialize?
12:21 < elichai2> altough I'm not even sure that the `secp256k1_pubkey` object is gej, so I might be wrong on that.
12:24 < elichai2> looking at the code it seems like that's not the case. why not? the lib doesn't promise anything about that object, why not make it store a gej obj? (that way verifying multiple signatures with the same pubkey will be faster)
12:25 < sipa> secp256k1_pubkey is ge
12:25 < sipa> ge's are faster to work with than gej
12:25 < sipa> and converting from ge to gej is free
12:26 < sipa> yes, it breaks the "same public key argument" but not in a meaningful way; you can just drop the first byte - actual derivation code doesn't need to change
12:27 < sipa> and address derivation code will need to change anyway
12:27 < sipa> arguably this can be dealt with at the address level; just skip the first pubkey byte when hashing
12:27 < elichai2> what are you refering to by address derivation code?  CExtPubKey? or something else?
12:28 < sipa> the code that computes address from keys
12:28 < sipa> whatever that is
12:28 < elichai2> right I forgot that ge->gej is 2 devisions and 2 small squares, the "hard" part it gej->ge (mod inversions)
12:28 < sipa> yeah
12:28 < elichai2> oh ok
13:28 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
13:55 < nkohen> So I'm developing a Discreet Log Contract Oracle server which needs to compute a nonce (long) ahead of signing and make public the R value. As far as I can tell there isn't a nice way for me to do this process without somehow having access to secp256k1_fe_is_quad_var or in some other way creating a function that takes a nonce and returns a bool for whether or not the nonce needs to be inverted (k => -k). Is there a public-facing
13:55 < nkohen> function I'm not aware of?
14:21 < sipa> secp256k1_ec_privkey_negate
14:21 < sipa> oh, i see
14:21 < sipa> no, i don't think so
14:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
14:25 < nkohen> do you suggest I add this function on my branch of secp or should I do something a little sillier like signing a message with a fake private key and test which of the two possible public keys R validate correctly against the fake signature (seeing as I have already implemented a function that computes s*G from R and m)
14:33 < nickler> why isn't sending R.x sufficient?
14:34 < nickler> (which you only get by signing - certainly awkward in your situation)
14:35 < nickler> (wait scratch that can just use your fixed nonce and use pubkey create and take the x-coordinate)
14:38 < nkohen> well all DLC clients need to compute `R + e*P` for all possible messages `e` so either the server needs to be able to compute the correct R and publish it or all clients need to have a function to compute the correct R from R.x
14:39 < nkohen> though I suppose I could go with just having the clients compute `R + e*P` from `R.x` seeing as I could then just change the one function I am adding to the interface to take in R.x rather than R
14:39 < nickler> you'd rather want a function that takes R.x, P and a message and computes R + e*P directly
14:39 < nickler> yeah
14:40 < nkohen> So in this case I assume that I would take R.x as an unsigned char* right? I don't have access to secp256k1_fe from the schnorrsig header file
14:42 < nickler> I think either we want a get_pubnonce function that computes the correct point or your function could take R and throw the y-bit away
14:43 < nickler> ideally we'd do the former have a new type for nonces so we don't use the pubkey stuff
14:43 < nickler> and encode nonces as 32 bytes only
15:39 < real_or_random> elichai2 sipa : I think if we'll have some 32-byte variant of schnorr (no matter if it's the only one or not), there should be a new public key type in the API.
15:43 < sipa> real_or_random: agree
17:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1
17:34 -!- instagibbs [~instagibb@pool-100-15-121-126.washdc.fios.verizon.net] has quit [Ping timeout: 245 seconds]
17:35 -!- instagibbs [~instagibb@pool-100-15-121-126.washdc.fios.verizon.net] has joined #secp256k1
18:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]
20:24 -!- nkohen [~nkohen@2601:282:4101:9356:98e9:d895:822c:6cdc] has quit [Ping timeout: 276 seconds]
20:35 -!- nkohen [~nkohen@2601:282:4101:9356:a1ee:9437:66b5:23b4] has joined #secp256k1
21:05 -!- Cory [Cory@unaffiliated/cory] has quit [Ping timeout: 268 seconds]
21:12 -!- Pasha [Cory@unaffiliated/cory] has joined #secp256k1
21:14 -!- Pasha is now known as Cory
--- Log closed Wed Aug 07 00:00:32 2019