Decentralized mining protocol standard: getblocktemplate (ASIC ready!)

[DavinciJ15]

Easier than the alternatives

I see your point.

Eh, why do we need passwords?

It was used for HTTP reuse of code but I guess with a new protocol it's not needed anymore eh?  I can't think of any reason why we should have miner passwords.   LOL

[1713544393]

1713544393

[Luke-Jr]

Eh, why do we need passwords?

It was used for HTTP reuse of code but I guess with a new protocol it's not needed anymore eh?  I can't think of any reason why we should have miner passwords.   LOL

Getting off-topic here, but Eloipool has always ignored passwords entirely, and only used username for share logging (ie, no checking against a db).

[kano]

So ... I've had a go at a pool OP about ignoring transactions and found to my surprise they aren't the ones choosing the transactions.

GBT is.

Here's a run of 15 block for the said pool and look at how bad this is for the bitcoin network - shocking in my opinion:

Bitcoind's GBT is deciding the txns, and it's regularly making small blocks when the bitcoin network constantly has a very large number of outstanding transactions (>4000)

This of course means that everyone's bitcoind is sitting there with a list of many thousands of unconfirmed transactions waiting to go into blocks ... and it is bitcoind's own GBT that is part of the cause of it ...

Code:

Block     size txns
205771 209,454 311
205767 188,756 499
205766   9,468  32
205729  30,740  55
205724  37,399  58
205706  11,169  27
205699   9,720  28
205689   8,609  28
205683 102,113 245
205671  27,961  20
205670  59,118  69
205668  46,083 114
205667   4,791  15
205656 105,743 194
205654  71,232 188
205643  10,739  23
205631   4,551  13
205627  16,381  38

6 blocks (1/3) in there you could consider large (>100 txn),
6 blocks (1/3) are very small (~10k or less and few txns)

Is this basically saying that GBT doesn't adhere to the fee structure of bitcoind?

Is GBT's aim to have every bitcoind on the BTC network constantly running large (>4000) txn memorypools and keep them growing?

...

I will also point out that the Eligius pool has for many months restricted all it's blocks to a limit of only 32 transactions and to ignore transactions that pay full fees if they are near the lower limit - as stated by the new pool OP.
The old pool OP is the same proponent of the so called decentralisation holy grail GBT ... that is CLEARLY showing itself to be bad for BTC and the BTC network.

I see the link there as expected, not surprising.

The argument given for the 32 transaction limit was that it reduced the risk of orphans (which of course it does) however, the issue there is that larger pools with better software did not have the orphan problem Eligius had and instead of fixing the performance problems of the pool software, Eligius' solution was instead to detriment the BTC network by reducing the number of transactions being confirmed and thus extend confirmation times.

Even the new pool op has clearly stated that his intererst is in short term return, not considering the bad long term effect of such short sighted decisions.
i.e. a quick buck with risk of long term problems vs a long term strategy that will also pay much better in the long run.

I've seen Luke-Jr make many arguments about what's good for BTC but only to find that he himself is a proponent of doing thing that are quite simply and clearly bad for it - and it seems that GBT follows this same path also.

Edit: this also explain why people mining with GBT aren't having the expected network problems of receiving hundreds of transactions with every request for work - since GBT ignores most transactions.

Easy way to see it: ./bitcoind getblocktemplate | grep sigops | wc
Sometimes you get a lot and sometimes you don't get many at all - even though if you check your debug.log it will show thousands of unconfirmed transactions (poolsz)

[abracadabra]

If GBT is planning on going anywhere, this has got to get fixed. Ignoring transactions is bad.
If this doesn't get fixed, I doubt pools will support GBT.

Waiting to see how LukeJr responds.

[DrHaribo]

bitcoind has always made a decision about which transactions to include in a block. That has nothing to do with GBT which is just a different API for getting this (and other) data out of bitcoind.

By the way, kano, if you have a suggestion for how bitcoin can be improved, you can set up a pull request on github and I'm sure the bitcoin developers will consider it.

[Luke-Jr]

If GBT is planning on going anywhere, this has got to get fixed. Ignoring transactions is bad.

Kano is a troll and basically a liar.

GBT is a protocol, it doesn't and can't "ignore transactions".

