--- Log opened Mon Jul 03 00:00:48 2023
00:55 -!- gnusha_ [~gnusha@user/gnusha] has quit [Server closed connection]
00:55 -!- gnusha [~gnusha@user/gnusha] has joined #secp256k1
00:55 -!- Topic for #secp256k1: libsecp256k1 development | https://github.com/bitcoin-core/secp256k1 | Logs: http://gnusha.org/secp256k1 | Developer meeting: Monday 15:00 UTC in every week with an odd ISO 8601 week number
00:55 -!- Topic set by real_or_random [sid554204@user/real-or-random/x-4440763] [Thu Jul 21 06:51:52 2022]
00:55 [Users #secp256k1]
00:55 [ achow101   ] [ FelixWeis_ ] [ jonasschnelli ] [ roconnor      ] 
00:55 [ ajonas     ] [ fjahr      ] [ jonatack2     ] [ RubenSomsen   ] 
00:55 [ andytoshi  ] [ ghost43    ] [ kanzure       ] [ sanket1729_   ] 
00:55 [ Apocalyptic] [ gnusha     ] [ katsu_        ] [ sgiath        ] 
00:55 [ ariard     ] [ harding    ] [ kcalvinalvin  ] [ sipa          ] 
00:55 [ b10c       ] [ hebasto    ] [ LarryRuane    ] [ siv2r         ] 
00:55 [ BlueMatt   ] [ HumanGeek  ] [ lightningbot  ] [ stickies-v    ] 
00:55 [ BlueMatt[m]] [ jarolrod   ] [ meshcollider  ] [ stratospher[m]] 
00:55 [ cfields    ] [ jb55       ] [ michaelfolkson] [ theStack      ] 
00:55 [ darosior   ] [ jeremyrubin] [ Nebraskka     ] [ user_         ] 
00:55 [ DeanGuss   ] [ jesseposner] [ nickler       ] [ waxwing       ] 
00:55 [ elichai2   ] [ jnewbery   ] [ p2plife-      ] [ windsok       ] 
00:55 [ fanquake   ] [ johnzweng  ] [ real_or_random] 
00:55 -!- Irssi: #secp256k1: Total of 51 nicks [0 ops, 0 halfops, 0 voices, 51 normal]
00:55 -!- Channel #secp256k1 created Wed May 19 12:44:13 2021
00:57 -!- Irssi: Join to #secp256k1 was synced in 152 secs
02:50 -!- sanket1729_ [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Server closed connection]
02:51 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined #secp256k1
04:11 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
04:26 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
04:29 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
04:46 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
05:07 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
05:13 -!- jonatack2 [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
05:14 -!- jonatack2 [~jonatack@user/jonatack] has joined #secp256k1
05:58 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
06:30 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
07:02 < real_or_random> meeting
07:02 < real_or_random> sipa nickler hebasto 
07:02 < hebasto> hi
07:04 < real_or_random> hm :D
07:05 < hebasto> one hour eariler?
07:05 < real_or_random> oops
07:05 < real_or_random> lol ok
07:06 < real_or_random> let's give them one more hour :D
07:09 < sipa> hi
07:09 < sipa> it's in an hour, right?
07:37 < real_or_random> yep
08:00 < real_or_random> now, meeting :)
08:01 < real_or_random> sipa nickler hebasto 
08:01 < hebasto> hi
08:01 < nickler> hi
08:02 < sipa> hi
08:02 < real_or_random> topics? :)
08:04 < real_or_random> did any of you follow the discussion in https://github.com/mit-plv/fiat-crypto/issues/1560#issuecomment-1615690066 ?
08:04 < nickler> real_or_random: how much of the signed digit PR did you review already?
08:05 < sipa> real_or_random: I have not.
08:05 < real_or_random> I stopped after the second commit, so I haven't looked at the main algorithm
08:06 < real_or_random> but hm, it's not even that much code 
08:06 < sipa> Have you ever reviewed the existing ecmult_const code? ;)
08:07 < real_or_random> parts of it (the skew etc)
08:07 < sipa> Sad, that part goes away :p
08:08 < real_or_random> so sad, yeah
08:08 < sipa> real_or_random: Is there a summary, or link to a latest comment, i should real about fiat/i128 stuff?
08:09 < real_or_random> let me try to summarize
08:10 < real_or_random> andres suggested to move fiat away from int128 support (and instead replace the few ops where it's necessary, e.g., 64x64->128 muls with other intrinsics)
08:10 < real_or_random> that makes it easier for their future plans
08:11 < real_or_random> and performance is apparently okay on clang, but suffers a bit on GCC
08:11 < real_or_random> I said that this makes fiat much less attractive for us because we went the opposite direction (using a struct to implement u128 if it's not natively available), and we care about GCC performance
08:12 < sipa> As in, they'd output effectively emulation of 128-bit multiplication, and rely on the compiler to map it to efficient arithmetic?
08:14 < real_or_random> no, they use only operations on 64-bit ints (e.g., mul outputs lo and hi)
08:14 < real_or_random> and then under the hood they can provide #ifdefs that implement the ops efficiently (e.g., using __int128 if available ^^)
08:15 < sipa> oh so using umulh etc?
08:15 < real_or_random> yep
08:15 < real_or_random> see the highlighted code here https://github.com/dderjoel/secp_bench/blob/master/mashup.h#L52-L125
08:17 < real_or_random> but after I provided feedback, andres suggested that they could help us because the current fiat code uses int128_t, so we'd  just need a way to output C code that calls functions (like mul in our abstract u128 implementation) instead of operators (like * )
08:17 < sipa> That doesn't look too different from what we're going, except at a lower level of abstraction.
08:17 < sipa> As in, fiat_secp256k1_dettman_mulx_u64 is the same as our secp256k1_u128_mul
08:18 < sipa> Except it passes arguments separately instead of combined in a struct.
08:18 < real_or_random> right. though apparently that makes a performance difference on GCC
08:18 < real_or_random> as least that's how I understand joel
08:18 < real_or_random> 's benchmarks
08:19 < sipa> Should we try if getting rid of the struct, and breaking it down into operations on int64s is equally fast or faster for us too?
08:21 < real_or_random> I'm a bit hesitant
08:21 < real_or_random> our int128 stuff is formally verified. we would throw that guarantee away (for now) 
08:22 < sipa> No, I'm not talking about changing anything semantically I think/
08:22 < real_or_random> and if they can offer something which is closer to our code, without a lot of work on their side, that sounds easier for us 
08:22 < sipa> Just wherever a function on the int128 type is called today, that argument is split into two 64 bit arguments - but the functions remains the same.
08:23 < real_or_random> I guess we could try but I expect that this has implications on performance somehow
08:23 < sipa> I'll try.
08:23 < sipa> I don't think it's too big a change.
08:23 < real_or_random> sure, if you're in the mood
08:24 < real_or_random> though andres also asks if we care about the performance of the C code on x86-64 then so much, given that we plan to have cryptopt asm
08:24 < real_or_random> and that's a good point too
08:24 < sipa> It is a good point.
08:25 < sipa> I'm not sure - practically speaking we really only care about x86-64 and aarch64 as 64-bit platforms./
08:25 < real_or_random> right
08:27 < real_or_random> btw, you that you mention aarch64
08:28 < real_or_random> https://github.com/bitcoin-core/secp256k1/pull/1163 made me wonder why if we still care about the arm32 asm
08:28 < sipa> I think we do; lots of people run Bitcoin Core on 32-bit raspberry pis etc
08:28 < real_or_random> a few years back when I proposed to remove this, this was controversial. 
08:28 < sipa> ... but we should make it non-experimental
08:29 < real_or_random> ok yeah, I don't know that the ecosystem is
08:29 < sipa> It's still noticably faster than what GCC compiles it to, IIRC.
08:29 < sipa> Much more so than on x86_64
08:30 < real_or_random> cryptopt doesn't support arm, right? :P
08:30 < sipa> It does not.
08:31 < sipa> It'd be nice if we can use cryptoline or something like that to formally verify the asm we have (I think it supports both x86 and arm).
08:32 < real_or_random> can you open an issue about making it non-experimental? 
08:32 < sipa> Yeah.
08:32 < real_or_random> then we can discuss there what we need. though I'm not sure
08:32 < real_or_random> if we want formal verification, then it will never happen (TM)
08:33 < sipa> Maybe.
08:34 < real_or_random> other topics?
08:35 < real_or_random> nickler: why did you ask about sd ecmult_const?
08:35 < real_or_random> just trying to coordinate review efforts?
08:36 < nickler> yes, my understanding was that this is one of the current priorities
08:41 < real_or_random> yep, I think it is. ^^ I'll try to look at this next, when I look at secp next time
08:42 < nickler> I have no other topics; I would like to open a PR for musig2 soon, but before we do that ideally we first bring secp-zkp up-to-date with upstream
08:43 < sipa> Cool.
08:44 < nickler> real_or_random: kk, sounds good! Just wanted to know if there's more review from you to come.
08:46 < real_or_random> ok, I think then end of meeting?
08:46 < real_or_random> unless we have more topics?
08:49 < sipa> Don't think so.
08:51 < real_or_random> ok, end of meeting
09:04 -!- kcalvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has quit [Server closed connection]
09:04 -!- kcalvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has joined #secp256k1
09:35 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
09:41 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
10:05 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:43 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:29 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
11:30 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:40 -!- jonatack2 [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.8]
11:40 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
11:44 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
12:23 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
12:33 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Read error: Connection reset by peer]
12:34 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 240 seconds]
12:35 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
14:29 < sipa> I wrote a patch to switch to representing the uint64s separately in the u128 functions, rather than in a secp256k1_u128 type, and it's noticably slowing things down, both in GCC and Clang.
14:30 < sipa> Some 5%, say.
14:30 < sipa> For ecdsa_verify.
14:31 < sipa> See https://github.com/sipa/secp256k1/commits/202307_128to2x64
14:31 < sipa> If someone else wants to benchmark.
21:15 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
21:16 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
22:12 -!- meshcollider [meshcollid@meshcollider.jujube.rpblc.net] has quit [Ping timeout: 245 seconds]
22:45 -!- meshcollider [meshcollid@jujube.rpblc.net] has joined #secp256k1
23:00 -!- meshcollider [meshcollid@jujube.rpblc.net] has quit [Ping timeout: 250 seconds]
23:30 -!- meshcollider [meshcollid@meshcollider.jujube.rpblc.net] has joined #secp256k1
--- Log closed Tue Jul 04 00:00:49 2023