How a floating blocksize limit inevitably leads towards centralization

[MoonShadow]

I've done nothing of the sort.  If I add a rule to my client that it quietly drops blocks that are over 250Kb, what have I done to you?

Nothing, but you've kicked yourself off the network (until a majority of mining power + a significant amount of full nodes on the network implement your rule too.

No, I haven't.  You don't even know that I dropped your block.  I can participate as a node just fine, just not as a miner.  It's a balance of forces.

[wtfvanity]

I don't understand. XMiningPool Inc. mines a block at 600kb. You ignore it. So in your block chain you go from 250,000 to 250,002?

[MoonShadow]

I don't understand. XMiningPool Inc. mines a block at 600kb. You ignore it. So in your block chain you go from 250,000 to 250,002?

No, I'm not saying that I actually reject an otherwise valid block, because it's bigger than I like.  That would certainly force a hard fork.  I'm saying that, as a client, I have a rule that does not forward blocks over my chosen limit to my other peers. If I'm alone, or otherwise in the minority on the issue, I've caused zero harm to anyone while managing to save myself some bandwidth.  However, if any significant minority of the total number of full clients that participate in the network, whether or not they mine themselves, also adopt this rule; the effective result is that this creates a delay in the propagation of overlarge blocks, effectively granting a bandwidth advantage to miners who choose to stay within the soft limit.  Thus, miners who create blocks over the limit effectively have their hashrate handicapped by delays in propagation.  As for myself, even if the block is overlarge, if it passes the standard "hard" block validity rules, it still does not get rejected from my own blockchain, as that would prevent myself from participating in the network in the event that said overlarge block is still the one that is built upon.  I'm doing nothing with my soft limit rule other than choosing not to forward the block.  

My highlighted sentence above implies that as the bandwidth requirements increase for full nodes, someone is going to implement something functionally similar anyway, in order to save bandwidth.  Worse would be for some programmer to take the easy route, and simply modify the code so that a full client quietly never forwards a valid block to it's peers, and it's peers never notice.

[Nagato]

So let me see if I have the math right according to the scalability article on Bitcoin.

Visa does 2000tps we can do 7. If Bitcoin scaled up to Visa, the wiki says we would need around an 8 megabits/second connection. That would create a block size of approximately 500 megs each. Am I hitting that number right? A home DSL connection would choke up with that and bandwidth caps at home would easily be exceeded. Nothing that serious miners or colocation couldn't handle.

CPU isn't an issue. At 72 GB a day serious pruning would have to be discussed.

At the minimum fee of 0.0005, that's over 600 BTC per block in fees if we increase the limit to 500 megs per block. But the discussion is we shouldn't make big blocks, so the fees increase for the miners? It seems like if you have a million transactions in a block, that there could potentially be more fees. Of course they are smaller fees, but there are much more of them.

As of today, there should be no reason that we could not move the maximum block size to 10x what it currently is and we would probably good for a very long time being able to process more than paypal can. When that wall is approaching we can discuss it again like Satoshi suggested.

No that is incorrect. With a 8mbit/s connection, you will merely be able to download blocks at the rate they are created, it will be impossible for you to mine.

Simplified:
500MB / 800KB/s = 625s ~ 10min
By the time you are done downloading the latest block and begin working on the next block, someone else has already found the next block.

[markm]

Okay but if you have somewhere in the neighborhood of three megaminers, of a scale about like one would get by Google buying deepbit, Paypal buying another, Amazon buying another, etcetera, Eligius either heaviliy sponsored by whatever coalition of bible-thumpers can add up to such scales or marginalised due to being actually trivially small in the new larger scale scheme of things, the only propagation that matters is the direct high bandwidth pipes between these superpowers. The 49% or less - the whole rest of humanity - gets a crumb from the superpowers' table less than 50% of the time and even within that demographic the bigger fish in that smaller pond can hook up directly to each other, and maybe even try to co-operate in finding sneaky ways to get more peeks faster at what the superpowers are actually working on in a given one block period, so quite possibly half or more of the 49% also are not affected by the relaying decisions of mere non-mining nodes.

Lets think for a moment of all those Jalapinos that once upon a time sounded like they could decentralise hashing power into every home. Are all those coffee-warmers going to have to be moved out from under livingroom or home-office coffeecups, co-located in data centres somewhere, if they are to be able to keep up with actually validating? They would, if they didn't actually validate, be merely rubber-stamping on behalf of someone else...

-MarkM-

[Nagato]

