Just released the first version of cgminer to natively support GBT, version 2.9.0.

However, the block change performance of EMC on GBT is lacklustre:
https://bitcointalk.org/index.php?topic=108854.msg1317574#msg1317574

New version -> 2.9.1

Main thing in this new point release is support for the pooled GBT mining protocol. This is once again a large chunk of new code and carries with it the attendant risks of new instability so I'm leaving 2.8.7 up for download. The GBT implementation is my own from scratch, not using an existing implementation. luke-jr helped debug a few things to do with how the protocol worked since no one else seems to understand it.

Note that I have serious reservations about recommending GBT as significantly advantageous for the miner (in terms of performance) unlike stratum. See my post here as to why:
https://bitcointalk.org/index.php?topic=108854.msg1317574#msg1317574



Human readable changelog

Support for GBT mining protocol.
Minor stratum tweaks, bugfixes and improvements.


Full changelog

Version 2.9.1 - November 6, 2012

- Reset work flags to prevent GBT shares from being submitted as stratum ones
after switching.


Version 2.9.0 - November 6, 2012

- Add endian swap defines for where missing.
- Only retarget stratum shares to new pool diff if diff has dropped.
- Remove resetting of probed variable when detecting GBT.
- Count lost stratum share submits and increase message priority to warning.
- Only retrieve a new block template for GBT pools that are the current pool.
- Show which pool untracked share messages have come from.
- Add management for dead GBT pools.
- Count lost shares with stratum as submit stale lost.
- Discard record of stratum shares sent and report lost shares on disconnection
since they will never be reported back.
- Swab, don't just swap the bytes in the GBT target.
- Change status window message for GBT connected pools versus LP.
- Generate a gbt work item from longpoll when required to set new block and
message appropriately.
- Use existing pool submit_old bool from gbt data.
- Retrieve a new block template if more than 30 seconds has elapsed since the
last one to keep the data current and test the pool is still alive.
- Update GBT longpollid every time we request a new longpoll.
- Manage appropriate response codes for share submission with GBT.
- Allow the longpoll thread to start with GBT and only set the longpollid once.
- Correct last few components of GBT block generation courtesy of Luke-jr.
- Use correct length for offsetting extra nonce and remaining data.
- Flip all 80 bytes in the flip function which was wrongly named flip256 for its
purpose.
- Calculate midstate for gbt work and remove now unused variable.
- Use a standard function for flipping bytes.
- Insert the extra nonce and remaining data in the correct position in the
coinbase.
- Remove txn size debugging and enlarge gbt block string to prevent overflow.
- Remove varint display debugging.
- Build varint correctly for share submission and sleep 5 seconds before
retrying submit.
- Make gbt_coinbase large enough for submissions, swap bytes correctly to make a
header from GBT and encode the number of transactions in share submission.
- Store the fixed size entries as static variables in GBT in binary form,
byteswapping as is required.
- 32 bit hex encoded variables should be in LE with GBT.
- Target and prevblockhash need to be reversed from GBT variables.
- Construct block for submission when using GBT.
- Use same string for debug as for submission and make string larger to cope
with future GBT messages.
- Skip trying to decipher LP url if we have GBT support.
- Store all the transaction hashes in pool->txn_hashes instead of separating
txn0 and correct generation of merkle root, fixing memory overwrites.
- Hook into various places to generate GBT work where appropriate.
- Create extra work fields when generating GBT work.
- Generate header from correct hashing generation of the merkle root for GBT.
- Generate the merkle root for gbt work generation.
- Create a store of the transactions with GBT in the minimum size form required
to generate work items with a varied coinbase.
- Create a function that generates a GBT coinbase from the existing pool
variables.
- Extract and store the various variables GBT uses when decoding gbt work.
- Check for invalid json result in work_decode.
- Decode work in separate functions for getwork vs gbt.
- Check for the coinbase/append mutable in GBT support to decide whether to use
it or not.
- Add a gbt mutex within the pool struct for protecting the gbt values.
- Convert work decode function to prepare for decoding block templates.
- Check for GBT support on first probing the pool and convert to using the GBT
request as the rpc request for that pool.
- Make the rpc request used with getwork a pool variable to allow it to be
converted to/from gbt requests.
- Changes to build prototypes to support building on FreeBSD 9.1-RC2 amd64
- Free old stratum_work data before replacing it
- There is no need for addrinfo any more.
- server and client sockaddr_in are no longer used in struct pool.
- Merge pull request #322 from luke-jr/bugfix_stratum_tmpwork
- Set sshare id and swork_id within the sshare mutex to avoid multiple share
submits with the same id.
- Initialize temporary stratum work

