Per core, I'm getting 4.8 MK/s with single Base58 address… Maybe that's close to Hash160 speed. @Nomachine, may i know the speed of a single core with Hash160?
4.8 MK/s per core, on a CPU, to do RIPEMD160(SHA256(...)) is pretty impressive. But even running the hashing on an empty buffer in a loop (no EC involved at all, simply hashing) is much slower than the actual EC throughput (12 MK to maybe 20 MK/s per core, using libsecp256k1), so it is futile to optimize that part until the hashing speed itself catches up. Currently, that means that H160 needs a 3x to 4x boost up in speed, which I find unlikely to ever happen (if it does, most likely the EC throughput would also be boosted up proportionally).
If low-level custom firmware can be developed to give us direct access to the ASIC’s SHA-256 hashing function (without its built-in mining logic), then this approach could work. We could offload the SHA-256 part to the ASIC while handling the rest on the GPU/CPU, creating a hybrid GPU + ASIC system for Bitcoin address generation.
However, there are 2 major obstacles 1st ASICs are built for a single, highly optimized task (Bitcoin SHA-256 hashing). They deliver extreme speed and efficiency, but they don’t support RIPEMD-160 hashing, meaning we would still need a GPU or CPU for that step. This makes the overall speed gain questionable.
2nd Even if the ASIC operates at full potential, the real question is whether we can transfer data fast enough between the ASIC and GPU/CPU to maintain efficiency.
Even if we successfully solve both hashing optimization and data transfer issues, there’s another problem: As you say :
The EC throughput also scale up proportionally? You seem confident about this, but I have my doubts. If EC operations remain the bottleneck, then optimizing hashing alone wouldn’t provide the expected speed boost.What do you think? Would solving hashing and transfer limitations truly lead to a proportional increase in EC throughput?