Well, yes. On a quick search, one good starting point would be a 'beginners study/dev board' like from here https://fraserinnovations.com/product/altera-fpga-study-board/ you can also search for 'Altera FPGA board' for others.
Intel's direct link is https://www.intel.com/content/www/us/en/products/details/fpga/development-kits.html
The biggest hurdle you face is translating the equation you will use into an array of logic gates the FPGA will emulate. Odds are scads of other folks have been working on FPGA crypto solutions so no doubt they will have some kind of logic config files online to start with. The most common language used for creating the files is Verilog. I'd think that there is a FPGA community forum somewhere, just search for one and take it from there.
Topic: S.O Finder (Read 320 times)
So, the biggest problem with using an FPGA, is the difficulty of finding someone who can "program" it, right? If that's the case, wouldn't it be simpler for me to try learning to configure/program it myself? Since I can make mistakes multiple times, as long as I'm careful not to damage the chip or anything like that.
I know I'm already being annoying with this subject, but it's something I've genuinely become interested in.
I know I'm already being annoying with this subject, but it's something I've genuinely become interested in.
Quote
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)
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.
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.
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.
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 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.
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.
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?
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).
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.
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.
So, since an FPGA is so much cheaper and can be customizable (configurable) at the hardware level, why hasn’t anyone been using it?
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.
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
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.
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.
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.
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.
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.
If you have resource to do that, consider buying FPGA and program it (or hire FPGA programmer) instead.
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.
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.
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.
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.
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.
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.
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.
Jump to: