SatoshiDice, lack of remedies, and poor ISP options are pushing me toward "Lite"

[jgarzik]

If Satoshi thought that transaction fees would be how mining supported itself, that was just a guess. He couldn't possibly have known how it would eventually work out or even thought he could know. Note that some of his other guesses have proved wrong, like the popularity of sending directly to IP addresses.

Not quite.  Once the initial block reward is exhausted (negligible), fees are the only mining income.  So that leaves only two possibilities:  transaction fees would be how mining supported itself, or external incentives cause miners to mine at a loss (fee-wise).

[dree12]

If Satoshi thought that transaction fees would be how mining supported itself, that was just a guess. He couldn't possibly have known how it would eventually work out or even thought he could know. Note that some of his other guesses have proved wrong, like the popularity of sending directly to IP addresses.

Not quite.  Once the initial block reward is exhausted (negligible), fees are the only mining income.  So that leaves only two possibilities:  transaction fees would be how mining supported itself, or external incentives cause miners to mine at a loss (fee-wise).

(emphasis mine)

As computing times shrink, I expect big miners will be paid by big corporations and banks to directly deliver new blocks to them, bypassing the network and its latency. This is an example of an external incentive.

[justusranvier]

or external incentives cause miners to mine at a loss (fee-wise).

My back of the envelope calculations suggest this is a likely possibility.

[gmaxwell]

As computing times shrink, I expect big miners will be paid by big corporations and banks to directly deliver new blocks to them, bypassing the network and its latency. This is an example of an external incentive.

I don't see how this makes any sense at all without making additional assumptions which would make Bitcoin pointless. The stochastic nature of mining means that there is always large uncertainty about block delivery times— the block gap is frequently anywhere in an hour window.  Paying non-trivial amounts for trivially copyable data to get it seconds faster when the common arrival uncertainty was already an hour does not generally make sense for most applications.

Keep in mind that a little payment isn't sufficient, mining needs to be expensive enough that an attacker can't do a short term attack— doubly so in the future because there will no subsidy motivation for honest behavior anymore, the motivation to behave honestly would be fees and preserving their value— Without the proof of work Bitcoin is just a particularly computationally and bandwidth expensive rumoring network totally vulnerable to network attackers.

You might be assuming that the miners would keep blocks secret from parties that don't pay them, but this can only be done if mining is centralized since otherwise a miner who promotes their block further faster gets built on and they become the valid block.  Moreover, block secrecy violates the less discussed second half of the Bitcoin security assumption:  Bitcoin assumes that honest parties control a majority of the mining applied computing power _and_ that information is easy to spread and hard to stifle.  The latter part is critical because you can only converge on the longest chain if you've actually heard of it. We don't talk about it much because it's not hard to meet today and you have bigger problems if you can't even get the blocks... but it really precludes any kind of paid access to blocks from being viable.

As far as the OP's issue— it would be pretty easy to add a trickle mode to the client where it only connects to the network periodically and only fetches blocks just to avoid failing behind. So you'd leave it running... but it would only connect to a few peers on the network ever half hour or so, pull new blocks and disconnect, then process them slowly and unintrusively. But I don't think there is enough demand for such a thing to bother coding and testing it.  Maybe that sort of thing could become the default behavior for minimized gui full nodes that aren't listening, but I dunno— differences in behavior create confusion.

[theymos]

Later on, we can use the usual mechanism for phasing in rule changes - have new block or transaction version numbers express acceptance of the new rule set and automatically begin enforcing them if/when more than a certain percentage of users have opted in (probably a very high percentage).

