re: The ASIC revolution

I'm in two minds about what I'll do if/when the ASIC revolution comes. I've tried to engage BFL as potentially developing software for their hardware somehow sponsored by them, but they're completely silent in response. Furthermore any software developed to drive them will likely be based on existing fgpa code which I had no input into, which means that if I don't do the development, it will be luke-jr who does as the fpga code was done by luke-jr who now maintains a semi-hostile fork of cgminer and I guess he's ideally positioned to take over maintainership of the project entirely as that fork if I pull out. I'd hate my baby to end entirely in his hands but it's looking inevitable unless I fork cash out to BFL who I don't even trust, to do the code for their own hardware. They obviously realise they'll corner the market in the interim regardless of what their software and community support will be like so they are guaranteed to make huge profits and they need not engage the community and developer(s) in a positive way.

I will most definitely be maintaining cgminer and actively developing it right up to the moment some real ASIC hardware appears, so don't think I'm abandoning anything any time soon. Ironically a lot of the recent development has been towards making cgminer scale to massive hashrates, devices and pools.

Comments please.

Ask a simple question and the moron brigade is out in force, up yours asshole.

CGMiner was originally a fork of CPUMiner for the CPU->GPU migration. BFGMiner is basically the same thing from GPU->FPGA/ASIC, except that I opted to try keeping CGMiner in sync instead of just flat out forking from the start.

Heh - well that is your forum name ... so why the hostility

As far as BFL's ASICS - I'll believe it when I see it, just like it was with their FPGAs. Initial stumbles can be forgiven if they really do produce a quality piece of hardware, then follow up with support and community involvement. If not, there are other ASIC projects.

The 7970 crowd sourcing went pretty well, and that was for a $500+ component. A 3.5 Gh/s BFL Jalapeno is only $187 including international shipping...

You could set up an address, and when it gets to 30 BTC, order a unit.

BFL will be losing my business if they don't supporting CG Miner

I noticed something was fishy when they recommended another miner, I tried it, disgusting!

1. Precisely why I tried getting sponsorship from BFL themselves in the form of hardware, so yes.
2. Not my area of expertise and the project progress appears slow...

Unfortunately, this is actually clearly an exaggeration to the point of being incorrect.

luke-jr wrote the first FPGA module which was support for the BFL.

Xiangfu wrote the first support for the Icarus based on Luke-jr's BFL code but even back then had to rewrite enough of it to make it work properly - back with the first release of the Icarus code my involvement was to help debug Xiangfu's code and get it working.

nelisky wrote the entire ztex support and luke-jr has had nothing to do with that at all.

By this point I had rewritten some of the Icarus code, extended it and also added the only performance gains to it so far: LP abort, 10x setup speed and optimising the abort time to reduce getworks
The only non-trivial change that luke-jr initiated for Icarus (even in his fork) was to close and re-open the serial port every time it sent work to the Icarus to avoid a problem with the serial port not working due to a problem with his linux kernel he was using - which I requested he instead determine when there was a serial port problem and then close and re-open it (since it was such a rare problem) - but he refused to.

I requested he change the BFL code to abort work on an LP to stop wasting work (on average half a nonce per LP) - of course only if the pool doesn't accept or need stale work - but again he refused to do it (and still hasn't)
The side affect for anyone mining on a pool that doesn't pay stale shares, is that the BFL code now gets 5x the stale shares compared to GPU and Icarus when you factor in the MH/s speed
(i.e. if you incorrectly ignore the MH/s difference BFL is 10x the number of stale shares vs Icarus)
Feel free to view my rigs (2xICA, 1xBFL, 1x6950) to verify this:
http://207.36.180.49/miner.php?ref=0&pg=Mobile
(N.B. that page is very slow to load and I will remove it from this post some time in the future)

His excuse for this was: June-1 GMT+10 log discussion:
The next MOD that decides to remove this BETTER HELL ASK ME FIRST OR HAVE A GOOD EXCUSE
other than pandering to a bull shit request from Luke-jr and helping hide his lies ... got that gmaxwell?
The PUBLIC FreeNode IRC #cgminer channel that anyone can be in - including you have been in - is NOT private in any way
[Private log reposted without permission removed]

Still no sign of that 'private' code he wrote more than a month ago ...
So everyone using BFL on a pool that doesn't pay stale shares is getting 5x the number of stale shares with the current code than they should (and also of course luke-jr isn't getting this 5x)

luke-jr wrote the support for MMQ
(I wont get into the issues with that code now ...)

luke-jr added support for the BFL Rig Box (similar to the BFL single)

Now for the actual commits in the commit log with our names on them I did:
 git log | grep Author | grep -i (kolivas or kano or luke)
Matching the following words:
kolivas: 1659
kano: 198
luke: 78

This of course includes git management by ckolivas, however, git management is just as important as writing code for the git

Now I wont make any exact meaning of those numbers - but feel free to analyse the results if you wish.

I clearly have trust issues with anything luke-jr says ... maybe others do too?

The problem with that statement is:
Prove anywhere one lie you say I have said ... anywhere ...