If we want to cap the time of downloading overhead the latest block to say 1%, we need to be able to download the MAX_BLOCKSIZE within 6 seconds on average so that we can spend 99% time hashing.

At 1MB, you would need a ~1.7Mbps  connection to keep downloading time to 6s.
At 10MB, 17Mbps
At 100MB, 170Mbps

and you start to see why even 100MB block size would render 90% of the world population unable to participate in mining.
Even at 10MB, it requires investing in a relatively high speed connection.

Also of importance is the fact that local bandwidth and international bandwidths can wary by large amounts. A 1Gbps connection in Singapore(http://www.starhub.com/broadband/plan/maxinfinitysupreme.html) only gives you 100Mbps international bandwidth meaning you only have 100Mbps available for receiving mining blocks.

[misterbigg]

If we want to cap the time of downloading overhead the latest block to say 1%, we need to be able to download the MAX_BLOCKSIZE within 6 seconds on average so that we can spend 99% time hashing.

At 1MB, you would need a ~1.7Mbps  connection to keep downloading time to 6s.
At 10MB, 17Mbps
At 100MB, 170Mbps

and you start to see why even 100MB block size would render 90% of the world population unable to participate in mining.
Even at 10MB, it requires investing in a relatively high speed connection.

Thank you. This is the most clear explanation yet that explains how an increase in the maximum block size raises the minimum bandwidth requirements for mining nodes.

Given this bandwidth limitation, here's a new proposal for the adjustment of maximum block size:

1) A boolean flag is added to each block. The flag represents the block solver's yes or no vote for increasing the block size. The independent miner or mining pool sets this flag according to their preference for an increase.

2) Every time the difficulty is adjusted, the number of yes votes is counted from the last adjustment. If the number of yes votes is greater than 90%, then the block size is increased by 1%. Both percentages are baked-in constants, requiring a hard fork to change.

[MoonShadow]

If we want to cap the time of downloading overhead the latest block to say 1%, we need to be able to download the MAX_BLOCKSIZE within 6 seconds on average so that we can spend 99% time hashing.

At 1MB, you would need a ~1.7Mbps  connection to keep downloading time to 6s.
At 10MB, 17Mbps
At 100MB, 170Mbps

and you start to see why even 100MB block size would render 90% of the world population unable to participate in mining.
Even at 10MB, it requires investing in a relatively high speed connection.

And practically speaking, most people would like to be able to use their broadband connection for other things.  Offically, my cable service is a 10Mbit/sec connection, but practically I can't sustain more than 1.5Mbps to any single IP address.  If I let my bittorrent client full access, it peaks around 1.5Mbps but averages about half that.  Your bandwidth needs are further complicated by the fact that once you have downloaded and verified a block, you're expected to then upload that block to your connected peers.  Since most broadband connections are half as fast uphill, this limits your connected peer's download to half of what you're offically capable of.  In conclusion, anything beyond a 1MB limit is too resource intensive for the at-home full client to be able to keep up with at present, but with the advancements in Internet tech and infrastructure, we can assume that an at home connection would be able to manage a 10-20 MB block within a decade.  We would want to aim for the hard limit to be at least this high, while continuing to depend upon soft limits in the meantime.

Also of importance is the fact that local bandwidth and international bandwidths can wary by large amounts. A 1Gbps connection in Singapore(http://www.starhub.com/broadband/plan/maxinfinitysupreme.html) only gives you 100Mbps international bandwidth meaning you only have 100Mbps available for receiving mining blocks.

International bandwidth is much more complicated than this, with respect to a p2p network such as Bitcoin.  Much like bittorrent, the bandwidth for Singapore is functionally replicated for all of the Bitcoin clients in all of Singapore, so it's not true that the international connection is divided among the many peers all trying to download the same block, it's effectively shared data as if there were a locally available seed on Bittorrent.  Granted, it's not the same as saying that all of Singapore could be regarded as one node, and then the block replicates across the entire nation-state from one copy; but once one copy of the block has made it across the bottleneck, the local bandwidth effectively becomes the limiting factor to propagation.

[MoonShadow]

If we want to cap the time of downloading overhead the latest block to say 1%, we need to be able to download the MAX_BLOCKSIZE within 6 seconds on average so that we can spend 99% time hashing.

At 1MB, you would need a ~1.7Mbps  connection to keep downloading time to 6s.
At 10MB, 17Mbps
At 100MB, 170Mbps

and you start to see why even 100MB block size would render 90% of the world population unable to participate in mining.
Even at 10MB, it requires investing in a relatively high speed connection.

Thank you. This is the most clear explanation yet that explains how an increase in the maximum block size raises the minimum bandwidth requirements for mining nodes.

Given this bandwidth limitation, here's a new proposal for the adjustment of maximum block size:

1) A boolean flag is added to each block. The flag represents the block solver's yes or no vote for increasing the block size. The independent miner or mining pool sets this flag according to their preference for an increase.