Bitcoind, by default design, has always ignored spam transactions when it can detect them.
The Bitcoin protocol, by Satoshi's original paper design, specifically depends on miners choosing to ignore transactions that don't meet miner-defined policies.
But again, one of this has anything to do with GBT; transaction acceptance works exactly the same whether you use getwork, GBT, or Stratum, except that GBT moves the final decision for which transactions to include to the miner (note that no mining software supports changing the pool's decisions yet, but I plan to have future versions of BFGMiner support adding more transactions from bitcoind to collect on fees).

[Luke-Jr]

GBT moves the final decision for which transactions to include to the miner

Transactions are included or excluded from the block based on what criterias? Could criterias be made user-selectable or changeable?

As I said, there is no existing implementation of miner-side transaction control yet.

[kano]

GBT moves the final decision for which transactions to include to the miner

Transactions are included or excluded from the block based on what criterias? Could criterias be made user-selectable or changeable?

As I said, there is no existing implementation of miner-side transaction control yet.

So now that yet again Luke-Jr has called me a liar ... which is a common thing for you to do and you have never once proven that true when you have said it ... though I have proven it true in reverse about you ... where is the lie in my post?

The only point you have made is that GBT is a protocol and the implementations are the fault of the implementers ...

So who implemented them?

You in your cloned BarbieMiner, you in your pool, and ... "someone" in bitcoind.

I guess the other place to look will be P2Pool - but I don't know if that just gets the results from bitcoind or if it processes those results.

BitMinter blindly accepts the results from bitcoind (according to DrHaribo's response)

--

Luke-Jr if you are going to use you standard method of distributing FUD by hiding behind definitions of words then I guess you are really saying the GBT is simply an idea and no use in the real world.

The implementations are what use it and if the implementations are bad for BTC then GBT is bad for BTC.

The two first implementations I listed are also by you ...

--

I've explained to you and also mentioned to Gavin a suggestion about the problems with bitcoind and dealing with large blocks.
Specifically that each block transferred from one pool to another sends way too much data that most bitcoinds already know and does way too much work that the bitcoinds have already done.
That's as far as I went - and seems a good enough solution.

(Edit: and GBT doesn't even use this simple and obvious idea)

I don't deal with bitcoin code development directly, there are just way too many issues with doing that and I have (made clear) elements of it that I disagree with and twice when I've raised those issues they have been shot down.
Fine - I disagree with the devs - so I don't think throwing code in that direction would be productive.
Ideas and issues are what I do throw in that direction.

Meanwhile, your solution at your pool was to reduce the number of transactions per block to 32 and ignore full paying transactions (Satoshi Dice) and who knows what else because of that.
I guess the reason you would not divulge that information before was that people would then know that your own pool was ignoring full paying transactions and that would show you as the hypocrite you are.

--

Anyway, I've reset both my bitcoinds and will see how big the memorypool is again in a week or two.

One of my 0.7.0 bitcoind started:
09/22/12 08:30:55 Bitcoin version v0.7.0.3-g0a4e67a-beta ()

It first reached 4000 after less than 4 days:
09/26/12 00:04:23 CTxMemPool::accept() : accepted 8f15d5ec48 (poolsz 4000)

The last time it was under 1000: (one month after it started)
10/22/12 13:35:31 CTxMemPool::accept() : accepted 0a8e298047 (poolsz 999)

The last time it was under 2000: (two days after that)
10/24/12 15:41:28 CTxMemPool::accept() : accepted f14b7e229c (poolsz 1999)

The last time it was under 3000: (almost 8.5 hours after that)
10/25/12 00:02:21 CTxMemPool::accept() : accepted 879a991172 (poolsz 2999)

... and it kept growing ...

[DavinciJ15]

If GBT is planning on going anywhere, this has got to get fixed. Ignoring transactions is bad.

Kano is a troll and basically a liar.

GBT is a protocol, it doesn't and can't "ignore transactions".

Calling people names does not prove you are correct.

People called me a troll and liar because I said money is created when people go into debt at a bank.  So does someone calling me a name make it true?  Is the documentation found in Modern Money Mechanics created by the banks a lie?

"Of course, they do not really pay out loans from the money they receive as deposits. If they did this, no additional money would be created. What they do when they make loans is to accept promissory notes in exchange for credits to the borrowers' transaction accounts."
Modern Money Mechanics

I understand the truth of our monetary system and this is why I like bitcoins as a solution to our unfair monetary system.  So lets forget the name calling and find out the truth.

Finally I am not sure if it's a bad thing that miners are ignoring transactions as that's part of the market saying... hey you are not paying me enough to include your transaction!

There will always be miners that work for low to no transaction fees because they believe in the system, thus there is no need to be a "government" and attempt to force good behaviour.

Just my 2 satoshis

[Luke-Jr]

Calling people names does not prove you are correct.

Ignoring is the standard appropriate way to deal with trolls. I just put that out there so newbies know why he isn't getting a response.
There's no basis to Kano's accusations in any case, so not much really to say about them other than that they're lies.

[DavinciJ15]

Calling people names does not prove you are correct.

Ignoring is the standard appropriate way to deal with trolls. I just put that out there so newbies know why he isn't getting a response.
There's no basis to Kano's accusations in any case, so not much really to say about them other than that they're lies.

I may not agree that it's an issue but Kano is not a troll for voicing his a opinion.  I have a YouTube channel and I get a lot of trolls and Kano sounds nothing like the trolls I get.  I got so many I did a video for them...

http://www.youtube.com/watch?v=8sQaIeHvuM0

It was funny and even the trolls loved it.

[firefop]

I may not agree that it's an issue but Kano is not a troll for voicing his a opinion.  I have a YouTube channel and I get a lot of trolls and Kano sounds nothing like the trolls I get.  I got so many I did a video for them...

http://www.youtube.com/watch?v=8sQaIeHvuM0

It was funny and even the trolls loved it.

Hey D, big fan.

That being said, Luke's right. Kano's in this for profit more than love (obvious from his post history here if nothing else). In addition he tends to bend the truth past the breaking point quite often. These two statements are fact I'd encourage you to verify their veracity for yourself.

The following is my personal opinion which I happen to believe is right:

The reason that LukeJr supporters tend to discount poster like Kano is the simply because Luke has a technical mind, understands how things work and also is a proponent if not an advocate of the bitcoin network's need to be transparent. That's basically what this entire post is about... Luke (and myself and anyone who loves liberty) would rather take a slightly less streamlined process that we can see through than trust a pool op to inform us of what's happening. So sure, Stratum is less bandwidth at the cost of giving the pool op the ability do whatever they want behind it and the miners never knowing. It makes me wonder what they'd like to hide.

Also, I'd call it trolling when Kano comes here to decry the 'bad design' of GBT when the real issue is exactly what I've posted above... at the very least he's dishonest for not simply making his case for what it is... the desire to open a wedge into bitcoin that can be exploited later either by himself or others... without those of us actually doing the work knowing about it.

[-ck]

...And where do I fit in? Despite what it may look like, this is a technical discussion about the disadvantages of GBT.

[DavinciJ15]

I may not agree that it's an issue but Kano is not a troll for voicing his a opinion.  I have a YouTube channel and I get a lot of trolls and Kano sounds nothing like the trolls I get.  I got so many I did a video for them...

http://www.youtube.com/watch?v=8sQaIeHvuM0

It was funny and even the trolls loved it.

Hey D, big fan.

That being said, Luke's right. Kano's in this for profit more than love (obvious from his post history here if nothing else). In addition he tends to bend the truth past the breaking point quite often. These two statements are fact I'd encourage you to verify their veracity for yourself.

The following is my personal opinion which I happen to believe is right:

The reason that LukeJr supporters tend to discount poster like Kano is the simply because Luke has a technical mind, understands how things work and also is a proponent if not an advocate of the bitcoin network's need to be transparent. That's basically what this entire post is about... Luke (and myself and anyone who loves liberty) would rather take a slightly less streamlined process that we can see through than trust a pool op to inform us of what's happening. So sure, Stratum is less bandwidth at the cost of giving the pool op the ability do whatever they want behind it and the miners never knowing. It makes me wonder what they'd like to hide.

Also, I'd call it trolling when Kano comes here to decry the 'bad design' of GBT when the real issue is exactly what I've posted above... at the very least he's dishonest for not simply making his case for what it is... the desire to open a wedge into bitcoin that can be exploited later either by himself or others... without those of us actually doing the work knowing about it.

That being said, Luke's right. Kano's in this for profit more than love (obvious from his post history here if nothing else). In addition he tends to bend the truth past the breaking point quite often. These two statements are fact I'd encourage you to verify their veracity for yourself.

Thanks I will keep reading and Kano's posts.

The reason that LukeJr supporters tend to discount poster like Kano is the simply because Luke has a technical mind, understands how things work and also is a proponent if not an advocate of the bitcoin network's need to be transparent. That's basically what this entire post is about... Luke (and myself and anyone who loves liberty) would rather take a slightly less streamlined process that we can see through than trust a pool op to inform us of what's happening. So sure, Stratum is less bandwidth at the cost of giving the pool op the ability do whatever they want behind it and the miners never knowing. It makes me wonder what they'd like to hide.

Also, I'd call it trolling when Kano comes here to decry the 'bad design' of GBT when the real issue is exactly what I've posted above... at the very least he's dishonest for not simply making his case for what it is... the desire to open a wedge into bitcoin that can be exploited later either by himself or others... without those of us actually doing the work knowing about it.

Good points, I'm not against GetBlockTemplate (GBT) I just want something that works for everyone not just those with a mensa membership card. :p  lol With that said, I understand that bitcoin is a complex protocol to begin with and we don't want pools to consolidate and use the hashing power for evil once there is nothing anyone can do about it.  However that is not an issue right now so stratum is fine transition from GPU/FPGA mining to ASICs.  In the future we will need GBT.

Bottom line I want GBT but stratum gets the job done faster and with less work for pools, miners and software producers.

[Luke-Jr]

Bottom line I want GBT but stratum gets the job done faster and with less work for pools, miners and software producers.

In reality, GBT is much less work for pools/miners/software developers to implement, and does everything Stratum does with a little more overhead (that probably won't be a problem for a while).
I agree GBT could benefit from adopting some of Stratum's design concepts (I wish slush participated in the GBT BIP process so these could have been integrated from the start!), but in practice we have plenty of time for that before it's an issue.
IMO, most likely the next-generation mining protocol to replace GBT (and Stratum) will use a persistent TCP connection, fully transparent, and probably based on the original Bitcoin p2p protocol (it has some convenient overlap, and eliminates the small JSON overhead both GBT and Stratum are subject to) - and maybe even a p2p-friendly design.

[DavinciJ15]

Bottom line I want GBT but stratum gets the job done faster and with less work for pools, miners and software producers.

In reality, GBT is much less work for pools/miners/software developers to implement, and does everything Stratum does with a little more overhead (that probably won't be a problem for a while).
I agree GBT could benefit from adopting some of Stratum's design concepts (I wish slush participated in the GBT BIP process so these could have been integrated from the start!), but in practice we have plenty of time for that before it's an issue.
IMO, most likely the next-generation mining protocol to replace GBT (and Stratum) will use a persistent TCP connection, fully transparent, and probably based on the original Bitcoin p2p protocol (it has some convenient overlap, and eliminates the small JSON overhead both GBT and Stratum are subject to) - and maybe even a p2p-friendly design.

This is my opinion based on what I have read in the threads here, I have no experience developing code for these mining protocols so you take my opinion for what it's worth. (not even a satoshi) :p

With that said it's easy to conclude that since cgminer and others have implemented stratum over GPT kind of gives my opinion a bit of legs to stand on. 

[wizkid057]

*snip*
Meanwhile, your solution at your pool was to reduce the number of transactions per block to 32 and ignore full paying transactions (Satoshi Dice) and who knows what else because of that.
I guess the reason you would not divulge that information before was that people would then know that your own pool was ignoring full paying transactions and that would show you as the hypocrite you are.
*snip*

I'm going to just chime in to address this particular comment, if for no other reason but to discredit the kano.

In a conversation yesterday evening this particular issue regarding Eligius was discussed on IRC, and kano was given a link to the post on this forum from months prior stating that these actions were being taken on Eligius.  Now, since I personally pointed this out to him, this post of his is clearly after I pointed this out (October 31, 2012, 10:05:21 PM is after both October 30, 2012, 11:57:55 PM and also well after the original post date below), and yet he still publicly says that this information was "not divulged before"? Well sir, you deserve to be called a liar, and it should be obvious that you are simply trying to discredit the work of others in the community, to what end I do not know.  Want the proof?  I'm not going to just make accusations without proof.  Here it is:

Bitcointalk post from June 17th 2012: https://bitcointalk.org/index.php?topic=23768.msg968819;topicseen#msg968819  This post clearly states publicly what the pool operator at the time decided to do with Satoshi Dice transactions and limiting the transaction count.

*snip*
For now, I am blocking transactions to 1dice* addresses and limiting our blocks to 32 transactions until we've caught up on the extra credit or at least have a viable alternative solution.
*snip*

For reference, here is a snippet of IRC log from yesterday evening (timestamps in UTC-0400):

Code:

[23:54:25] <wizkid057> 2012-10-30 23:57:57,913 merkleMaker     WARNING Making merkle tree with 132 transactions (ideal: 132; max: 132)
[23:54:27] <wizkid057> lol
[23:54:31] <wizkid057> 132 unconfirmed txns
[23:54:35] <wizkid057> without satoshidice
[23:54:36] <wizkid057> :P
[23:54:54] <con_> yet you still limit it to 32 ?
[23:55:00] <@kanoi> so every person on the planet who is running the official bitcoind shouldn't be is what you are saying
[23:55:02] <con_> urgh
[23:55:06] <wizkid057> con_: thats actually my personal pool
[23:55:21] <wizkid057> eligius is still 32 atm... was going to change that once I got the new reward system going
[23:55:41] <wizkid057> kanoi: shouldnt be what?
[23:55:45] <@kanoi> you are now gonna get a post in eligius about this ...
[23:55:52] <wizkid057> processing SD txns?
[23:56:00] <wizkid057> ok?
[23:56:03] <wizkid057> i'm confused
[23:56:06] * wizkid057 scratches head
[23:56:14] <con_> no, just all transactions
[23:56:21] <wizkid057> theres already posts in the eligius threads saying the 32 txn limit, and the SD filtering....
[23:56:24] <wizkid057> nothing new
[23:56:27] <con_> sure
[23:56:42] <@kanoi> yeah but pewople don't put 2+2 together ...
[23:57:49] <con_> again my complaint is the protocol as it stands encourages all pool ops to drop transactions
[23:57:55] <wizkid057> https://bitcointalk.org/index.php?topic=23768.msg968819;topicseen#msg968819 <--- satoshidice filtering ...... 

(anyone is welcome to entirety of this several hour conversation upon request.)

Tired of all the childishness around here, especially now that I've taken over management of Eligius.  Apparently that means that I get to field the BS that kano usually directs towards Luke-Jr, and I'm not going to tolerate that kind of trash.  It gets really old and is very counter productive.  Stop with the FUD because you're just making yourself look stupid.

-wk

[wizkid057]

Bottom line I want GBT but stratum gets the job done faster and with less work for pools, miners and software producers.

In reality, GBT is much less work for pools/miners/software developers to implement, and does everything Stratum does with a little more overhead (that probably won't be a problem for a while).
I agree GBT could benefit from adopting some of Stratum's design concepts (I wish slush participated in the GBT BIP process so these could have been integrated from the start!), but in practice we have plenty of time for that before it's an issue.
IMO, most likely the next-generation mining protocol to replace GBT (and Stratum) will use a persistent TCP connection, fully transparent, and probably based on the original Bitcoin p2p protocol (it has some convenient overlap, and eliminates the small JSON overhead both GBT and Stratum are subject to) - and maybe even a p2p-friendly design.

This is my opinion based on what I have read in the threads here, I have no experience developing code for these mining protocols so you take my opinion for what it's worth. (not even a satoshi) :p

With that said it's easy to conclude that since cgminer and others have implemented stratum over GPT kind of gives my opinion a bit of legs to stand on. 

By that logic you should say GBT is better because its actually built directly into the official bitcoin client.  I don't see how stratum is better just because cgminer implemented it.  Just because something is implemented somewhere prominent doesn't make it superior.

[kano]

I may not agree that it's an issue but Kano is not a troll for voicing his a opinion.  I have a YouTube channel and I get a lot of trolls and Kano sounds nothing like the trolls I get.  I got so many I did a video for them...

http://www.youtube.com/watch?v=8sQaIeHvuM0

It was funny and even the trolls loved it.

Hey D, big fan.

That being said, Luke's right. Kano's in this for profit more than love (obvious from his post history here if nothing else). In addition he tends to bend the truth past the breaking point quite often. These two statements are fact I'd encourage you to verify their veracity for yourself.

The following is my personal opinion which I happen to believe is right:

The reason that LukeJr supporters tend to discount poster like Kano is the simply because Luke has a technical mind, understands how things work and also is a proponent if not an advocate of the bitcoin network's need to be transparent. That's basically what this entire post is about... Luke (and myself and anyone who loves liberty) would rather take a slightly less streamlined process that we can see through than trust a pool op to inform us of what's happening. So sure, Stratum is less bandwidth at the cost of giving the pool op the ability do whatever they want behind it and the miners never knowing. It makes me wonder what they'd like to hide.

Also, I'd call it trolling when Kano comes here to decry the 'bad design' of GBT when the real issue is exactly what I've posted above... at the very least he's dishonest for not simply making his case for what it is... the desire to open a wedge into bitcoin that can be exploited later either by himself or others... without those of us actually doing the work knowing about it.

... another acolyte.
No I wont ignore that OT rubbish.

That being said, Luke's right. Kano's in this for profit more than love (obvious from his post history here if nothing else). In addition he tends to bend the truth past the breaking point quite often. These two statements are fact I'd encourage you to verify their veracity for yourself.

i.e. rubbish that you seem to think someone else has to prove and you can't since it's not true.

Please - show me these posts of mine you are talking about.
I'd love to have a read.

... and if you can't show them ... then I guess that shows how pointless your post is.

You do realise that every argument Luke-Jr and I have had about implementation issues in cgminer - he has later either done what I said or say he would do it ...

Transparency?

You've blindly decided to believe what Luke-Jr has said and not ever bothered to check it.

I've found this problem.

As for pools - that is simply you being too lazy to check what they do.

All the transactions that go into a block are shown in the block.
All transactions that do NOT go into a block are there for ANYONE to see.
If you don't want to spend ANY effort seeing what they are (as simple as reading the debug.log of bitcoind) that is your ignorance or laziness, nothing more.

--

Hmm you really gonna guess at my financial situation and motive?
And try to use that as an argument against me

firepop - subSTRATA - who's next?
I think the problems of higher difficulty and BTC halving are bringing the nut-cases out into the open.

--

Meanwhile ... as I've implied before ... anyone with a linux bitcoind:

Firstly have a look at the last few lines of your debug.log to see how big your memorypool is
Secondly ./bitcoind getblocktemplate

There are 2 issues here:
1) When getblocktemplate does return a lot of txn's per work request - see how large it is ... then consider what you have to send back in reply with each share you find

2) getblocktemplate also returns a small number of transactions when the memory pool isn't small ... say even when the memory pool is in the thousands ...

Arguing that the protocol design is good yet it allows (and all implementations currently use) this sort of thing is purely deceit.

This is what it currently does.
This needs to be fixed before those who don't check such things and believe the rubbish that Luke-Jr spouts start using it.
Oops - too late it's already in use ... oh well.

Actually, the biggest issue with GBT is the lack of GBT transparency itself in the comments the proponents make.
Ignoring or hiding the points about it that will negatively affect it's users and BTC.

Nice to see Luke-Jr actually mention ... some ... of them ... and yet again hide the important points.

Firstly, GBT is less work to implement ONLY because it uses an inferior method of data transfer that is already available and used by GetWork and bitcoind.

It has MUCH more overhead than Stratum.
Consider the data transfer size relationship to txn numbers.
As you mine until a block change, the txn number will continue to increase.
This leads to something that is in direct opposition to the requirements of BTC.
BTC requires transactions to be confirmed - the more the better.
However, with Stratum the relationship is order log2 N with GBT it is order N
Not only that, the size of the actual items sent are much larger in GBT.
GBT sends the whole transaction each time, Stratum just sends the side of the merkle tree and information for the coinbase transaction.
This give direct incentive to reduce the number of txns confirmed by anyone who implements GBT - including Luke-Jr himself on his own pool

Then of course there is

IMO, most likely the next-generation mining protocol to replace GBT (and Stratum) will use a persistent TCP connection

What Stratum already does - as he already knows.

Meh lots of posts while I was writing this ...

[-ck]

One more point about the GBT protocol. If a miner chooses which transactions they include rather than accept whichever transactions the pool/bitcoind has offered in the template, the miner has to submit all the transactions with every share he submits.

A quick check
./bitcoind getblocktemplate
at this very second produces a output that is 469441 bytes!

If every template request was this size and the miner used the customise coinbase option and chose transactions, they would be receiving 400kb for the block template and each share submitted would be 400kb unless they started withholding transactions.