--- Log opened Tue Nov 30 00:00:47 2021 06:24 < real_or_random> I really wonder why secp256k1_pubkey_load takes a context. Maybe it https://github.com/bitcoin-core/secp256k1/blob/aa5d34a8fe99b1f69306be20819f337dbd3283db/src/secp256k1.c#L237 06:25 < real_or_random> Maybe it's useful if we save pubkeys by serializing their dlog in the future... 06:27 < sipa> excellent idea 06:27 < sipa> it would simplify a lot of group arithmetic 06:28 < sipa> more seriously: ARG_CHECK needs a context, because it can call a context-provided callback 06:40 < real_or_random> oh indeed 06:40 < real_or_random> stupid macros. I eye-grepped the function for "ctx" 06:40 < roconnor> fool. 06:41 < real_or_random> :X 06:42 < real_or_random> it's a little bit strange though. we have ARG_CHECK mostly in the top-level API functions 07:55 -!- hg [~halosghos@user/halosghost] has joined #secp256k1 07:57 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host] 07:57 -!- waxwing [~waxwing@user/waxwing] has joined #secp256k1 08:45 -!- nickler_ [~nickler@static.219.205.69.159.clients.your-server.de] has quit [Ping timeout: 256 seconds] 08:46 -!- nickler [~nickler@static.219.205.69.159.clients.your-server.de] has joined #secp256k1 10:50 < robot-dreams> Hi, I have a question about the function `secp256k1_ecmult_odd_multiples_table` at https://github.com/bitcoin-core/secp256k1/blob/master/src/ecmult_impl.h#L64 10:50 < robot-dreams> When computing the table, why is it OK to drop the `d` coordinate of `z` and apply it to `a` instead? 10:50 < robot-dreams> Naively, it seems like `(a.x, a.y, a.z) + (d.x, d.y, d.z)` would give a completely unrelated result compared to `(a.x/d.z^2, a.y/d.z^3, a.z) + (d.x, d.y, 1)`. 10:51 < robot-dreams> I meant to say "drop the `z` coordinate of `d`" 10:56 < sipa> that sounds related to the effictively affine addition rule 10:57 < sipa> i need to swap the details in again, but iirc it means that if you want to add (x1,y1,z) + (x2,y2,z), then that's the same as adding (x1,y1,1) + (x2,y2,1), and then multiplying the z coordinate with z 10:57 < sipa> this isn't true for elliptic curves in general, but it is true for secp 10:59 < robot-dreams> Hmm, ok, I will try it using the addition formulas 11:03 < sipa> /* Calculate odd multiples of a. 11:03 < sipa> * All multiples are brought to the same Z 'denominator', which is stored 11:03 < sipa> * in Z. Due to secp256k1' isomorphism we can do all operations pretending 11:03 < sipa> * that the Z coordinate was 1, use affine addition formulae, and correct 11:03 < sipa> * the Z coordinate of the result once at the end. 11:03 < sipa> in src/ecmult_impl.h 12:59 -!- hg [~halosghos@user/halosghost] has quit [Read error: Connection reset by peer] 13:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection] 13:06 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1 13:10 < robot-dreams> Ah hah, 13:10 < robot-dreams> /** We need to calculate (rx,ry,rz) = (ax,ay,az) + (bx,by,1/bzinv). Due to 13:10 < robot-dreams> * secp256k1's isomorphism we can multiply the Z coordinates on both sides 13:10 < robot-dreams> * by bzinv, and get: (rx,ry,rz*bzinv) = (ax,ay,az*bzinv) + (bx,by,1). 13:10 < robot-dreams> * This means that (rx,ry,rz) can be calculated as 13:10 < robot-dreams> * (ax,ay,az*bzinv) + (bx,by,1), when not applying the bzinv factor to rz. 13:10 < robot-dreams> * The variable az below holds the modified Z coordinate for a, which is used 13:10 < robot-dreams> * for the computation of rx and ry, but not for rz. 13:10 < robot-dreams> */ 13:10 < robot-dreams> in src/group_impl.h 13:10 < robot-dreams> You also mentioned it here: https://github.com/bitcoin-core/secp256k1/pull/210#issuecomment-96166989 13:10 < robot-dreams> ``` 13:10 < robot-dreams> The isomorphism involved can be compactly written as: 13:10 < robot-dreams> (in affine coordinates): (a,b) + (c,d) = (e,f) <=> (a_t^2,b_t^3) + (c_t^2,d_t^3) = (e_t^2,f_t^3). 13:10 < robot-dreams> (in Jacobian coordinates): (a,b,c) + (d,e,f) = (g,h,i) <=> (a,b,c_t) + (d,e,f_t) = (g,h,i*t). 13:10 < robot-dreams> ``` 13:11 < robot-dreams> Just to make sure I understand correctly, (a) this isomorphism exists because a = 0 for secp256k1, and (b) the codomain is the curve Y^2 = X^3 + 7t^6? 16:30 -!- gnusha [~gnusha@user/gnusha] has joined #secp256k1 16:30 -!- Topic for #secp256k1: libsecp256k1 development discussion | https://github.com/bitcoin-core/secp256k1 | Channel logs: http://gnusha.org/secp256k1 16:30 -!- Topic set by real_or_random [] [Tue Jun 1 01:19:08 2021] 16:30 [Users #secp256k1] 16:30 [ andytoshi ] [ elsirion ] [ jamesob ] [ kcalvinalvin ] [ real_or_random] [ shiza ] 16:30 [ Apocalyptic] [ fanquake ] [ jesseposner ] [ laanwj ] [ robertspigler ] [ sipa ] 16:30 [ ariard ] [ FelixWeis] [ jnewbery ] [ lightningbot ] [ robot-dreams ] [ siv2r[m] ] 16:30 [ BlueMatt ] [ fjahr ] [ johnzwen- ] [ luke-jr ] [ rockhouse ] [ uasf ] 16:30 [ cfields ] [ ghost43 ] [ jonasschnelli_] [ meshcollider ] [ roconnor ] [ waxwing ] 16:30 [ darosior ] [ glozow ] [ kallewoof ] [ michaelfolkson] [ RubenSomsen ] [ windsok ] 16:30 [ DeanGuss ] [ gnusha ] [ kanzure ] [ Nebraskka ] [ sanket1729 ] [ yakshaver] 16:30 [ elichai2 ] [ harding ] [ kaushik ] [ nickler ] [ sebx2a ] 16:30 -!- Irssi: #secp256k1: Total of 47 nicks [0 ops, 0 halfops, 0 voices, 47 normal] 16:30 -!- Channel #secp256k1 created Wed May 19 12:44:13 2021 16:32 -!- Irssi: Join to #secp256k1 was synced in 143 secs --- Log closed Wed Dec 01 00:00:48 2021