2) Every time the difficulty is adjusted, the number of yes votes is counted from the last adjustment. If the number of yes votes is greater than 90%, then the block size is increased by 1%. Both percentages are baked-in constants, requiring a hard fork to change.

Interesting, an intergrated voting method.  I can't say which direction that I'd consider it more likely that most miners would prefer, which is a good sign that it's a viable solution.  However, I don't know that I'd agree that a 1% change per difficulty adjustment is going to be enough.  After all, there will only be roughly 26 such adjustments in one year.  Taking into account the compounding of prior adjustments, off of the top of my head I'd guess that it's not possible for the blocksize to increase by more than 35% in one calender year.  And only then if all the vote adjustments move in the same direction.  I'd say a better number would be 5% per adjustment if the vote was a supermajority (i.e. 80% of votes in one direction) or 2.5% (or so) for a simple majority.  This would, at least, make it possible for the blocksize to double in a calender year, even if it doesn't make such an outcome likely.

[MoonShadow]

Okay but if you have somewhere in the neighborhood of three megaminers, of a scale about like one would get by Google buying deepbit, Paypal buying another, Amazon buying another, etcetera, Eligius either heaviliy sponsored by whatever coalition of bible-thumpers can add up to such scales or marginalised due to being actually trivially small in the new larger scale scheme of things, the only propagation that matters is the direct high bandwidth pipes between these superpowers. The 49% or less - the whole rest of humanity - gets a crumb from the superpowers' table less than 50% of the time and even within that demographic the bigger fish in that smaller pond can hook up directly to each other, and maybe even try to co-operate in finding sneaky ways to get more peeks faster at what the superpowers are actually working on in a given one block period, so quite possibly half or more of the 49% also are not affected by the relaying decisions of mere non-mining nodes.

Lets think for a moment of all those Jalapinos that once upon a time sounded like they could decentralise hashing power into every home. Are all those coffee-warmers going to have to be moved out from under livingroom or home-office coffeecups, co-located in data centres somewhere, if they are to be able to keep up with actually validating? They would, if they didn't actually validate, be merely rubber-stamping on behalf of someone else...

-MarkM-

This is such a contrived situation that I have to reject it as a strawman argument.

[misterbigg]

I don't know that I'd agree that a 1% change per difficulty adjustment is going to be enough.

All of the baked in constants are of course subject to tuning before final implementation. I used 90% and 1% as examples.

But remember that an increases in the blocksize translates directly into an increase in the minimum bandwidth requirements. Do you really want the minimum bandwidth requirement to double in one year? Even at 1% that still means that with a steady stream of successful votes, the minimum bandwidth requirement will increase by 12% per year. That's a lot.

Even a one time adjustment of the maximum block size to 2 megabytes would raise the bandwidth requirements to 3.4 Mbps. You're okay with this? If implemented today (assuming there was sufficient transaction volume) it would certainly preclude a large body of independent miners. Myself included (if the Jalapeno ever ships).

The penalty for increasing the maximum block size too slowly is that miners have large fees for a while. The penalty for increasing it too quickly is a loss of network hashing power and a centralization of mining power. Better to be conservative and adjust slowly.

...

This is such a contrived situation that I have to reject it as a strawman argument.

It is not contrived, it is precisely what would happen if the minimum bandwidth requirements were jacked up by a factor of 100 (which happens when you increase the maximum block size to 100 megabytes). I think he's just explaining it in terms that a non-technical person might understand.

[MoonShadow]

I don't know that I'd agree that a 1% change per difficulty adjustment is going to be enough.

All of the baked in constants are of course subject to tuning before final implementation. I used 90% and 1% as examples.

Granted.

Upon further consideration, I think that this might be a great way to move the soft limit, but I still think we need to have a (much higher) hard limit.  For the reasons that I stated before, and others, a hard limit removes many of the incentives for big players to engage in anti-competitive activities; since it puts a very real limit to the long term effectiveness of such underhanded methods.

[misterbigg]

I think that this might be a great way to move the soft limit, but I still think we need to have a (much higher) hard limit.

