BFGMiner started on 2012-01-05 with me replacing the CPU and GPU miner threads with a device driver API (845961a..b9d197d). I'm well aware cgminer merged BFGMiner's changes up until Con forked it around when BFL announced ASICs. I obviously had no reason to make a thread or binaries until that point - it would have been redundant. Perhaps in hind-sight it would have made things easier when Con and you decided to stop merging, to have done that from the start.
While it's a bit cute how you think you came up with the name, you have it wrong: it's St. Barbara's FPGA/GPU Miner; St. Barbara is the patron Saint of mathematicians and miners - quite a nice fit to go along with St. Eligius (patron of coin minters and coin collectors).

No, before BFGMiner, cgminer was CPU/GPU-only.

Quote me - I'm not seeing it at all ...
[/quote]

BFGMiner was forked from a cgminer that only supported CPUs and GPUs. Whilest Con was merging BFGMiner back into cgminer, I didn't bother with making independent-but-identical releases, but when he forked cgminer's FPGA codebase out from BFGMiner, I had to begin maintaining it independently. tl;dr: FPGA-capable cgminer is a fork of BFGMiner is a fork of GPU-only cgminer.

Right in the post I quoted from. You were claiming to deserve stuff from BFL because you claim you wrote the driver for them.

The problem is more about when people don't work together with others. Everyone was (and is) welcome to contribute to the development of GBT, so why quietly reinvent an incompatible protocol on the side? GBT vs StratumMP is like W3c HTML/CSS vs Microsoft Internet Explorer "quirks" HTML/CSS.

GBT is primarily a pooled mining protocol, and does address the problem you mention perfectly, while also addressing other (arguably) more serious problems (centralized pool control).

This analogy doesn't really make sense. Electrum and Satoshi implement things very differently. The only thing StratumMP really does differently from GBT is the protocol/communication syntax.

Pooled miners already need those features enough that they've been hacked on top of getwork for a long time. Probably no miner or pool implements full specs for all the getwork extensions, and that's fine for GBT as well. The important thing is that in cases where those features are needed, there is a consistent protocol for it rather than every pool/miner doing the same thing 5 different ways.

I've written up a forum post for getblocktemplate; replies on that topic are probably off-topic on this thread.

Since Eleuthria and slush have both recently announced their own developed-behind-closed-doors mining protocols, I felt it appropriate to make a thread here for end-user discussion of the "getblocktemplate" standard which they intend to compete with. As a poolserver author, a pool operator, a miner author, and a contributor to the reference client, my life is not improved by having yet another protocol to support, and what's bad for the authors of the infrastructure tools is also bad for all their users.

Getblocktemplate Features

• Decentralized: the miners decide what they will mine, and make their own blocks - no more blindly giving up mining control to pool operators
• ASIC-ready: miners can produce as much work as they need with a single request
• Usable yesterday: Eligius has supported it since February, and more pools real soon
• Solo mining: just point your miner to bitcoind 0.7 and mine by yourself (no bitcoind load issues)
• Simple: the basic implementation requires only minimal block building
• Extensible: extensions are available today for miners who wish to take more control over their miners, and future improvements can easily be added later

Documentation

See the new Bitcoin Wiki page for getblocktemplate, with lots of useful resources including end user and developer documentation.

Technical specifications:

• BIP 22: getblocktemplate - Fundamentals
• BIP 23: getblocktemplate - Pooled Mining

Supported by... (post or PM me to get yours added)

Poolservers (providing getblocktemplate to miners):

• Eloipool
• bitcoind 0.7+
• ecoinpool (planned)

Mining software:

• BFGMiner 2.8+
• cgminer 2.9+
• Butterfly Labs's EasyMiner (planned)
• poclbm (planned)
• Ufasoft Bitcoin Miner (planned)

Libraries for mining software:

• libblkmaker (C library for easy integration into any miner)
• python-blkmaker (Python port of libblkmaker)

Mining pools:

• BitArena.net
• EclipseMC
• Eligius
• Bitparking merged mining pool (planned)
• TripleMining (planned)

History/Background

Getblocktemplate's origins trace back to forrestv's getmemorypool JSON-RPC method for bitcoind. He created it so that his pool (P2Pool) could piggy-back on bitcoind so as to avoid harming the Bitcoin network (up to this point, it mined only empty blocks that never confirmed transactions). Having been fighting with scalability problems in pushpool/bitcoind for months on my pool (Eligius), I set out to implement a fast pool server using getmemorypool to do its own block production (this became Eloipool, this first open source makes-its-own-blocks poolserver). Other poolservers also implemented block creation using getmemorypool over the months following.

At about the same time, interest in decentralizing pooled mining became a hot topic. While BitPenny had initially released its own decentralized mining proxy months prior, P2Pool's implementation became rapidly popular. Anyone involved in Bitcoin mining protocols could see the need to move control of block creation back into the hands of the miners. Unfortunately, both BitPenny and P2Pool had used very pool-specific proprietary protocols to implement their decentralization. On the other hand, getmemorypool was almost a perfect fit for the task - it just lacked support for the now-ubiquitous pooled mining extensions that had developed around the getwork protocol over time.

