S.O Finder

[SupremeTrinity]

What if we created a mini operating system, basic but designed solely for finding private keys?

It might be a good idea, though a bit insane, since any operating system runs beneath any program—partly for security and hardware integrity reasons. It limits program performance to a safe level.

The idea of creating a mini OS sounds interesting to me, as this way we would have full access to the hardware and wouldn’t face any security restrictions or anything else that could hinder the program’s execution—aside from obvious hardware limitations.

[NotFuzzyWarm]

We already have it - Linux. Available in many different forms it can be tailored to any application you want. It is free of any hardware restrictions you think exist.

[SupremeTrinity]

Linux still has many limitations. Any common operating system doesn’t allow you real and total access to all the processor’s resources with full efficiency—they at least run alongside your program, sharing processing power.

My idea is to create a system stripped of anything that could take even the slightest bit of processing power away from the program itself, leveraging every CPU cycle to the fullest.


And yes, Linux, for security reasons, does not give you full access to your computational power. And even if someone finds a way to make it grant that access, it’s still an operating system that runs alongside your program, consuming processing power that could otherwise be used by your program.

[NotFuzzyWarm]

Then you are talking about writing a program in CPU-specific microcode aka assembler that runs directly on the CPU. Good luck with trying that for modern multi-core CPU's and GPU's.

For what it's worth, stand-alone programs CAN be written to directly access lowest levels of the CPU operations (ring-0 and ring-1) that a normal OS runs on top of - they are usually called drivers for specific functions and RTOS's for multiple functions.

[ABCbits]

If you have resource to do that, consider buying FPGA and program it (or hire FPGA programmer) instead.

[kTimesG]

This is what CUDA is for. The shader assembly code runs directly on the GPU's hundreds of billions of transistors, with no overhead of any OS hardware management; so you can consider that microcode as the "operating system" if you truly know what you want to do.

If that's not enough you need to design an FPGA or ASIC, to program the logic circuit to do what you need (basically construct your own microprocessor from scratch). Then the only limit is the semiconductor manufacturing process (nanometer distance between positive and negative charged areas of each transistor) and of course your engineering skills to take maximum advantage of the way current flows through the wires.

All of the above are easier than creating a new OS.

[SupremeTrinity]

The idea of an ASIC is good, but the problem is its price—it’s an unfeasible investment for many people. My idea of an OS is to eliminate this price issue and use the potential of a regular computer for this search. It would be more like a mutual benefit as an open project. However, it’s understandable that it might not be well-received by the community, as it would be a massive undertaking, even though the idea isn’t to build an entire system.

It’s more like creating a basic, ultra-powerful calculator solely for Bitcoin searching, with nothing sharing even the slightest percentage of processing power with anything unnecessary, making full use of every CPU cycle. Anyway, it’s a crazy idea, but I see it as a good one, even if insane. 

[NotFuzzyWarm]

So as said above - program a FPGA for it. Things like this are precisely what they are made for. They give the speed of a dedicated ASIC without the huge design & production costs involved. FPGA's are readily available and price is on par with a moderately priced PC using a decent CPU while being far faster when programmed right.

[ABCbits]

The idea of an ASIC is good, but the problem is its price—it’s an unfeasible investment for many people. My idea of an OS is to eliminate this price issue and use the potential of a regular computer for this search. It would be more like a mutual benefit as an open project. However, it’s understandable that it might not be well-received by the community, as it would be a massive undertaking, even though the idea isn’t to build an entire system.

That's why i only mentioned FPGA, due to lower entry barrier. Writing new OS or assembly code in order to use CPU effectively seems inefficient when,
1. FPGA have better parallel computation compared with CPU.
2. FPGA have higher power efficiency compared with CPU and GPU.

It's also worth to mention price of entry level FPGA similar with SBC (single board computer). For example, bundle of Intel Altera MAX10 only costs $68[1].

[1] https://www.amazon.com/Intel-Altera-MAX10-FPGA-Package/dp/B07L6ZT267

[kTimesG]

It’s more like creating a basic, ultra-powerful calculator solely for Bitcoin searching, with nothing sharing even the slightest percentage of processing power with anything unnecessary, making full use of every CPU cycle. Anyway, it’s a crazy idea, but I see it as a good one, even if insane. 

Today's (and yesterday's) CPUs are not designed to be used in real-mode operation, those times passed away many decades ago (MS-DOS days). A new OS to handle a CPU needs to be like any existing OS that handles a CPU, because there are a ton of things to be careful at (even hardware bugs in the CPU that need workarounds at the OS level), which is what an OS does.

And then, a CPU is a generic piece of silicon with a few dedicated ops (arithmetic units for a few data sizes, maybe vector units, floating points, etc. - definitely NOT what you need to break Bitcoin), so you'll likely have just around 0.001% improvement in speed by creating an "OS that runs just that code" - because existing OSs already offer ways to run a process exclusively an a CPU core, for maximum performance, with no wasted cycles.

