--- Log opened Thu Aug 15 00:00:40 2019 01:35 -!- harding [~harding@cpe-66-91-121-125.hawaii.res.rr.com] has quit [Ping timeout: 248 seconds] 01:36 -!- harding [~harding@cpe-66-91-121-125.hawaii.res.rr.com] has joined #secp256k1 03:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 04:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 04:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 05:37 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-chkqjvgluvzddzsc] has joined #secp256k1 05:43 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 05:48 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 09:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 11:06 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 12:21 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1 12:23 -!- provoostenator [~vwDZ2BYsc@2a05:d014:5f:e100:fd30:8af7:2d6a:cbb1] has joined #secp256k1 12:23 -!- reallll [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds] 13:32 < elichai2> Will a hash to curve function in secp256k1-zkp be conceptually ACKed? (still deciding between "Try and Increment"(loop with incrementing the hash until quad residue), "Try and rehash"(the same but hashing the result every try) or something like Icart's function or just if it's on the curve without relation to quad residue) 13:34 < elichai2> One question would be should the data to this function be considered secret, and if so then acheiving constant timeness is a bit harder(but possible). I personally don't think it should be considered secret because the main use case I see is for a "verifiable unsolved point" such that you show that your point has no known DL 13:35 < sipa> for what purpose? 13:35 < sipa> i know cases where a hash-to-curve operation operates on secret data and one where it operates on public data 13:36 < sipa> generally something like this will be part of a particular protocol, so you should implement whatever that protocol requires 13:36 < elichai2> I see right now only use cases for public data. I.e proving that this point has no known DL (for example an internal key in taproot) 13:37 < nickler> there is already hash to curve in secp-zkp using shallue_van_de_woestijne https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/include/secp256k1_generator.h#L63 13:37 < sipa> yeah, that's a fairly complicated constant-time one 13:37 < sipa> but it's part of our generator system there, so it can't be changed 13:38 < sipa> without breaking deployed systems 13:38 < nickler> elichai2: for internal taproot keys hash to curve isn't really needed https://github.com/sipa/bips/pull/43/files 13:39 < elichai2> ha. and there `seed32` is a secret number 13:39 < elichai2> *? 13:40 < nickler> exactly 13:41 < elichai2> could you explain the reason why it's secret? (i'm curious) 13:41 < sipa> elichai2: it's not secret, but it needs to be compatible with places where it's used with a secret input :) 13:41 < sipa> (iirc) 13:42 < sipa> it's for confidential assets 13:42 < elichai2> btw, why hash of der serialization and not just hash of "This is an alternative generator" that feels more obviously not maliciously chosen 13:42 < sipa> DER? 13:42 < sipa> there is no DER involved 13:42 < elichai2> sipa: what do you mean when it's used with it? don't you just create a generator and only then just multiply it by your secret? 13:42 < elichai2> sipa: talking about: https://github.com/sipa/bips/pull/43/files 13:43 < sipa> heh, that's nonsense 13:43 < sipa> it's the serialization of G 13:43 < sipa> but DER is only ever used for ECDSA signatures, not elliptic curve points 13:44 < elichai2> yeah lol, that's why it seemed even weirder 13:44 < sipa> and the reason G is used in the input is because that guarantees there is no known ratio between G and the outcome of that function 13:45 < sipa> if G wasn't used in the hash, it's possible that G secretly was chosen in function of the output of that function 13:45 < sipa> (without public knowledge) 13:45 < elichai2> oh rightt in CA you need to make sure there's no way to find some x such that x*G == commitment(a*G + b*H) 13:45 < sipa> i think you're confusing with just pedersen commitments; those don't need hash2curve 13:46 < elichai2> aren't they the reason for a second generator there? 13:46 < sipa> elichai2: the reason is just that maybe CA operations need to run on an HSM at some point, when signing for secret asset types 13:46 < sipa> elichai2: yes, you need a second generator for Pedersen commitments, but no hash2curve 13:46 < sipa> just single fixed static second generator 13:47 < elichai2> right 13:47 < sipa> but CA needs one generator per asset type 13:47 < sipa> and the assets are dynamic, so new generators need to be generated on the fly 13:47 < sipa> and in some scenarios, which aren't implemented, those generators may need to be computed from secret data 13:48 < elichai2> ohh 13:48 < sipa> so we chose a hash2curve function that actually can be implemented in a constant-time fashion, even if we don't care about the constant-timeness now 13:50 < sipa> elichai2: in any case, for random-looking taproot internal keys with no known DL, you don't need hash2curve 13:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 13:51 < elichai2> so how would you choose a random point that all participants in the taproot will agree it has no known DL? 13:51 < sipa> One example of such a point is ''H = point(0x0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)'' 13:51 < elichai2> (in the simple test I wrote I did the simplest possible thing, but that's for testing and temporary: https://github.com/elichai/bitcoin/commit/0fe34f3f09eb03b901f4f59e0bd5b4c804a161e3#diff-607598e1a39100b1883191275b789557R372) 13:52 < sipa> by taking the hash of G as X coordinate, if the hash is modeled as a random oracle, the resulting point has provably no DL w.r.t. G 13:52 < elichai2> sipa: (I assume that's the Generator compressed) this is a kind of hash2curve, (does this produce a valid x coordinate) 13:52 < sipa> elichai2: sure, but it can be computed just once in sage or whatever 13:53 < sipa> no need to have the entire function in secp256k1 13:53 < sipa> i agree that conceptually you're always somehow computing some hash2curve operation in order to construct additional generators 13:53 < sipa> but very few protocols need to actually do this at runtime 13:53 < elichai2> fair, altough you would want to use a good secp library that you know that it's working correctly. didn't say it's needed at run time 13:54 < elichai2> but yeah 14:01 < sipa> F=GF(2^256 - 2^32 - 977) 14:01 < sipa> E=EllipticCurve(F,[0,7]) 14:01 < sipa> G=E(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8) 14:02 < sipa> H=E.lift_x(Integer(hashlib.sha256(("04%064x%064x" % (G[0], G[1])).decode("hex")).hexdigest(), 16)) 14:02 < sipa> "02%064x" % H[0] 14:02 < sipa> > '0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0' 14:10 < elichai2> So i've basically done: 14:10 < elichai2> data=b'Bitcoin Test Framework' 14:10 < elichai2> data_hash = int.from_bytes(hashlib.sha256(data).digest(), 'big') 14:10 < elichai2> while data_hash >= SECP256K1_ORDER or not SECP256K1.is_x_coord(data_hash): 14:10 < elichai2> data_hash = int.from_bytes(hashlib.sha256(data_hash.to_bytes('big')).digest(), 'big') 14:10 < elichai2> p = SECP256K1.lift_x(data_hash) 14:10 < elichai2> But yeah I might replace that with this hardecoded H and comment that it's a hash of G 14:42 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 15:21 -!- roconnor [~roconnor@host-104-157-195-166.dyn.295.ca] has joined #secp256k1 20:02 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 20:06 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 20:07 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 20:25 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 20:25 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 20:30 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 20:30 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 20:37 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 20:42 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 21:14 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 21:14 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 21:31 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 21:31 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 22:05 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 22:05 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 22:08 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 22:15 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 22:59 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Ping timeout: 248 seconds] 22:59 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 23:07 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-chkqjvgluvzddzsc] has quit [Quit: Connection closed for inactivity] 23:12 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Ping timeout: 272 seconds] 23:13 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 23:25 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Ping timeout: 272 seconds] 23:25 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 23:32 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Ping timeout: 244 seconds] 23:38 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 --- Log closed Fri Aug 16 00:00:42 2019