I think counting a single execution each time and then making an average/median could be skewering the results.
Is it not possible to execute the code 100,000 times and count the final time instead?
Well, I could be wrong tho
this is not my benchmarks this is when i’m integrating shim there using thier benchmark tools not mine all this measurment are knuth harness benchmarks not mine
1 Like
It’s typical to do it like you say (timestamp, execute many times, timestamp) and then report the average for 1 execution. If report shows per-execution, it doesn’t mean it was just 1 execution that was measured.
Yeah you could be right.
However it is presented in a way that makes it look like that’s how it happened 
never trust me take anything from repo and reproduce your self all is avalible in repo for tests benchmarks you can test and reproduce anything by your self. all things are documented and avalible i’m not hiding anything
1 Like
Yeah, I am not actually accusing you of anything.
You asked basically “how can the benchmarks be improved”, so I am answering.
Sorry if I came off as aggressive, that’s not intentional, this is the normal way I discuss, I mean no harm.
I am wired differently and have mental pain levels set higher than most people so even when I discuss “normally” from my Point Of View, people sometimes feel like I am being aggressive.
i don’t mean this. i’m trying to say that i’m not searching authority i want that we all together improove system and make it much better then it’s now. thats what i mean dont trust me i dont need trust need real outsider reviews because outisders can find that problems what may be i missed.
Anyway, so what does “shim” mean in this context?
You say things like “bch shim”, I have no idea what that means.
A shim is a thin compatibility layer that translates one library’s API to another implementation underneath. In this case, it exposes the exact same secp256k1.h header that libsecp256k1 uses, but routes all calls to UltrafastSecp256k1’s engine internally. Zero code changes required in the host project
1 Like
Welcome to BCH research! It is a small community and everyone is very busy, but glad to have you here and contributing! Your work definitely looks useful.
Keeping mobile optimised for speed is going to be super key for BCH as the transaction volume starts to ramp up and people just expect to use it with no issues. We don’t have the luxury of offloading to L2s, it just has to all work and work fast on L1.
@Bastian is working on this kind of stuff. Might be a good crossover! See here: Confidential Transactions - #10 by Bastian
also @fpelliccioni from Knuth is very interested in these kinds of optimisations and might like to look at this.
1 Like
Thanks, I really appreciate the context and the pointers.
That L1 point makes sense to me: if BCH wants high-volume usage directly on L1, then wallet/mobile performance and reusable-address/privacy workloads need to stay practical without relying on offloading.
I’ll look into Bastian’s Confidential Transactions work and the Knuth side as well. Knuth is especially interesting because I already have an A/B shim benchmark using Knuth’s own benchmark tooling, so that may be a good place to start with a clean, reproducible integration path.
My preferred first step is still conservative: standalone benchmark/workload first, then docs, then optional integration discussion. No forced replacement, no consensus change — just a measurable path for projects that want to evaluate faster secp256k1 execution.
1 Like
@shrec re: privacy and reusable addresses, the focus has been on how to do that in a post quantum (pq) resistant fashion, which is currently quite challenging.
since rpa is based on ecdh, it’s not currently seen a viable implementation for privacy in pq era and the question is now what to use instead? the challenge there is also, which offer reusable addressing?
some food for thought
That’s fair. If the requirement is “post-quantum reusable addressing as the final design”, then ECDH-based RPA is not the endgame.
But I think these are two different timelines.
Today, BCH still uses secp256k1. If secp256k1 becomes practically unsafe, the problem is much larger than RPA: signatures, wallets, existing coins, address reuse assumptions, and migration rules all need to change.
Until that migration path exists, I think current-era privacy/reusable-address designs are still worth evaluating. RPA may not be the final PQ answer, but it can still be a practical workload for today’s BCH ecosystem — especially for mobile/L1 usability.
So I’d separate the questions:
- What can improve privacy and reusable-address UX today under the current secp256k1 model?
- What should replace that model in a future PQ migration?
Both are important, but I wouldn’t block current privacy work on a PQ design that the ecosystem cannot yet deploy or test in practice.
Thanks for tagging Fernando.
For Knuth specifically, I already built a shim and ran an A/B benchmark using Knuth’s own tooling. My goal is not to ask for a default replacement, but to provide a clean optional evaluation path: build it, run the same benchmarks, inspect the shim, and decide based on reproducible results.
I’ll prepare a Knuth-specific integration note after the v3.69 release so the benchmark can be reproduced independently.
yes, it’s a complex question. there has been extensive work evaluating this from an RPA perspective https://github.com/00-Protocol/BCH-Stealth-Protocol/tree/main
and in my thread above, there is a pq path towards privacy demonstrated on chipnet today where amounts are hidden. if paired with cashfusion, identity may also be shielded.
so it’s not so much that pq is blocking privacy development as it is how are the questions being created by that work getting answered? for example, reusable addresses with ml-kem-768
I personally didn’t run into any performance issues with secp256k1. what have you experienced?
regarding the RPA “grind” I believe the bottleneck there is electrum/fulcrum performance
Thanks, that makes sense — I’ll read through the BCH Stealth Protocol work.
I agree that PQ privacy/reusable-address research is important, especially if the goal is a long-term design rather than only a current-era secp256k1 design.
The distinction I’m trying to make is mostly about timelines and deployment targets:
-
Current production BCH still runs on secp256k1, so RPA/ECDH-style workloads can still be useful to evaluate for today’s wallet/mobile/L1 performance and privacy UX.
-
PQ reusable addressing is a separate research/migration track. ML-KEM-768 or hybrid designs may be the right direction, but that needs its own engineering work: address format, key size/UX, wallet scanning model, compatibility, migration, and testnet/chipnet validation.
So I don’t see these as mutually exclusive. RPA may not be the final PQ answer, but it can still be a useful current-era workload. In parallel, PQ reusable addressing should be explored as the future-facing track.
For my library, the immediate relevance is: if a design has heavy EC workloads today, I can help benchmark/optimize that. If the future design uses ML-KEM or hybrid primitives, that’s probably a separate module/track rather than something I would mix into the secp256k1 engine directly.
Fair point. I’m not claiming that secp256k1 is currently the main BCH bottleneck in normal node operation.
What I have so far are A/B integration benchmarks showing that the same secp256k1 workloads can be executed significantly faster through the shim in several existing codebases. That does not automatically mean those workloads are the current production bottleneck.
For RPA specifically, if the main bottleneck is Electrum/Fulcrum indexing/scanning rather than raw EC operations, that is useful information. Then the right next step is not to claim “secp256k1 is the bottleneck”, but to build a workload-level benchmark:
- wallet-side RPA scan/grind cost
- Electrum/Fulcrum query/indexing cost
- EC operation cost inside the pipeline
- mobile/client-side constraints
- batching opportunities
My interest is mostly in identifying where faster EC execution becomes useful, not forcing it into places where it is not the limiting factor.
So if you have a good RPA benchmark path or a pointer to where Fulcrum/Electrum spends time, I’d be interested in testing that directly.
2 Likes
A 60-80% signing time reduction is quite significant! The problem with novel cryptographic libs in general, though, is safety: The engine is so central to everything, people would likely want not just intense scrutiny but also a proven track record… The track record part faces a harsh chicken and egg problem.
As others kind of mentioned up there, RPA may help you solve the chicken and egg problem of track records, since it’s a sufficiently small niche yet is significant enough to attract some significant attention. The grind may not the current biggest bottleneck, but then the current implementation is nowhere near ideal and neither is the grind target bits - imo it should be grinding more bits given current traffic so the indexer doesn’t need to transmit as much stuff.
This is probably a huge ask, but if you feel confident enough, the best path forward might be to directly help out the RPA project even for the parts not directly related to your lib. More popularity, less unrelated bottlenecks, higher likelihood for more track record.
1 Like
That makes sense. After I finish the current release/PR package, I’m planning to look at the full RPA pipeline directly.
I don’t want to treat it as only an EC primitive problem. I’d rather measure the whole path, identify the real bottlenecks, optimize what can be optimized, and then return a working, reproducible solution with benchmarks and documentation.
If the bottleneck is the indexer, that should be improved. If the EC layer matters, that should be measured too. The useful result is not a claim — it is a better RPA pipeline that others can test.
1 Like