So let me get this straight, this whole debate over GBT vs stratum boils down to the issue of "network security"? I'm all for network security, but I usually leave the details for people smarter than me. However, I have to ask the same questions as Kano: Does having every miner on a pool verify the transactions actually increase security? And also how does mining at a centralized pool using GBT = decentralized?
I suspect you've already reached a number of conclusions and that I'm just wasting my time responding— since you're already ignoring the points upthread, but in case I'm incorrect:
GBT was originally created by ForrestV (under an the original name, getmempool) so that p2pool could exist. Today _all_ current pool software uses it to talk to bitcoind. Luke took up the task of writing the formal specification for it and made a number of important improvements to close some denial of service risks and to make it more useful for general pool software, and because some of the updates weren't completely compatible and because the old name was confusing it was renamed. GBT is part of the bitcoin ecosystem, developed cooperatively in public, reviewed and used by many people, part of the reference software, with a clear publicly agreed specification. It's not just "luke's thing".
It seems to me that if these "security" issues are actually a non-issue, than stratum + cgminer = the best solution. I say cgminer because LJR admitted to having to edit his program just to use the same stratum implementation as cgminer. We get the same amount of "security" as the old GW, but with far less network usage and far greater scalability. On the other hand, if these issues are actually legitimate, than it would appear that GBT is the way to go, as it does use a little less network usage.
When you "mine" using getwork or unsecured-stratum you aren't a miner from the perspective of Bitcoin. You're just more or less blindly selling computing time to an untrusted third party (the pool) who is using it to mine. If you were to call yourself a miner in that model we might as well say that AMD is a miner with 90% of the hashpower, declare bitcoin a failure, and go home.
The security of bitcoin really depends on this assumption that mining— real mining, not just people selling cpu cycles— will be _well_ distributed, and that the people running it will have a long term investment in bitcoin (e.g. mining hardware) that would be damaged by doing anything hostile like helping someone double spend. If it's not well distributed there is a lot of risk that attackers can take over bit chunks by hacking systems or holding guns to people's heads. If the miners are not invested in Bitcoin then they could get short term returns by maliciously mining. These risks exist even if they don't allow the attacker to get a majority hash power, "a lot" is enough to steal from people especially if combined with network isolation attacks (see the bitcoin paper on attack success probability as a function of hashrate). People hype "51%" but >50% is just when the attack success probability becomes 100% (assuming infinite attack duration). Especially with the subsidy down to 25 BTC a high value attack doesn't have to have high odds of success to be very profitable.
If these assumptions— that actual mining (validation) is distributed and the miners are economically motivated to be honest— is incorrect then bitcoins— and mining hardware— should be worthless.
So, big centralized pools are a terrible thing for bitcoin. They violate the assumptions, and even if the poolops themselves are honest people (well, lots of people thought pirate was honest...) they are still an easy target for attack electronically or at gunpoint. But pools are easy and convenient and people are short-sighted and hope that someone else does the work to keep bitcoin secure while they just do the easiest thing.
For a while the core developers have been strongly encouraging people to mine using p2pool which solves these (and other) issues. Luke's pool was already popular with the more-geeky crowd and it lost a number of big miners to P2pool. Rather than denying the reality of the above serious concerns Luke looked for a way of combining the advantages— make mining that is as easy to use and as flexible in payout schemes as fully centralized pools, but not a danger to the Bitcoin ecosystem. He realized that the getmempool call that p2pool and other poolservers were already usng could be used by miners directly, allowing the miners to "trust but verify" and substantially limiting the attacks a malicious party controlling a pool could perform.
(Luke has also done some clever work in BFGminer to decrease the exposure even with getwork, for example it watches the previous block in the block header and prevents pools from asking you to mine a fork against blocks you previously mined. ... but getwork simply doesn't have enough information to do much better validity checks than that)
Con is a brilliant coder, by everyone's acknowledgement, but he's also a little bit coin operated. Luke can be difficult to deal with at times— but he's thinking long term and he's concerned with the future viability of Bitcoin for everyone. When you delegate _Bitcoin's_ security to either Con or Luke, you might be delegating it to people smarter than you either way— but out of the two only in the case of Luke are you delegating it to someone who's actually demonstrated that they've thought mught about it or _care_ much about it.
People could debate if a centralized pool using GBT and users with BFGminer is "decenteralized" or not or GBT-mining's merit relative to p2pool. But debates over terms are boring, and a comparison to p2pool is somewhat apples to oranges (I say p2pool is more decentralized, especially since the poolops can still cheat miners out of payments in the non-p2pool options, and Luke argues with me). What matters is that properly used GBT based mining can close many of the risks to Bitcoin of centralized pools. And fortunately slush was convinced with stratum to add extensions to pick up many of the same advantages.
Yes, getting extra data to validate the work takes some more bandwidth but all the bandwidths involved in mining (or bitcoin for that matter) are small. Because GBT style mining allowed massive bandwidth reductions for high speed miners many people had been just expecting people to switch to it and never notice the increases because they were paid ten times over by the improvement, but then slush showed up with stratum which had the efficiency but not (initially) the security improvements of GBT... In any case, the bandwidths involved are so small that they shouldn't be relevant to almost any miners (esp since they don't increase much with increased hashrate). It may be relevant to mining pools— but miners are paying for their services and ought to demand the best behavior for their long term future.
