--- Log opened Mon Dec 14 00:00:46 2020
00:14 -!- jessepos_ [~jp@2601:643:8980:bfd2:3cdc:b002:cf8:d4b2] has joined #secp256k1
00:15 -!- jesseposner [~jp@2601:643:8980:bfd2:3cdc:b002:cf8:d4b2] has quit [Ping timeout: 260 seconds]
00:16 -!- Netsplit *.net <-> *.split quits: wxss, dr-orlovsky, cfields, meshcollider, jonatack
00:22 -!- Netsplit over, joins: dr-orlovsky, jonatack, meshcollider, cfields, wxss
00:37 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 240 seconds]
00:54 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #secp256k1
03:01 < sanket1729> sipa: Is the new commit adding "avoiding modulas operations" explanation complete? Because it is giving me wrong answers locally. Or maybe there is some error in bounds calculation.
04:57 < sanket1729> A question about constant-timed operations? Are the CPU operations actually translated into constant time operations implemented at the hardware level?
05:19 < nickler> No they are not. Though most elementary operations are constant time. See https://github.com/bitcoin-core/secp256k1/pull/708#issuecomment-604354483 and https://github.com/bitcoin-core/secp256k1/pull/711.
05:43 -!- jesseposner [~jp@2601:643:8980:bfd2:7d7e:ee39:a576:2c3c] has joined #secp256k1
05:46 -!- jessepos_ [~jp@2601:643:8980:bfd2:3cdc:b002:cf8:d4b2] has quit [Ping timeout: 258 seconds]
05:54 -!- jessepos_ [~jp@2601:643:8980:bfd2:98c1:5a96:a9af:37d1] has joined #secp256k1
05:58 -!- jesseposner [~jp@2601:643:8980:bfd2:7d7e:ee39:a576:2c3c] has quit [Ping timeout: 260 seconds]
06:32 -!- deusexbeer [~deusexbee@079-170-137-107-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 246 seconds]
07:50 < andytoshi> what would be needed to "safely" use the same context objects in libsecp and secp-zkp
07:52 < andytoshi> i guess we'd need to literally link the projects together
07:57 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #secp256k1
08:00 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
08:01 -!- belcher_ is now known as belcher
08:18 < nickler> hm with our new -zkp approach, as long as -zkp is kept up to date you wouldn't have to use libsecp at all
08:19 < andytoshi> right, that's already how elements works
08:19 < andytoshi> but it's difficult for the rust-bindings because it's hard to do bitcoin stuff without a rust-secp dependency
08:19 < nickler> ...which would propagate well to the bindings, if rust-secp-zkp is a fork of rust-secp, because then you'd always use rust-secp-zkp
08:19 < andytoshi> and rust build infrastructure (or any build infrastructure does not give you a nice way to swap out a libsecp dependency for a secp-zkp dependency
08:20 < andytoshi> ok, it's maybe a uniquely rust problem that you can't swap out your dependencies' libsecp linkage for a secp-zkp linkage
08:21 < nickler> hm right, I guess rust-bitcoin exposes the context object which you wouldn't be able to reuse with rust-secp-zkp
08:21 < andytoshi> if we were dynamically linking maybe it could be done, but that's hard to do for bindings unless you have published versions and ABI promises
08:26 < nickler> instead of swapping out the secp linkage, couldn't you make rust-bitcoin depend on rust-secp-zkp instead, with feature flags?
08:26 < nickler> imo it's not terrible to recreate the context obj if you're using both rust-bitcoin and rust-secp-zkp
08:28 < andytoshi> ....that would be less controversial than making bitcoin core use secp-zkp instead...
08:28 < andytoshi> but that's not saying much
08:29 < andytoshi> the short answer is no, i will get tremendous pushback from trying to amke rust-bitcoin depend on my own experimental crypto library instead of the consensus one
08:30 < nickler> OTOH rust-bitcoin-zkp would be overkill
08:31 < andytoshi> yeah .. so ideally we could just somehow make rust-secp-zkp use the context objects from rust-secp
09:32 < sipa> sanket1729: no, i haven't tested any of what i've written
09:33 -!- deusexbeer [~deusexbee@079-170-137-164-dynamic-pool-adsl.wbt.ru] has joined #secp256k1
09:50 < sipa> sanket1729: there are lots of things in that explanation that don't appear in the paper
09:50 < sipa> sanket1729: eta instead of delta
09:51 < sipa> sanket1729: the way d and e are computed is completely different in the paper
09:52 < sipa> all the variable-time tricks
09:54 < sanket1729> Did you just type the code in comment without interpreting it in python?
09:54 < sanket1729> because it works and tests well on my local machine :P
09:55 < sipa> yes, i've never executed any of that code
09:55 < sanket1729> Wow
09:56 < sanket1729> The python code works correctly. I could not test the constant time one becuase it relies on 64 bit representation et
09:56 < sipa> i mean: it's ultimately the same as the C code, at some level of abstraction, which works
09:56 < sipa> the constant time code should also work
09:56 < sipa> python integers work like C ints of infinite size
09:56 < sanket1729> Does it not assume that first bit is sign bit etc
09:56 < sanket1729> ah
09:57 < sipa> e.g. -1 is $infinity 1 bits, semantically
09:57 < sipa> so (x >> 63) is -1 if x was a number between -2^63 and -1 incl
09:58 < sipa> i should explain that probably
09:59 < sanket1729> Does (u & (d >> 63)) return u if d>> 63 is 1. I think that will return 1 instead of u
09:59 < sipa> it will return u if d is negative
09:59 < sipa> because -1 is all 1 bits
10:00 < sanket1729> nice
10:00 < sanket1729> I get it
10:00 < sipa> sanket1729: so in the paper, the  u v q r matrices are matrix-multiplied together as integers, recursively in a divide-and-conquer
10:01 < sipa> that gives you a 256-bit matrix at the end, and one of its coefficients, multiplied by modulus^-1 mod 2^256, is d
10:02 < sipa> dettman figured out that just locally completely updating d is faster
10:02 < sipa> i.think the paper's approach is asymptotically faster
10:02 < sipa> but for our sizes (just 5 or 9 limbs), this is better
10:17 -!- jessepos_ [~jp@2601:643:8980:bfd2:98c1:5a96:a9af:37d1] has quit [Quit: Textual IRC Client: www.textualapp.com]
10:18 -!- jesseposner [~jp@2601:643:8980:bfd2:98c1:5a96:a9af:37d1] has joined #secp256k1
10:45 -!- jonatack [~jon@134.19.179.139] has quit [Quit: jonatack]
10:52 -!- jonatack [~jon@88.124.242.136] has joined #secp256k1
10:53 < sanket1729> sipa: I think I found a bug in the constant time normalization part.
10:53 < sanket1729> test vector
10:53 < sanket1729> https://gist.github.com/sanket1729/1b85a233452b0fc83ff3a7781ae48543
10:55 < sanket1729> I also changed line #5 to (sign -1) instead of sign + 1 which I think was another bug
10:57 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 264 seconds]
10:58 -!- jonatack [~jon@134.19.179.195] has joined #secp256k1
11:00 < sipa> yup
11:02 < sipa> if you change the shift to 257, does it work?
11:03 < sanket1729> yes
11:04 < sipa> awesome, thanks
11:04 < sanket1729> But I would reconvince myself about the bounds then
11:05 < sipa> you can change it to ">> 500" if you like, instead
11:05 < sanket1729> I see, the normalize in non constant time should check the v < - modulus then
11:12 < sipa> sanket1729: pushed some fixes
11:15 < sanket1729> awesome. Looks great. I think comment has great explanation. Will look at the C code next based on the high level code and explanation.
12:03 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-cndlteukbokvnpjt] has quit [Ping timeout: 264 seconds]
12:03 -!- digi_james [sid281632@gateway/web/irccloud.com/x-vjrjbdfohnkqvcae] has quit [Read error: Connection reset by peer]
12:03 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-hsbvpmeoieudooak] has quit [Ping timeout: 258 seconds]
12:04 -!- digi_james [sid281632@gateway/web/irccloud.com/x-ckjfcboybjfhlvon] has joined #secp256k1
12:04 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-fpkuvfihnixtfrzh] has joined #secp256k1
12:06 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-erppcjnosclqbarw] has joined #secp256k1
16:08 -!- jesseposner [~jp@2601:643:8980:bfd2:98c1:5a96:a9af:37d1] has quit [Quit: Textual IRC Client: www.textualapp.com]
19:22 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 240 seconds]
19:43 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #secp256k1
22:10 -!- jonatack [~jon@134.19.179.195] has quit [Read error: Connection reset by peer]
22:16 -!- jonatack [~jon@88.124.242.136] has joined #secp256k1
--- Log closed Tue Dec 15 00:00:48 2020