Hmm... To work with the current stratum limitation, cgminer checks shares against the current stratum pool difficulty before trying to submit them. I can remove this code and then difficulty is tied to the work at the time it was generated up to how the pool does things entirely. I'm thinking I will check difficulty against the new difficulty only if difficulty has dropped and then leave it up to the pool to cope. While this may introduce more rejects with diff increases, at least there is no chance of work lost, and will work with your idea.

Tying difficulty with work entirely would still be much better.

Only partially because one uses push over an open persistent socket while the other is a delayed http response a la current longpoll. There is also the matter of the massive difference in the size of the data sent out which is always much bigger with gbt and transmitting a full transaction list unless the protocol gets extended in the future.

Hopefully this post should help you decide which protocol to choose:
https://bitcointalk.org/index.php?topic=108854.msg1317574#msg1317574

Almost implemented the first working version of GBT within cgminer.

This sort of behaviour tells the story well though:


Now pool 3 here is slush on stratum (ping time 335ms), while pool 2 is EMC on GBT (ping time 225ms).

Note how stratum picks up the block change and notifies me 10 seconds before GBT does. However, this is not the GBT pool simply learning of the block change later, because it starts rejecting my shares as being from the previous block before I even got the longpoll from the GBT pool. Then of course there's a second longpoll with the transactions, which is not an unusual practice.

So long as everything is working, yes. Long term the need for that option should even be removed, but it's still early days.

Correction: 4-6 weeks.

The minirigs can work with small amounts of work updating fast enough for p2pool's requirements. With cgminer you can enable the feature --bfl-range which splits work up into smaller amounts making stales manageable, but reduces hashrate by 1%.

Thank you very much. Yes it was the concept rather than the details, and branch is a better term. I'm thinking the mining software can support both modes and be started in confirm transaction mode only if desired by the user.

EDIT: or alternatively, randomly inject requests for full transactions.

My goodness! Go back 3+ pages on this forum thread and you'll see that's what I was discussing with jgarzik. Yes I was trying to be productive and help find some useful pool mining mode for GBT. All it needs is a request in the protocol for branches.

...this may explain why I was so annoyed yesterday.

EDIT: https://bitcointalk.org/index.php?topic=108854.msg1286483#msg1286483

It does fail over except under one circumstance: If the pool is still connected to cgminer, and is still sending cgminer work, but the pool is not successfully receiving shares. I will be addressing that soon. Any other situation, it does take longer to failover if the connection is not dropped cleanly as there is not always a reliable way of knowing the other end has stopped sending, but cgminer uses 90 seconds of silence from the server to assume that it has stopped responding since stratum mandates messages at least every 60 seconds. Try sticking it into debug mode from the display menu to see if it's still receiving messages. Without a backup however, all cgminer can do is regularly try and keep contact with the primary.

Yeah it seems at the time ozcoin kept the connection open but its own buffer was full and was not accepting anything the miner was trying to send, delaying submission. There currently is a very long timeout for submission of data in cgminer and it probably queued up heaps of shares it was trying to submit in that time and overflowed. I will address that in the future. Even if the connection is open, cgminer will have to assume a pool is as good as dead if it's failing to accept data for some arbitrary period.

Since the point of get_transactions is simply to confirm the merkle branches, you only need to allow it once per stratum template push. All the stratum pools so far only push a new template every 30 seconds. Limiting get transaction requests to 1 for each template would only allow the miner to ask for it once every 30 seconds.

By the same token, GBT pools should limit how often users can ask for a template since that does send out all the transactions.

Must I quote myself?
That IS correct.

I was exploring the possible issues with implementation of GBT and got attacked as though I was trying to spread FUD about GBt. Nowhere did I imply this is what all miners would be doing.

Great stuff, don't forget to put a redirect in your regular getwork servers' headers.

HTTP hdr(x-stratum): stratum+tcp://us.ozco.in:3333

And if you blame me for not paying attention at the right time earlier on when this protocol was developed well I'm terribly sorry for not keeping track of every goddamn fucking thing going on in the bitcoin world.

I will implement whatever the fuck this protocol ends up being one way or another.

Sorry for offering suggestions, I will now say no more on this.

Please read my quote. I did NOT say that.