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
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.
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.
@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:
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:
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.