--- Log opened Fri Dec 04 00:00:36 2020
05:41 < nickler> apparently ec_pubkey_combine is used in clightning to compute the revocation pair
05:41 < nickler> revocationpubkey = revocation_basepoint * SHA256(revocation_basepoint || per_commitment_point) + per_commitment_point * SHA256(per_commitment_point || revocation_basepoint)
06:38 < andytoshi> sipa: almost everything is a group :) lattices form groups but you can still find QC-hard problems with them
06:38 < andytoshi> the issue is cyclic groups
08:05 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1
08:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
08:30 -!- reallll is now known as belcher
08:40 < sipa> andytoshi: right
08:55 -!- jessepos_ [~jp@2600:380:c010:4d5b:595a:9185:2152:9cb8] has joined #secp256k1
08:57 -!- jessepos_ [~jp@2600:380:c010:4d5b:595a:9185:2152:9cb8] has quit [Client Quit]
08:57 -!- jessepos_ [~jp@2600:380:c010:4d5b:595a:9185:2152:9cb8] has joined #secp256k1
09:00 -!- jesseposner [~jp@2601:643:8980:bfd2:21a3:28f3:d78:7f10] has quit [Ping timeout: 264 seconds]
09:24 -!- jesseposner [~jp@2601:643:8980:bfd2:888:c250:4010:2f1e] has joined #secp256k1
09:28 -!- jessepos_ [~jp@2600:380:c010:4d5b:595a:9185:2152:9cb8] has quit [Ping timeout: 240 seconds]
19:13 -!- Netsplit *.net <-> *.split quits: midnight
19:18 -!- Netsplit over, joins: midnight
19:26 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Max SendQ exceeded]
19:28 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #secp256k1
19:33 -!- jessepos_ [~jp@2601:643:8980:bfd2:d437:5b18:4154:8907] has joined #secp256k1
19:36 -!- jesseposner [~jp@2601:643:8980:bfd2:888:c250:4010:2f1e] has quit [Ping timeout: 264 seconds]
19:41 -!- jesseposner [~jp@2601:643:8980:bfd2:919a:9c07:5dbc:913c] has joined #secp256k1
19:45 -!- jessepos_ [~jp@2601:643:8980:bfd2:d437:5b18:4154:8907] has quit [Ping timeout: 260 seconds]
22:11 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #secp256k1
22:12 < virtu> hi. I'm looking for an easy way to benchmark the sigops performance of different architectures with secp256k1. is bench_verify a good place to start?
22:14 < virtu> it seems like bench_verify only uses a single thread. is that correct?
22:14 < virtu> (makes sense, when trying to benchmark the latency of one signature)
22:15 < virtu> is there an easy way to measure throughput (sigs/s)?
22:22 < sipa> virtu: run bench_verify multiple times in paralle
22:23 < sipa> libsecp256k1 is entirely thread neutral
23:46 < virtu> sipa: thanks, I can try that, although I worry about desynchronization in case of large numbers of threads
23:46 < virtu> I want to make sure all threads are in the compute-intensive part at the same time, so the estimate is meaningful
23:47 < virtu> in case of desync., some threads might sustain a higher frequency in the benchmark phase than would be possible if they were all simultaneously in the benchmark phase
23:48 < sipa> you seem to have said the same thing twice
23:48 < sipa> not sure what you mean by desybc
23:48 < sipa> desync
23:49 < virtu> if I just run the binary x times, there's no guarantee that the x threads will simultaneously start and end the benchmark
23:50 < sipa> while true; do ./bench_verify; done :)
23:50 < sipa> just keep them running in a loop
23:50 < virtu> the performance of each thread depends on the frequency of the core its running on; if some threads haven't started the compute-intensive part yet, the other cores get a higher share of the processor's TDP and can clock higher
23:51 < virtu> then these threads finish with a higher frequence, thus higher performance; then the other threads start, and since the previous ones are already finished, they also get a higher freq.
23:51 < virtu> thus the performance would be overestimated
23:51 < sipa> yes, so keep all cores busy the whole time
23:52 < virtu> ok, I'll try that, thanks
--- Log closed Sat Dec 05 00:00:36 2020