My point is that even an ASIC, even as expensive as it is, is a much cheaper and faster way then recreating a perfectly round wheel, with a ROI of a few magnitudes of performance higher, than any un-wasted CPU cycles.

[SupremeTrinity]

So, since an FPGA is so much cheaper and can be customizable (configurable) at the hardware level, why hasn’t anyone been using it?

[kTimesG]

So, since an FPGA is so much cheaper and can be customizable (configurable) at the hardware level, why hasn’t anyone been using it?

Who says they didn't? Maybe you didn't search hard enough?

Just an example: https://github.com/ZcashFoundation/zcash-fpga

Bitcoin uses the same secp256k1 curve as most other cryptos.

[SupremeTrinity]

And what is the average speed a program like this can reach? Considering the investment, it would need to achieve a speed greater than running it on a computer.

[kTimesG]

And what is the average speed a program like this can reach? Considering the investment, it would need to achieve a speed greater than running it on a computer.

You don't have "programs" when dealing with FPGA - it's simply run electronically by the hardware itself, it is not software. The speed is determined by how it is engineered, generally hundreds to thousands of times faster than a CPU, at the same power consumption, and tens of times faster than a GPU (which is still software at some high degree).

[SupremeTrinity]

So why are so many people still programming for GPUs instead of investing in FPGAs? Since FPGAs are so much better in terms of both price and performance, maybe it's because of the number of threads? 

[kTimesG]

So why are so many people still programming for GPUs instead of investing in FPGAs? Since FPGAs are so much better in terms of both price and performance, maybe it's because of the number of threads? 

Everything comes with a price. Are you actually able to find someone to create a FPGA design, after you have acquired your FPGA? It is not like you buy it on Amazon and flash it with something you find on Github, and then expect miracles. It takes a tremendous effort to suit it to your needs / problem, generally you'd want to hire a very skilled hardware engineer that is also an expert in cryptography / modular math and several other fields. These are the guys that work at Intel or TSMC's next-gen chips, not some users on a forum.

Meanwhile GPUs are scalable and easily programmable - e.g. a task that can be handled by your everyday software engineer.

So these are two very different problems, with very different tradeoffs. Performance does not come for free, it has its price.

[ABCbits]

So why are so many people still programming for GPUs instead of investing in FPGAs? Since FPGAs are so much better in terms of both price and performance, maybe it's because of the number of threads?  

Everything comes with a price. Are you actually able to find someone to create a FPGA design, after you have acquired your FPGA? It is not like you buy it on Amazon and flash it with something you find on Github, and then expect miracles. It takes a tremendous effort to suit it to your needs / problem, generally you'd want to hire a very skilled hardware engineer that is also an expert in cryptography / modular math and several other fields. These are the guys that work at Intel or TSMC's next-gen chips, not some users on a forum.

Meanwhile GPUs are scalable and easily programmable - e.g. a task that can be handled by your everyday software engineer.

So these are two very different problems, with very different tradeoffs. Performance does not come for free, it has its price.

It's also worth to mention that,
1. It's much easier to find seller who sell GPU rather than FPGA.
2. When you code a FPGA, usually that code is optimized to that FPGA alone. If you re-use it on different FPGA device, usually it'll have lower efficiency or even unable to run.

[SupremeTrinity]

So the "ideal balance" is to combine the useful with the pleasant? Trading raw performance for ease of development and scalability?
Because for me, using FPGA, despite being very complex to "program," would bring absurd performance compared to writing GPU code. In this case, I’m considering that the FPGA configuration would be done in such a way as to make it scalable with other FPGA boards of the same model and similar ones.

[kTimesG]

So the "ideal balance" is to combine the useful with the pleasant? Trading raw performance for ease of development and scalability?
Because for me, using FPGA, despite being very complex to "program," would bring absurd performance compared to writing GPU code. In this case, I’m considering that the FPGA configuration would be done in such a way as to make it scalable with other FPGA boards of the same model and similar ones.

So why are you still here to state the obvious, just do it Be aware that the guys who can tackle such a project can be counted on the fingers of one hand, so they most likely won't care too much about cracking Bitcoin keys, unless you make them an offer they can't refuse (not in the Godfather style). Also, they most likely already work for NSA and the likes, so they would get in trouble (this time in the Godfather style).

Good luck with your plan, keep us updated.

[NotFuzzyWarm]

In this case, I’m considering that the FPGA configuration would be done in such a way as to make it scalable with other FPGA boards of the same model and similar ones.

Um, like long ago when Kano wrote the FPGA driver for cgminer? The head of Canaan back then ran an array of 10 FPGA miners using cgminer code. Aside from being programmable, for the most part a FPGA works exactly the same as an ASIC does - they receive input data, run it through a logic array and then spit out a result. Once the pipeline is loaded all 3 operations happen every 1-2 clock cycles.

With a FPGA (or ASIC) throughput is only limited by:
a. FPGA clock speed
b. how fast a host pc can feed input data to the FPGA and respond to results (no key found or key found)