.... you are increasing transaction confirm times by 4 times with GBT versus Stratum.....
I don't exactly see how this makes any sense. As we know, transactions are confirmed initially when they are mined in a block, and receive a bump in confirmation every time a new block is built on top of the block in which the transaction appears.
Now, the bitcoin network is tailored for blocks every 10 minutes. Now, I'm no rocket scientist, but, as far as I know, 30 seconds, 80 seconds, and 120 seconds are still < 10 minutes. So, at most, even if any protocol shifts mining the transaction by any of those times, the confirmation time gets pushed to the next block. So, instead of 10 minutes, its 20 minutes to get a confirmation, in a worst case scenario. And, again, no rocket scientist here, but, 20 divided by 10 != 4.
And this is a moot point anyway. The polling interval of getting new work containing new transactions (GBT, getwork, stratum, custom, whatever) shouldn't adversely effect confirmation times on average as long as the work is requested at intervals of less than half the bitcoin block mining target of 10 minutes, since every time a block is found, the new transactions will be used for the new work anyway. So, at most, again, even in a worst case scenario we're talking about pushing the transaction back one block IF the transaction if given to the pool that just happens to mine the next block AFTER *every* miner of that pool has already requested their work, but before it mines the block. Seems like a pretty unlikely scenario even at 120 seconds (20% block target time).
I really want to know where this 4x longer to confirm number comes from...
To summarize, lets look at every protocol as pseudo code:
(X being 1/2 the protocol's new work interval)
- Miner requests work from pool
- X seconds later, Network user submits a transaction
- Miner mines a block using work from line 1
- Miner requests new work from pool due to new block found (this happens < X seconds from line 1)
- Miner's new work's works on the transaction referenced on line 2, < X seconds from the time it was submitted to the network
- Some miner (maybe this one, maybe somewhere else) mines a block that contains the transaction from line 2 sometime between now and 10 minutes from now, on average
Transaction confirmation time: X seconds at a minimum, to 10 minutes, on average.
So, if the network contains only one miner, polling at X second intervals, then transactions take at least X seconds to be put into a block, and 10 minutes on average. In practice, regardless of the value of X, miners are not requesting work from their pools or solo bitcoind at the exact same interval, so, again, as long as the value of X is less than 5 minutes, the value of X has no real effect, on average, on transaction confirmation time, because blocks happen on average every 10 minutes.
But, as this forum is full of trolls anyway, I don't think anyone should just trust me, kano, luke, or anyone else. Do the math yourself, have someone you know do the math for you, or in some other way verify the numbers yourself.
-wk
P.S. - The OP was actually about bandwidth usage, not confirmation times... FWIW, I'm at 0.49 shares per 2KB with stock-settings bfgminer on Eligius using GBT with my four x6500s (~1.5GH share acceptance rate), after about 10 hours.... which is actually better than Luke-Jr's result, for whatever reason. Seems stock setting is a scantime of 60 seconds and expiry of 120 seconds... which IIRC is the same as cgminer.