--- Log opened Thu Sep 17 00:00:21 2020
00:12 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 244 seconds]
01:02 -!- jonatack [~jon@37.166.18.142] has joined #secp256k1
01:21 -!- jonatack [~jon@37.166.18.142] has quit [Ping timeout: 240 seconds]
01:21 -!- jonatack [~jon@213.152.162.181] has joined #secp256k1
03:35 -!- jonatack [~jon@213.152.162.181] has quit [Ping timeout: 256 seconds]
04:19 -!- jonatack [~jon@37.166.18.142] has joined #secp256k1
06:20 -!- jonatack [~jon@37.166.18.142] has quit [Read error: Connection reset by peer]
06:21 -!- jonatack [~jon@37.166.18.142] has joined #secp256k1
07:22 -!- jonatack [~jon@37.166.18.142] has quit [Read error: Connection reset by peer]
09:00 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #secp256k1
09:27 -!- real_or_random [~real_or_r@173.249.7.254] has quit [Quit: ZNC 1.7.5 - https://znc.in]
09:29 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has joined #secp256k1
13:52 < instagibbs> andytoshi, on my machine it basically doubled my sync time IIRC(signatures to latest assumevalid checkpoint)
13:52 < instagibbs> so I'd expect a 20-30% drop on the doubling
13:59 < andytoshi> instagibbs: o.O
14:00 < andytoshi> that's much better than i'd have expected
14:00 < sipa> doubled? what?
14:02 < instagibbs> I did a dry IBD a few times.... could be specific to my laptop?
14:03 < instagibbs> assumevalid off vs whatever it's checkpointed to in master
14:03 < sipa> instagibbs: wait, what are you comparing exactly?
14:03 < instagibbs> contrasting IBD total time with and without signature validation of most the chain
14:04 < sipa> oh!
14:04 < instagibbs> sorry!
14:04 < sipa> i thought you were claiming endomorphism was a 2x speedup
14:04 < sipa> how much IBD is with and withoit assumevalid heavily depends on how far in the past the assumevalid point is
14:05 < instagibbs> I probably should have just picked tip for the on-run :shrug:
14:05 < sipa> it needs to be 2 weeks deep or so
14:05 < sipa> there is a check
14:06 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
14:07 < instagibbs> either way, it was "a lot" for me
14:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
14:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
16:52 < ariard> is there any reference paper on endomorphism ? like "Efficient software implementation of public-key cryptography on sensor networks using the MSP430X microcontroller" is the one?
16:58 < sipa> ariard: the reference we used when implementing it is from a book, i believe, cited in the source code
16:59 < sipa> but conceptually it's very simple: there exist specific values of lambda and beta such that for every point (x,y), it is the case that lamdba*(x,y) = (beta*x,y)
16:59 < sipa> (very similar to how it is the case that -1*(x,y) = (x,-y) for every (x,y))
16:59 < sipa> where lambda and beta are nontrivial cube roots of 1 modulo the group order and the field size, respectively
17:01 < sipa> this allows you to rewrite a*P as a1*P + a2*Q, where a1 and a2 are 129-bit numbers, and a1+a2*lambda=a, and Q=lambda*P (which can be efficiently computed, as it's just multiplying the X coordinate by beta)
17:02 < sipa> so you halve the size of the scalars, and double the number of points - getting you something similar to the gains from multi-multiplication
17:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 272 seconds]
17:50 < ariard> sipa: okay and lambda is a constant for every point you don't have to recompute it?
17:51 < ariard> following the big comment in the code about lambda
17:52 < sipa> ariard: yes, lambda and beta are constants that depend on the curve parameters only
17:54 < ariard> ah is there more information on how they're selected and their properties ?
17:56 < ariard> but thanks for the answer, I'll dig on sounds so a nice improvement :)
17:59 < sipa> lambda and beta are just cube roots of 1
17:59 < sipa> (modulo the group order, and modulo the field size)
18:53 -!- roconnor [~roconnor@host-184-164-25-9.dyn.295.ca] has joined #secp256k1
18:54 < roconnor> So I see that a2 and b2 from https://gist.github.com/gz-c/bf70ce96b2488e5ccca65900086c75f5#file-gistfile1-txt-L40-L43 are computed by running the GCD algorithm between n and lambda and stopping half way.
18:55 < roconnor> And I see that they have roughly half as many bits as n.
18:55 < roconnor> But I'm still puzzlend as to what these particular values achive.
18:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
19:01 < roconnor> I though this ration would be approximately the ratio of n/lambda because I though the caculation was equivalent to truncating the continued fraction representation of n/lambda, but that doesn't seem to be the case.
23:33 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds]
23:39 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #secp256k1
23:42 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
23:53 -!- wallet42__ [sid154231@gateway/web/irccloud.com/x-kglqdbvrlpwzgiep] has quit [Ping timeout: 240 seconds]
23:53 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-cecollifvvxehwzf] has quit [Ping timeout: 260 seconds]
23:53 -!- digi_james [sid281632@gateway/web/irccloud.com/x-cziqtxzbhovrsgzp] has quit [Ping timeout: 240 seconds]
23:53 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-jkeelzewuuuzwtst] has quit [Ping timeout: 240 seconds]
23:56 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-bfjrmzfumzpxezas] has joined #secp256k1
23:56 -!- wallet42__ [sid154231@gateway/web/irccloud.com/x-kmodawzjplmhfcoq] has joined #secp256k1
23:56 -!- digi_james [sid281632@gateway/web/irccloud.com/x-onkyiigagbyecwyz] has joined #secp256k1
23:56 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-emezvqtpooboqkzz] has joined #secp256k1
--- Log closed Fri Sep 18 00:00:22 2020