Did the earlier posts not sink in? The soft limit is not a proper limit, it is merely a thin road block designed to function as an early warning system. There's no "moving the soft limit." See my earlier post about analyzing the block chain to see the effect of the soft limit on miner behavior. As far as you are concerned, you should pretend as if the soft limit doesn't exist.

As for having a much higher hard limit, again did you not read the earlier posts? A 10 megabyte hard limit (which isn't even "much higher" in your terms) would raise the minimum bandwidth requirements to 17Mbps. Do you have any idea how many miners would be knocked off the network? In an earlier post you were just explaining the limitations of international bandwidth and also that solo miners would like to actually use their internet connections while they are mining. How can you then claim that we need a much higher hard limit, with its accompanying much higher minimum bandwidth requirements? Go back and re-read the chapter and then try answering the test questions again.

[MoonShadow]

I don't know that I'd agree that a 1% change per difficulty adjustment is going to be enough.

This is such a contrived situation that I have to reject it as a strawman argument.

It is not contrived, it is precisely what would happen if the minimum bandwidth requirements were jacked up by a factor of 100 (which happens when you increase the maximum block size to 100 megabytes). I think he's just explaining it in terms that a non-technical person might understand.

Well then, the way that he is presenting it becomes a strawman argument.  Could you show me why this is inevitable?  Are there really no other factors?  Does an increase in resource demands not also incentivize the bandwidth starved mining operation to invest in better infrastructure?  This is over simple, and does not consider that the infrastructure itself is not static.  There are also other resource factors to be considered, which may or may not be of greater influence.  I have, for years, predicted that the city of Reykjavík, Iceland will one day become a center of the Bitcoin mining industry; for the simple reason that they have both relatively low electric rates (due to the blessings of geothermal power) and a very high domestic heating demand.  This has not yet come to pass, but it's not because Reykjavík has substandard international bandwidth connections, because that's not so.

[MoonShadow]

I think that this might be a great way to move the soft limit, but I still think we need to have a (much higher) hard limit.

Did the earlier posts not sink in? The soft limit is not a proper limit, it is merely a thin road block designed to function as an early warning system. There's no "moving the soft limit." See my earlier post about analyzing the block chain to see the effect of the soft limit on miner behavior. As far as you are concerned, you should pretend as if the soft limit doesn't exist.

As for having a much higher hard limit, again did you not read the earlier posts? A 10 megabyte hard limit (which isn't even "much higher" in your terms) would raise the minimum bandwidth requirements to 17Mbps. Do you have any idea how many miners would be knocked off the network? In an earlier post you were just explaining the limitations of international bandwidth and also that solo miners would like to actually use their internet connections while they are mining. How can you then claim that we need a much higher hard limit, with its accompanying much higher minimum bandwidth requirements? Go back and re-read the chapter and then try answering the test questions again.

Don't be a dick.  I read your posts.  I believe that I understood them, but apparently you didn't understand my arguments.  The soft limit is a voluntary limit at present, but there are things that can be done to disincentive miners from attempting to break that limit when it suits them.  Did you not understand what I was trying to communicate concerning adding a 'soft limit' propagation rule to the clients?  Truly harmless to the network and the client, and only somewhat damaging to the miner, unless a significant enough of a minority of clients participate in this rule, and the miner with an overlarge block ends up with an orphaned block as a direct result.  It doesn't have to work every time, just enough for the miners to notice.

[misterbigg]

The soft limit is a voluntary limit at present, but there are things that can be done to disincentive miners from attempting to break that limit when it suits them.

Why on earth would we want to discourage miners from breaking the soft limit? The soft limit was intended to be broken! I'll repeat that...it is intended that eventually miners will remove the soft limit. I explained the reasoning behind the soft limit in this post (anyone feel free to correct me if I got it wrong).

Did you not understand what I was trying to communicate concerning adding a 'soft limit' propagation rule to the clients?

Yeah I understood it. It was based on an erroneous understanding of the soft limit and its intention. And, it does nothing to improve the current situation. So I did not comment on it.

Well then, the way that he is presenting it becomes a strawman argument.  Could you show me why this is inevitable?  Are there really no other factors?  Does an increase in resource demands not also incentivize the bandwidth starved mining operation to invest in better infrastructure?

Now you're saying exactly what he was saying. That Bitcoin mining and validation should have ever increasing minimum requirements of bandwidth, CPU, and storage. Every time the requirements are jacked up, it will put Bitcoin out of reach for some fraction of miners. Sure, some miners will remain (those who have the capital to invest in new equipment). But at each increase, there will be fewer miners. Continuing to its logical conclusion, mining will be an activity performed only by large entities with the capital necessary for the big up-front investment in equipment (data center, dedicated fiber line, server farms). That's exactly the example he was making with Google, et. al. being the sole providers.

Certainly I will no longer be able to mine with my one Jalapeno (if it ever ships). The idea of hundreds of thousands of individuals solo mining with their commodity ASICs (like the Jalapeno) will go down the drain. Which he also pointed out in his post:

Lets think for a moment of all those Jalapinos that once upon a time sounded like they could decentralise hashing power into every home...

Someone suggested a "really high limit" for the block size of one gigabyte. Now we know that would require dedicated bandwidth of 1.7Gbps (yeah that's right, giga). This doesn't sound practical at all, and I cannot take anyone seriously who would give this a shred of legitimacy.

[markm]

there are things that can be done to disincentive miners from attempting to break that limit when it suits them.  Did you not understand what I was trying to communicate concerning adding a 'soft limit' propagation rule to the clients?  Truly harmless to the network and the client, and only somewhat damaging to the miner, unless a significant enough of a minority of clients participate in this rule, and the miner with an overlarge block ends up with an orphaned block as a direct result.  It doesn't have to work every time, just enough for the miners to notice.

It is also truly harmless, that is, utterly uneffective in influencing them in any way, to the big miners.

Sure it might impact miners who are too small to have direct dedicated high bandwidth pipes to the top 51% miners, but the top 51% miners will not even notice if every one of you irrelevant non-mining nodes all stick your heads in the sand at every block on the chain. You just don't matter to the big boys, the most you could do would be help the big boys to shake the small players out of the game faster.

-MarkM-

[MoonShadow]

The soft limit is a voluntary limit at present, but there are things that can be done to disincentive miners from attempting to break that limit when it suits them.

Why on earth would we want to discourage miners from breaking the soft limit? The soft limit was intended to be broken! I'll repeat that...it is intended that eventually miners will remove the soft limit. I explained the reasoning behind the soft limit in this post (anyone feel free to correct me if I got it wrong).

Did you not understand what I was trying to communicate concerning adding a 'soft limit' propagation rule to the clients?

Yeah I understood it. It was based on an erroneous understanding of the soft limit and its intention. And, it does nothing to improve the current situation. So I did not comment on it.

Then comment upon it now, for you are working on an erroneous understanding of my proposal and it's implications.

Well then, the way that he is presenting it becomes a strawman argument.  Could you show me why this is inevitable?  Are there really no other factors?  Does an increase in resource demands not also incentivize the bandwidth starved mining operation to invest in better infrastructure?

Now you're saying exactly what he was saying. That Bitcoin mining and validation should have ever increasing minimum requirements of bandwidth, CPU, and storage. Every time the requirements are jacked up, it will put Bitcoin out of reach for some fraction of miners. Sure, some miners will remain (those who have the capital to invest in new equipment). But at each increase, there will be fewer miners. Continuing to its logical conclusion, mining will be an activity performed only by large entities with the capital necessary for the big up-front investment in equipment (data center, dedicated fiber line, server farms). That's exactly the example he was making with Google, et. al. being the sole providers.

That is a static view, and not one that is supportable.  With each smaller increment, the percentage of marginal miners forced out would be smaller than otherwise, and thus the likelyhood that they would be able to return as both their own local infrastructure and the average infrastructure improves.  The limits exist for several reasons, not the least of which is artificial scarcity, but we still have to balance the future against the present.  Even without my proposed propagation rule, I'm pretty sure that the 250KB limit has never been broken to date.  Why is that?  Do you presume that it's only because there are not enough transactions to justify it to the miners?  I would think that part of it is that the soft limit is an agreed upon rule, to be exceeded once that has been agreed upon also.  My rule would only add a bit of risk to ignoring this rule that doesn't presently exist.  I don't doubt that, eventually, some miners are going to test the soft limit.  I want some of those tests to fail.

Certainly I will no longer be able to mine with my one Jalapeno (if it ever ships). The idea of hundreds of thousands of individuals solo mining with their commodity ASICs (like the Jalapeno) will go down the drain. Which he also pointed out in his post:

Lets think for a moment of all those Jalapinos that once upon a time sounded like they could decentralise hashing power into every home...

That's conjecture.  Show me why you believe that this is so, not just your assumptions about what the future holds using overly simplified mental models.  Thus far you have failed to present an argument for this perspective.  I'm not even willing to claim that it's incorrect, only that it remains unsupported.  Can you really not imagine any other incentives that would contradict the "logical conclusion" you have come to?I can think of at least three.

Someone suggested a "really high limit" for the block size of one gigabyte. Now we know that would require dedicated bandwidth of 1.7Gbps (yeah that's right, giga). This doesn't sound practical at all, and I cannot take anyone seriously who would give this a shred of legitimacy.

Only someone who assumes that only a hard limit is actually the only limiting factor.  Again, we've already bumped up against the 250KB soft limit on several occasions; and amazingly, none of the miners have chosen to comment out that line of code.  Obviously there is some kind of cost to the miners for doing so, or a presumption of a cost, that would exceed the benefits to the miner for doing so.  One such cost is simply the work involved in commenting out that line of code and recompiling their mining programs over a relatively few number of tiny transaction fees.  That condition is bound to change, certainly.  This does not mean that miners will start to ignore the soft limit.  It is a community convention that, while not presently enforceble by the running protocol, is still enforceable by the community.  If some miner actually did this prior to the community deciding to raise that soft limit, the offender would prompt some kind of response.  What kind of response, I won't hazard a guess; but those miners certainly don't desire to prompt the community to include rules more strict than what I'm proposing.  It's not in the interest of the miners to invoke a response.

[notig]

I think that this might be a great way to move the soft limit, but I still think we need to have a (much higher) hard limit.

Did the earlier posts not sink in? The soft limit is not a proper limit, it is merely a thin road block designed to function as an early warning system. There's no "moving the soft limit." See my earlier post about analyzing the block chain to see the effect of the soft limit on miner behavior. As far as you are concerned, you should pretend as if the soft limit doesn't exist.

As for having a much higher hard limit, again did you not read the earlier posts? A 10 megabyte hard limit (which isn't even "much higher" in your terms) would raise the minimum bandwidth requirements to 17Mbps. Do you have any idea how many miners would be knocked off the network? In an earlier post you were just explaining the limitations of international bandwidth and also that solo miners would like to actually use their internet connections while they are mining. How can you then claim that we need a much higher hard limit, with its accompanying much higher minimum bandwidth requirements? Go back and re-read the chapter and then try answering the test questions again.

Don't be a dick.  I read your posts.  I believe that I understood them, but apparently you didn't understand my arguments.  The soft limit is a voluntary limit at present, but there are things that can be done to disincentive miners from attempting to break that limit when it suits them.  Did you not understand what I was trying to communicate concerning adding a 'soft limit' propagation rule to the clients?  Truly harmless to the network and the client, and only somewhat damaging to the miner, unless a significant enough of a minority of clients participate in this rule, and the miner with an overlarge block ends up with an orphaned block as a direct result.  It doesn't have to work every time, just enough for the miners to notice.

would that basically be like checks and balances? miners are checked from overly large blocks?

[Nagato]

International bandwidth is much more complicated than this, with respect to a p2p network such as Bitcoin.  Much like bittorrent, the bandwidth for Singapore is functionally replicated for all of the Bitcoin clients in all of Singapore, so it's not true that the international connection is divided among the many peers all trying to download the same block, it's effectively shared data as if there were a locally available seed on Bittorrent.  Granted, it's not the same as saying that all of Singapore could be regarded as one node, and then the block replicates across the entire nation-state from one copy; but once one copy of the block has made it across the bottleneck, the local bandwidth effectively becomes the limiting factor to propagation.

Sure but you would be slower by atleast the time taken by the fastest node in your country. To mine profitably, you would want to be well connected with all other mining nodes worldwide, so international bandwidth matters a great deal. Getting information 2nd hand potentially doubles your network overhead timewise.

A serious miner would want to have as much upstream bandwidth as possible to get his block out to as many relay nodes as fast as possible, so the upstream requirements should ideally match the download requirements.

Ofcourse i believe some of these issues can be optimised.
For example you could request a block with only the hashes of the TX it contains, and you use the transactions in your not-included TX pool instead of downloading them. For your average transaction this wont help much, but for transactions with many inputs and outputs, this could help reduce burst BW requirements significantly.

The more i think of it, the more it seems to me that even at 10MB, most residential miners without an expensive connection will be out of the game. And if you are a small miner who was hashing 2-10ghz, the cost of a more expensive connection will be more than the profit you bring in making it unviable.