That's a terrible way of deciding an important issue such as this. Miners are not a very important part of the Bitcoin economy, and they don't have much more understanding of Bitcoin than anyone else. Their "votes" shouldn't matter more than anyone else's. (There shouldn't be general voting at all, in fact -- democracy is a poor way of making decisions.)

restricting the block size in the long term for the exclusive purpose of keeping transaction fees high is a form of central planning. If artificially restricting supply in order to manipulate prices worked to create a healthy economy, there wouldn't be so many people trying to leave managed economies for Bitcoin.

The block size limit doesn't need to be centrally-determined. Each node could automatically set its max block size to a calculated value based on disk space and bandwidth: "I have 100 GB disk space available, 10 MB per 10 minutes download speed and 1 MB per 10 minutes upload speed, so I'll stop relaying blocks [discouraging them] if they're near 1/8 MB [enough for each peer] and stop accepting them at all if they're over 2MB because I'd run out of disk space in less than a year at that rate". If Bitcoin ends up rejecting a long chain due to its max block size, it can ask the user whether he wants to switch to a lightweight mode.

Users could also specify target difficulty levels that they'd like the network to have and reduce their max block size when the network's actual difficulty level drops below that. A default target difficulty level could maybe be calculated based on how fast the user's computer is -- as users' computers get faster, you'd expect mining to also get faster.

[greyhawk]

And it appears to be approaching the rate of 300 transactions per block (about 43K transactions per-day).  
 - http://blockchain.info/charts/n-transactions-per-block?timespan=180days&daysAverageString=7

This is a transaction every two seconds.

A lot of these are microtransactions (e.g., under a dollar's worth of coins) used for wagering, so the blockchain already has a way of limiting those:

It's doubtful that anyone will be able to hold the entire blockchain at some point in the future, should Bitcoin become a mainstream thing.

Here's some interesting data (from 2006 only for the US)

Average daily number of transactions:
- 60 Million credit card transactions
- 100 Million Interbank ATM transactions
- 60 Million ACH transactions
- 15 Million SWIFT transactions
- 365.000 CHIPS transactions
- 521.000 FEDwire transactions
- 700.000 CLS transactions

So that's a cool 237 Million daily transactions, in the US alone, excluding cash transactions.

Let's assume a conservative average of 3 daily cash transactions per person (buying the paper, a hotdog and a pack of smokes). That adds a cool 1000 Million transactions for the US alone right there.

Yeah. Better go grab a YottaByte HD real quick.

[Meni Rosenfeld]

And it appears to be approaching the rate of 300 transactions per block (about 43K transactions per-day).  
 - http://blockchain.info/charts/n-transactions-per-block?timespan=180days&daysAverageString=7

This is a transaction every two seconds.

A lot of these are microtransactions (e.g., under a dollar's worth of coins) used for wagering, so the blockchain already has a way of limiting those:

It's doubtful that anyone will be able to hold the entire blockchain at some point in the future, should Bitcoin become a mainstream thing.

Here's some interesting data (from 2006 only for the US)

Average daily number of transactions:
- 60 Million credit card transactions
- 100 Million Interbank ATM transactions
- 60 Million ACH transactions
- 15 Million SWIFT transactions
- 365.000 CHIPS transactions
- 521.000 FEDwire transactions
- 700.000 CLS transactions

So that's a cool 237 Million daily transactions, in the US alone, excluding cash transactions.

Let's assume a conservative average of 3 daily cash transactions per person (buying the paper, a hotdog and a pack of smokes). That adds a cool 1000 Million transactions for the US alone right there.

Yeah. Better go grab a YottaByte HD real quick.

I think it is agreed that most Bitcoin payments won't take place on the blockchain. e.g., with tx replacement you can have one transaction carry multiple payments, and there can be various 3rd party services (I'm using "various" in a mostly positive sense - Bitcoin enables possibilities with good tradeoffs, better than the current banking system) . So 1B daily payments doesn't mean 1B daily transactions. The more transactions can actually make it to the blockchain, the lesser the overall "tax" (in the broadest sense) of using additional layers.

[gmaxwell]

I think it is agreed that most Bitcoin payments won't take place on the blockchain. e.g., with tx replacement you can have one transaction carry multiple payments, and there can be various 3rd party services (I'm using "various" in a mostly positive sense - Bitcoin enables possibilities with good tradeoffs, better than the current banking system) . So 1B daily payments doesn't mean 1B daily transactions. The more transactions can actually make it to the blockchain, the lesser the overall "tax" (in the broadest sense) of using additional layers.

Exactly.

Bitcoin is fundamentally not very good as a payment network. Global visibility is not compatible with high scalability and the security global-visibility provides somewhat unnecessary for pretty much anything short of the inflation resistance of the system... 99.999999% of the world does not care about the security of every dumpling bought in china. The nature of Bitcoin makes many worthwhile mechanisms like anti-fraud and instant fairly-firm resistance to reversal hard or impossible without attentional layers.  Bitcoin needs to be something of a payment network to be useful at all and the better of one that it is the less costly payment networks will and must be, so it's desirable to make it the best it can be— but it's not worthwhile to compromise the unique values that make it worth having, since no amount of compromise can free you from payment networks.

I think if more of the effort spent speculating on likely impossible modifications to Bitcoin itself (I don't mean the block size stuff as much as stuff like demurrage) was spent on inventing decentralized payment infrastructure we'd make a lot more progress. Remember, that one of the attractions of Bitcoin is that there is no centeral bank telling you that you can't invent new payment systems.  Bitcoin has solved the hard part in this ecosystem: invent a purely decentralized digital asset which people will recognize as valuable. Now interested parties can go figure out how to optimally exchange it with others.  Plus, when building a new system you're free to design in whatever features you think are important without being called a thief, and the public is free to choose not to use it. Bitcoin gives you an existing cryptocurrency ecosystem so getting value into it at all isn't a problem. Win win win. 

It makes me sad that in so many technology discussions people penalize things for being more flexible.  Were it possible for bitcoin to be usable with no payment network functionality at all it would still be awesome.  It seems when something can do five different things all the 'experts' on the Internet think it's appropriate to demand that it be the absolute best at each thing and that it sucks if it isn't. Sorry kids: Real engineering is all about compromises.

[dree12]

As computing times shrink, I expect big miners will be paid by big corporations and banks to directly deliver new blocks to them, bypassing the network and its latency. This is an example of an external incentive.

I don't see how this makes any sense at all without making additional assumptions which would make Bitcoin pointless. The stochastic nature of mining means that there is always large uncertainty about block delivery times— the block gap is frequently anywhere in an hour window.  Paying non-trivial amounts for trivially copyable data to get it seconds faster when the common arrival uncertainty was already an hour does not generally make sense for most applications.

Keep in mind that a little payment isn't sufficient, mining needs to be expensive enough that an attacker can't do a short term attack— doubly so in the future because there will no subsidy motivation for honest behavior anymore, the motivation to behave honestly would be fees and preserving their value— Without the proof of work Bitcoin is just a particularly computationally and bandwidth expensive rumoring network totally vulnerable to network attackers.

You might be assuming that the miners would keep blocks secret from parties that don't pay them, but this can only be done if mining is centralized since otherwise a miner who promotes their block further faster gets built on and they become the valid block.  Moreover, block secrecy violates the less discussed second half of the Bitcoin security assumption:  Bitcoin assumes that honest parties control a majority of the mining applied computing power _and_ that information is easy to spread and hard to stifle.  The latter part is critical because you can only converge on the longest chain if you've actually heard of it. We don't talk about it much because it's not hard to meet today and you have bigger problems if you can't even get the blocks... but it really precludes any kind of paid access to blocks from being viable.

As far as the OP's issue— it would be pretty easy to add a trickle mode to the client where it only connects to the network periodically and only fetches blocks just to avoid failing behind. So you'd leave it running... but it would only connect to a few peers on the network ever half hour or so, pull new blocks and disconnect, then process them slowly and unintrusively. But I don't think there is enough demand for such a thing to bother coding and testing it.  Maybe that sort of thing could become the default behavior for minimized gui full nodes that aren't listening, but I dunno— differences in behavior create confusion.

I never claimed that the payment would replace fees. In fact, I believe fees should and will be here to stay. I meant that as an example that in the future, mining revenue is not entirely dependent on fees — therefore, the withdrawal of the block subsidy is unlikely to have as great an effect as people make it out to be.

[gmaxwell]

I never claimed that the payment would replace fees. In fact, I believe fees should and will be here to stay. I meant that as an example that in the future, mining revenue is not entirely dependent on fees — therefore, the withdrawal of the block subsidy is unlikely to have as great an effect as people make it out to be.

Except you didn't actually substantiate your claim.

[EskimoBob]

S.DICE spam is just a prelude. 
It sure starts to sound like that we are circling back to what we are running away from - central control by few large entities. I guess we must be blindfolded and our imaginary straight line away from here, takes us back where we started.
Few huge mining farms will become the new "central banks" or "FED", if I may, and nothing has really changed. They will control the fees, the software features, protocol etc. BTC will be really convenient to use and it's accepted widely, but we as a community, have no vote/controll/etc over it. You win some, you lose some
Small guy is kicked out of the mining picture, bloated blockchain requires absurd amount of space and user will never ever download the full bc. Nobody really knows, is the existing BC the correct one or not. Only "Banks" know and you can be probably wiped out financially or blocked to use your funds as you are now.

Time to get over this childish "Staoshi knows everything" hysteria and start thinking about the worst outcomes and how to avoid it.

[grau]

Small guy is kicked out of the mining picture, bloated blockchain requires absurd amount of space and user will never ever download the full bc.
Nobody really knows, is the existing BC the correct one or not. Only "Banks" know and you can be probably wiped out financially or blocked to use your funds as you are now.

Yes. The longer we maintain unworldly policies like relaying zero fee transactions and dust the faster this will happen.

What we might choose is if the "Banks" will be the old ones or we provide funding to some arising out of this new community. The first step for the second alternative is to reduce funding dependency on inflation by enforcing fees.

The same applies to funding innovation that ensures the decentralized nature of the system is preserved to the extent possible.

[jl2012]

The current blockchain size is about 4.5G. If we prune all spent outputs, what the size would be?

[Jeweller]

This is one of the most interesting threads I've seen here -- made an account to reply.

A lot of people have different ideas about the importance of this block size limit, and I think it's useful to separate opinions about what "should" happen, and more objective analysis of what "will" happen.

And thinking about it, to me it looks like the 1MB block size is here to stay.  I'm not really sure what that means for bitcoin, if it's "good" or "bad", but here's why I think it's permanent.

First, it's a hard fork.  Every node right now, to my knowledge, will reject any block coming in at over 1MB.  Miners included.  ANY kind of hard fork is going to be really hard to implement due to the size of the network.  But if a hard fork does benefit everyone, or almost everyone, it could be planned in advance and switched to at some date.  As long as most (substantially more than 51%) of nodes switch to the new protocol in a coordinated way, a hard fork change could work. (BTW, has this ever happened?  I haven't heard of it but maybe it has?)

But in the case of removing the 1MB limit, I don't think the agents involved here will agree.  Specifically, the miners.  SatoshiDice would certainly be on board for 1GB blocks, as would BitPay, Gox, and I'd imagine most end users.  But I think miners have incentive to maintain the 1MB limit.  The limit creates an (artificial?) scarcity for what they are providing / selling: inclusion in the block chain.  If there's only room for ~4K transactions per block, thus only ~1M transactions a day, a spot in that blockchain is going to be quite valuable if millions of people want in.  Transaction fees could be quite high, making only large transfers feasible.

A transition to larger block sizes would thus be resisted by miners.  While you might say, "Well, at 10MB / block there's potential for 10X as many transactions, thus 10X the fees" I don't think it would work that way.  But in fact, I don't think this will ever be tested; all you need is miners to resist this change due to uncertainty.  Some miners might like to increase the size limit, but many won't.  Having large groups of miners disagreeing on fundamental protocol aspects sounds like a disaster for bitcoin.  Basically, to me, the network of miners IS bitcoin; they provide the power to run the network, and are compensated to do so.  If the miners aren't 100% for it, it's just not going to happen.

So I'd like to hear from people who agree, but mostly who disagree with me; how do you think this modification of the protocol could play out?  How would the miners get on board?  Do you think miners would in fact want bigger blocks, and why?  This seems like a very relevant discussion to have right now.  We could be hitting 1MB blocks in a matter of months.

[gmaxwell]

(BTW, has this ever happened?  I haven't heard of it but maybe it has?)

There has never been a hardforking change of the blockchain protocol rules.

There has however, been a 'hardforking' change of the on-the-wire P2P gossip protocol. A checkvalue was added all messages (negotiated, so compatible) but the negotiation itself got a checkvalue too after a two year time delay (and all nodes switched to the new new negotiation at a hard coded time). It caused a few minor issues but no major disruption.

We've also made softforking changes— changes which strictly reduced the set of acceptable things, so they need some coordination of mining to prevent the formation of forks but don't require a 100% upgrade— and there is one going on right now: https://en.bitcoin.it/wiki/BIP_0034

There are ways you could make increasing the blocksize technically soft-forking change (by having an auxblock committed in the block, and once coin is moved by the auxblock it may never be spent in the real blocks) but it would be hideous and pretextual.  But along those lines, it would also be technically possible to integrate a lower security high volume payment blockchain as a pure softfork.  The idea is that txn would be send to an address on the rapid payment blockchain using an output script that looks like an anyone can spend to old nodes.  New nodes would require that some evidence be presented (via some channel) before accepting a transaction that moves those coins back into the bitcoin network (perhaps a SPV like fragment proving the merge mined federated system agreed with the change?).  (Perhaps by admitting this possibility I can get people to stop obsessing over the block size?  There are a lot of possible things to do here, I personally prefer generally isolated systems because I think that people should have a choice. But even if you demand that it must be part of "bitcoin" that doesn't mean we have to increase the block size)

Oh, and welcome to the forum!

[2112]

There has never been a hardforking change of the blockchain protocol rules.

So how do you call the hard fork that occured after a fix to the integer overflow issue?

https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5139

[Meni Rosenfeld]

First, it's a hard fork.  Every node right now, to my knowledge, will reject any block coming in at over 1MB.  Miners included.  ANY kind of hard fork is going to be really hard to implement due to the size of the network.  But if a hard fork does benefit everyone, or almost everyone, it could be planned in advance and switched to at some date.  As long as most (substantially more than 51%) of nodes switch to the new protocol in a coordinated way, a hard fork change could work. (BTW, has this ever happened?  I haven't heard of it but maybe it has?)

In case it's not clear, the advance planning is done in software. That is, if we decide right now it should be changed, we add the line "if blockheight > 270000 then sizelimit = 10MB" to the upcoming software version. Then anyone who upgrades his client within the next half year will automatically switch when the time comes.

But in the case of removing the 1MB limit, I don't think the agents involved here will agree.  Specifically, the miners.  SatoshiDice would certainly be on board for 1GB blocks, as would BitPay, Gox, and I'd imagine most end users.  But I think miners have incentive to maintain the 1MB limit.  The limit creates an (artificial?) scarcity for what they are providing / selling: inclusion in the block chain.  If there's only room for ~4K transactions per block, thus only ~1M transactions a day, a spot in that blockchain is going to be quite valuable if millions of people want in.  Transaction fees could be quite high, making only large transfers feasible.

A transition to larger block sizes would thus be resisted by miners.  While you might say, "Well, at 10MB / block there's potential for 10X as many transactions, thus 10X the fees" I don't think it would work that way.  But in fact, I don't think this will ever be tested; all you need is miners to resist this change due to uncertainty.  Some miners might like to increase the size limit, but many won't.  Having large groups of miners disagreeing on fundamental protocol aspects sounds like a disaster for bitcoin.  Basically, to me, the network of miners IS bitcoin; they provide the power to run the network, and are compensated to do so.  If the miners aren't 100% for it, it's just not going to happen.

A limit on the data size of a block isn't the only or even the most efficient way to keep demand for transactions high. The marginal cost of handling the tx size is expected to be much lower than the amortized cost of hashing to secure it, so artificial scarcity in the former to sponsor the latter creates perverse incentives.

I favor a structured fee solution that takes into consideration the different costs. A component for storing and broadcasting data (e.g. data size limit); a component for signature verifications (e.g. limit on the number of signatures); and a (much more significant) component for miners' bargaining power in demanding payment for their hashing (e.g. limit on the total amount of bitcoins transferred).


Even in case data size limit remains as a rough approximation to encompass all three: Sure, at some point increasing the supply of transaction room will greatly reduce the price and the total revenue. But miners will also understand that if the limit is too low, the usability of the Bitcoin system at large is reduced, which will harm growth and potential total revenues.

If a majority cartel of miners decides anyway to reject all blocks with increased size limit, despite this being the new protocol agreed by the economic majority, this is none other than a >50% DoS attack. Whatever tools we come up with to handle that (e.g., moving to a block DAG structure) will apply.

[Mike Hearn]

A lot of these are microtransactions (e.g., under a dollar's worth of coins) used for wagering

Actually a lot of them are not really "used for wagering", they're (ab)used as a way to send messages to the client the wagerers are using. Part of the point of the payment protocol work is to give sites like SatoshiDice a messaging system that doesn't require assigning meaning to magic quantities of money.

By the way, SatoshiDice is (afaik) not using compressed pubkeys. That's because bitcoinj doesn't use them. SatoshiDice is open source, it uses a fork of the library. We can probably halve the amount of data it generates just by fixing that.

But twelve months ago no SatoshiDICE existed and nobody knows what 2013's breakaway Bitcoin success story will be but what if there are four of them, each as popular as SatoshiDICE is today.    Then the blockchain size limit (at the current restrictions) will be reached.

I fully agree we will reach the block size limits at some point, if only because people will come up with uses for micropayments beyond wagering. I think expecting a quadrupling of tx volume is optimistic, but hey, we're on the same side here. This is why I want to see the block size limit float.

It's doubtful that anyone will be able to hold the entire blockchain at some point in the future, should Bitcoin become a mainstream thing.

Your calculations are useful if my "mainstream thing" you mean "one world currency used for everything", which could only conceivably occur in some Star Trek future. If that does occur then yottabyte storage - for a few parties at least - is hardly inconceivable. I mean there was a time when "hold the web in RAM" sounded absurd yet multiple companies do it today. You don't need many parties to store the entire block chain because all other nodes can prune and only have to handle the working set size.

The current blockchain size is about 4.5G. If we prune all spent outputs, what the size would be?

It's on the order of a couple hundred megs. I forgot the exact size. Perfectly feasible to hold entirely in RAM for now.

That's a terrible way of deciding an important issue such as this. Miners are not a very important part of the Bitcoin economy, and they don't have much more understanding of Bitcoin than anyone else. Their "votes" shouldn't matter more than anyone else's. (There shouldn't be general voting at all, in fact -- democracy is a poor way of making decisions.)

You're right, I guess everyone should just do what I say instead. That's far more efficient. Good to hear you'll be on my side when the time comes

Obviously for a hard forking change it's economic majority that matters, not miner majority. That's why I said maybe transaction version numbers should be adjusted instead/as well. For the majority of participants who have no opinion one way or another, they will just upgrade to whatever their client developers deem best.

Every node right now, to my knowledge, will reject any block coming in at over 1MB.  Miners included.

This will shortly cease to be the case because SPV clients are going to start receiving filtered blocks, so cannot check their size. Sooner or later the majority of all users will be on SPV clients. Whether this equates to the majority of economic activity is still uncertain - I'd hope most merchants run their own full node, but I honestly don't know what the makeup of Bitcoin-using merchants will look like over time.

But in the case of removing the 1MB limit, I don't think the agents involved here will agree.  Specifically, the miners.  SatoshiDice would certainly be on board for 1GB blocks, as would BitPay, Gox, and I'd imagine most end users.  But I think miners have incentive to maintain the 1MB limit.

If all economic actors except some miners want the change then it's just equivalent to a 51% "attack" - if you can get a majority of hash power to agree, then the rest of the miners have to go along with it or see no income at all.

However, I think in the presence of a working alternative funding model most miners would accept larger blocks. I don't think there's any advantage to artificially throttling Bitcoins scalability if funding is not obtained via user-levied fees. I know gmaxwell argues strongly that allowing Bitcoin to scale would destroy its decentralization, but again I disagree.

Anyway, these are old, tired debates. The answers will become clear nearer the time.

[Pieter Wuille]

By the way, SatoshiDice is (afaik) not using compressed pubkeys. That's because bitcoinj doesn't use them. SatoshiDice is open source, it uses a fork of the library. We can probably halve the amount of data it generates just by fixing that.

It only saves you 32 bytes per txin, so more something like 20%. That said, yes, that would be a very welcome change.

It's on the order of a couple hundred megs. I forgot the exact size. Perfectly feasible to hold entirely in RAM for now.

In the format used by the current git head of the reference client (which will become 0.8 ), it's about 122 MiB now. Together with indexes and other overhead added by LevelDB, it's 143 MiB. Unpacked in RAM it's probably close to 5x as much (though there is little reason to have the entire database unpacked in memory).

[nevafuse]

There _must_ be competition for block space to make fees a viable way to pay for security.   

Limiting block space isn't the only way to increase mining fees.  Removing/reducing the block reward has the same effect.  Once the reward is less than the cost to mine, most miners will require a tx fee.  Given this incentive, there's really no reason to limit the block size.  It is in the miners best interest to set the limit as high as possible so they can receive the maximum amount of tx fees possible.  For this reason alone I foresee the block limit rising significantly.

Someone could try to disrupt the network with an extremely large block that contains millions of satoshi transactions, but it wouldn't be worth the effort.  Not to mention, miners could set their own size limits (for just this reason) & the consensus could be to orphan the block.