--- Log opened Tue Apr 09 00:00:22 2024
01:43 < setavenger> josie: So I ran the benchmarks and it seems that on both my phone and if I do a simpler benchmarking on my laptop the libsecp256k1 module is a bit slower.
01:43 < setavenger> Running the benchmarks on my laptop, without any label and filter-matching stuff, purely getting serialised x-only pubkeys, resulted in my implementation being about 12% faster.
01:43 < setavenger> On my phone the benchmarking included matching against a filter and labels (which in hindsight were not exhaustive computed), then we're looking at ~26 % speed reduction when using my quite bare bones implementation. 
01:43 < setavenger> About the problem I've encountered while computing labels. With x-only keys, as given in the libsecp256k1 SP-Module, we have to do some conversions to a full pubkey, which takes some additional computation. 
01:43 < setavenger> But thinking about this a bit more I don't think one can just use the pubkey and add the label to match against a filter. I think one actually has to check the negated pubkey as well.
01:43 < setavenger> So we have to check both `Pk + label = output` and `Pk - label = output`.
01:43 < setavenger> I would disregard the phone benchmark for now until I've figured out how to best handle labels. But I do think it shows a direction as it does give some insight on the overhead when converting between `secp256k1_xonly_pubkey` and `secp256k1_pubkey`.
03:20 -!- rafael_xmr [~rafael_xm@2804:6500:1002:46:3782:bfa0:64c2:3114] has joined #silentpayments
05:56 < setavenger> josie: I was able to optimise your implementation to get into about ~3% distance from my implementation, which leads to ~9% reduction in time needed for that specific benchmarking setup. Made a PR.
06:41 < josie> setavenger: regarding xonly vs compressed for the labels, it should be possible to first convert both to group elements, but that also has overhead so I'm not sure if its strictly better. I'm not sure about needing both pk + label and pk - label, but I need to revisit this since its been awhile since I've thought about it.
06:43 < josie> regarding the benchmark, thanks for the benchmarking! the speedup is because you are using ec_mult, which is not constant time, vs us using secp256k1_ecdh, which is constant time. Personally, I think its open to debate whether we _need_ constant time for the ecdh step, so having some concrete numbers helps a lot 
08:45 < setavenger> josie: I'll think about it as well. 
08:45 < setavenger> I'm not deep enough to really participate on the debate whether one needs constant time or not but happy to do some leg work with regards to benchmarking if new ideas/versions come up. I'm trying to find the best UX for users. For long scans 10% time reduction is already a lot.
17:42 -!- S3RK [~S3RK@user/s3rk] has joined #silentpayments
17:45 -!- S3RK_ [~S3RK@user/s3rk] has quit [Ping timeout: 264 seconds]
19:51 -!- rafael_xmr [~rafael_xm@2804:6500:1002:46:3782:bfa0:64c2:3114] has quit [Remote host closed the connection]
--- Log closed Wed Apr 10 00:00:23 2024