it might mean the end of Christian Robichaud of Bittware participation but we still have the dev kits that can work.

Due diligence on company financials, product pipeline, customer base, etc would have been completed long before the start of this thread. Molex would be looking at proven sales/revenue streams for BittWare. That comes from industrial customers and not crypto.

Some quick updates:

- The launch is still on schedule for May 30.  The initial launch will be for the VCU1525 as Bittware is still working to increase the power limit of their board
- It is now time for the lucky people who already have VCU1525's to private message me, so you can receive some pre-release software in the next couple of days for initial testing and to get some feedback on how hard you find the set up process
- An attempt was made (long ago) to negotiate getting a % of hardware sales with Xilinx/Bittware but this was not successful
- The Molex acquisition was a surprise; hopefully this won't affect Bittware's participation in crypto mining
- Keccak will be launched on May 30, and Tribus will be released on June 15, followed by Phi1612/Skunkhash (which are very similar); then Lyra2z, and following that it will be either CN7 or Neoscrypt; suggestions are welcome as to desired algorithms


If you already have a VCU1525 (a real one, not AWS instance), then please message me ASAP to receive your pre-release software.

I've been googling for a couple of hours, can't find suppliers of either board in Germany-Europe. The closest I am to was XCKU115-2FLVB2104E, by the price it appears to be 1/2 or 1/4 of the VU9P, does anyone have any ideas?

You probably should but that has nothing to do with FPGA.

Just listening to two devs. talking about FPGA'S.  And how GPU mining will die because of FPGA'S. No fud.
In my opinion .... it comes down to hashes per watt.

As the OP noted, we are working to make a board available with higher power than the XUPP3R.  And yes, we were just acquired by Molex, but it will not have any negative affect on our participation, in fact it gives us access to more resources, including those of Nallatech, who is also a Molex company. 

I strongly stand by the statement that there is no algorithm that is somehow going to be magically possible on GPUs but not possible on any FPGA hardware configuration. There is simply no resource to exploit unique to GPUs.

That doesn’t mean, however, that there will be a big performance gap. Honestly all these coins just stringing together a bunch of hashes to chain hash really looks to me like it will give a larger FPGA advantage vs the shockingly simple hash algorithms with no room for optimization’s.

Except - the pools and nodes have no idea what hardware you have, and zero way to know.

For true ASIC resistance just release a closed source obfuscated inefficient miner and don’t publish the specs. That’ll last about two weeks before someone reverse engineers it...

Nothing magic is required, just design an algorithm that actually plays to the real strengths of the GPUs.

In particular all currently popular hashing algorithms completely ignore the super fast floating point units in the GPUs and CPUs. Ultimately, some future generations of FPGAs will start including FPU blocks, very much like they started including DSP blocks years ago.

But currently the FPU performance gap is quite wide.

Picking winners in the ASIC game is relatively easy if one isn't afraid of occasionally changing the source code. When properly designed, it even doesn't need to be hard fork, just the version number of the PoW function needs to be explicitly recorded.

At the moment I don't have time to write a longer discussion, so for now I'll repost what I wrote in another thread. We'll see which of those new threads will get most intelligent discussion.

Yeah, that is the key.

The thing is that it is relatively easy to write hash function that are very ASIC-proof or FPGA-proof.

Bytom folks are a good example. Their goal was not to be general-ASIC-proof but to make sure that the ASIC that is fast at implementing their hash in their ASIC. So they wrote a hash function that uses lots of floating point calculations exactly in the way that their AI-oriented ASIC does. The hard part of understanding Bytom's "Tensority" algorithm is finding exact information about the actual ASIC chips that are efficient doing those calculations.

But the general idea is very simple: if you don't want your XYZ devices to become, play to their strengths in designing the hash function.

For XYZ==GPU start with GPUs strengths. I haven't studied the recent GPU universal shader architecture, but the main idea was to optimize particular floating point computation used in 3D graphics using homogeneous coordinates, like AX=Y, where A is 4*4 matrix and X is 4*1 vector <x,y,z,w> where w==1. So include lots of those in your hash function. In particular GPUs are especially fast when using FP16, a half-precision floating point.

For XYZ==CPU made by Intel/AMD using x86 architecture, again start with their strengths. They have unique FPU unit with unique 10-byte floating point format and unique 8-byte BCD decimal integer format. Additionally they have dedicated hardware to compute various transcendental functions. So use a lot of those doing chaotic irreducible calculations like https://en.wikipedia.org/wiki/Logistic_map or https://en.wikipedia.org/wiki/Lorenz_system . Of course one could write an emulation of those formats using quad-precision floating point (pairs of double-precision floats), but it will take many months.

During those months you have additional time to research more strengths of your GPUs or CPUs. Use them in a hard-fork to assure that the preferred vendor of your mining hardware continues to be Intel/AMD/Nvidia.