In February, I implemented and deployed a first draft of getmemorypool mining support in Eloipool (and on Eligius) along with a proof-of-concept getwork proxy (now known as gmp-proxy), adding revisions as needed to function as a general-purpose decentralized mining protocol. After I had confirmed it was working, I documented and proposed it on the Bitcoin development mailing list for review on February 28th, where discussion began on what was missing and what needed to be changed or clarified. During the following few months, a number of others, both developers and testers, provided constructive criticism and suggestions, which were integrated into the standard. I also actively encouraged participation in the development of the standard among pool operators and poolserver authors, especially as it became necessary to move forward into the ASIC "mining generation". Eventually, it was decided it would be best to rename it to the more appropriate "getblocktemplate" name and drop backward compatibility with getmemorypool for simplicity. The standard was split into two pieces and the technical specification can be found in BIP 22 and BIP 23.

Support for getblocktemplate mining was announced for BFGMiner a week ago, and is currently functional (implementing the basics is quite easy) though not entirely optimized yet. A number of other software developers and pools have told me they intend to add getblocktemplate support soon.

(side note: all of this occurred before Eleuthria or slush made their protocols public, and neither of them chose to participate in the open development of the getblocktemplate standard)

Contribute

All that being said, there is always room for improvement. Reception of the proprietary proposals strongly suggests getblocktemplate is in desperate need of good miner-side example documentation. If you have the time to help bring getblocktemplate to everyone sooner in any way, please get in touch

Thanks to... (in no particular order)

• Forrest Voight
• Pieter Wuille
• Jeff Garzik
• Gregory Maxwell
• Geir Harald Hansen
• Gavin Andresen
• Stefan Thomas
• Michael Grønager
• ...anyone else I forgot to mention

Except that while you claim to be inventing, you're forgetting that BFL support came from me, and you and Con only decided to fork it so that you could steal credit for it...

P_Shep definitely did make notable contributions to the BFL driver.

I did.

That's not the definition used in the table.

No, if a PPS pool collapses, miners lose their due balances. If a SMPPS pool collapses, nothing happens, and nobody is out any money due.

Those weren't promo lines, they were corrections to your reward system graph...

Sure, gmp-proxy isn't exactly written to be readable - it's just a quick proxy cobbled together. Doesn't change the fact that it works.

You have to keep 10k connections no matter what protocol you use over them, unless you're using UDP (which is a bad idea for other reasons). Long polling itself moves load to be server-driven, though that of course won't help the problem of announcing new blocks all at once no matter how you do it. A pool that doesn't want users to request new templates on their own could simply set the expiration on it to 90 minutes later and only return new ones via long poll responses. Besides, CPU mining is dead and will only get more dead as ASICs go online. There's no reason they can't continue to use getwork until they're gone completely.

BIP 22/23 is only complex if you make use of the extensions that don't exist for StratumMP at all. If you don't, it's in fact just as simple (perhaps simpler).

Block building is the same no matter what protocol conveys the data... if you're not happy with the current level of documentation, it makes more sense to improve it rather than just start from scratch.

gmp-proxy has been functional on open source Eloipool-based pools for months.

Not sure this is really any different/better than the BIP 22/23 standards which have been in open development for months...
as for the comments on it in the Stratum mining protocol doc:

• the fundamental BIP 22 operation is fairly easy to implement, just making use of the more advanced functionality (which StratumMP doesn't even support yet) is more complex
• GBT does not require or depend on HTTP; it is intentionally designed to be JSON-RPC over any transport
• GBT does not require a complete dump of the server's memory pool
• checking shares shouldn't be any different AFAIK?

Perhaps it would have been a good idea for you and slush to participate in forming the standards instead of privately working on duplicate protocols? :/

You can use external software to create your own custom transactions via RPC now.
You cannot simply "sendfromaddress <fromaddr> <toaddr> <amount>".

I suspect everyone would plan to merge it if anyone submitted a properly-designed and cleaned up GUI.
I suggested in another thread that those interested might set up a bounty, and/or hire a developer to get it done.

Sounds about right. nvidia is garbage

The RPC API has a poolpriority command I added to set the priority of all pools at once. If you want to open an enhancement Issue for a --pool-priority option, I can probablyl get that added for the next minor release (I might forget if there's no issue to track it).

Orphaned blocks simply don't exist, so they don't really have stats... Shares go toward whatever the next block is found, regardless of any orphans in the meantime.

He meant the clients might have already seen the transaction broadcast before, so would have validated it themselves already. That is indeed already cached, but there are a lot of transactions that don't get seen by any given node (about 10% IIRC), and the back-and-forth of requesting missing transactions would add delays - though it might make sense on top of the basic block distribution parallelization I mentioned, but it will need to be benchmarked.

CVE-2012-4682 and CVE-2012-4683 are two reported by you and fixed in 0.7rc1.