-S noauto

Yes it did, it was released under the name "cgminer", in collaboration with Con/Kano's GPU miner.

No, after ASICs were announced, Con/Kano went their own way because they were upset.

No, cgminer had been very tied around GPU code, and had entirely independent code for CPUs.
It took some pretty big changes to make it into a modular/driver based model.

You have an awfully centralised way of looking at things. Just because early versions of BFGMiner were released in this thread, thanks to my efforts to try to collaborate rather than release independently at the start, somehow means in your mind that everything only "counts" toward Con/Kano's sole credit after they decide to split off?

Legally speaking, they haven't stripped my copyrights and are abiding by the terms I licensed my code under.
Practically speaking, they seem to be doing what they can to convince newbies that cgminer is the "original" and BFGMiner a "clone", when in reality I originally wrote the code basis for FPGA/ASIC mining*.
On the other hand, I make it very clear in BFGMiner's documentation who has contributed, and to what degree.

* cgminer has since moved on to rewrite most of this code, but the reality remains that it was second to the game, after BFGMiner.

You have it backward.

Slightly off-topic here, but you could get BFGMiner support if they send nwoolls a sample one.

I was left "doing my own thing" because Con and Kano were unwilling to continue collaborating.
And BFGMiner now has more contributors than cgminer, just FWIW.

Hotplug is definitely a good feature to have, IMO. But there is nothing about it that requires bypassing the official drivers. BFGMiner does hotplug just fine with any USB, VCOM, or HID device, and will automatically trigger it in the next version.

I'm curious as to what you had to fight? The VCOM drivers just automatically work/install in most cases...

solo mining is covered in README

Not everyone donates with a percentage! I'm pretty sure our fastest miner has donated quite a bit in other ways.

It sounds like similar to bitfury's chips, the Coincraft A1 is used by a variety of different boards, some of which are just thin interfaces to talk directly to the chip(s). In this case, I'd suggest a single driver-coincraft.c file which implements all the low-level communications with the chip (similar to driver-bitfury.c, but ideally without the libbitfury.* extras), possibly with a "coincraft_gpio" driver for testing, and then build additional board-specific drivers on top of this (similar to the "bfsb", "metabank", "nanofury", etc drivers). As nwoolls mentioned, HACKING documents the basic driver interface and the async minerloop; depending on the chip, however, the queue minerloop might (or might not) be preferable - the "bitforce" and "hashfast" drivers are good examples of different ways to use that interface.

If you'd like me to write the driver myself, I'd need at least a sample unit for each of the different interfaces/boards, and some documentation on them. I believe zefir linked me a draft doc for the chip itself a while back, but I'm not sure I have the latest version.

CPU mining is the same as GPU mining: no reason to drop it.
Although there isn't an active maintainer to make sure it keeps working, either...
Would be nice if pooler merged

Prime POW support was never finished/merged; so someone willing to clean up the code is needed to get it added in.

Curious why you like to slander others so much?
I mean, I understand it might be hard to make me look bad using facts, but are you really so desperate to make me look bad that you're willing to lie?

Only because you're listening to a real liar.

Figure out which is which by serial number ([M]anage should tell you) and use:
--set-device antminer@serial:clock=x0881 --set-device antminer@otherserial:clock=x0981

There's an interesting pedegree: cpuminer -> cgminer (GPU) -> BFGMiner (formerly released under the name cgminer) -> cgminer.

Only if it becomes troublesome to maintain.
At the moment, nwoolls is maintaining the scrypt part of the code, so it's not at risk of being removed.
We could always use more contributors, though - even non-programmers can help out with improving documentation

More or less, though at this point it might be more accurate to say they have common roots: since forking, the cgminer devs have rewritten most of the BFGMiner code (for the worse, though).

Yeah, I did give it some thought a few hours ago, but I was unable to come up with a workable solution
I suppose martians could prioritise an ASIC foundry and manufacture a proprietary implementation of some new proof-of-work.
It might leak to Earth, but hopefully by then it will be "too late"? :p

I have no  idea why people keep forking cgminer.
You'd think they'd help improve the original BFGMiner codebase!

If a centralised system is desired, no blockchain is necessary at all.
Earth does not have any such timestamping restrictions on blocks.

Higher supply decreases value, not increases it... so this doesn't really argue why it should be increased quicker.

Well, now it sounds like the goal is a centralised system masquerading as a decentralised one...
I'd be more inclined to support a system that improves on Bitcoin (or at least retains its functionality) rather than seems to be introducing new problems without addressing the existing ones.

I don't see how; the terrestials will just naturally create a forked blockchain, and if they have a higher hashrate, it will replace the martian one as soon as it gets far enough ahead...
I'm not aware of any such measures that can be taken without centralising the currency.

Raising the money is done with the premine. Beyond that, it doesn't help raise money at all.
If all the subsidy is mined before leaving Earth, then where is the incentive for martians to mine at all, much less maintain the same hashrate as it had on Earth?
Keep in mind that the difficulty needs to be high enough to make it resistant to attacks...