Increasing MAX_BLOCK_SIZE to a larger but reasonable limit will still allow a fee economy and most users will still be able to run a full node.  Personally I believe block size needs to be limited, it just doesn't need to be limited at 1MB.  Raising it to some larger limit (5MB, 10MB, 20MB) would provide "breathing space" and time to develop a more comprehensive strategy for scaling bitcoin.

I think there are lots of differing views on MAX_BLOCK_SIZE and some try to make it binary choice.  These are just the views I have seen expressed:
a) "1MB now, 1MB tomorrow, 1MB forever"
b) Don't raise the limit "now" (where now can be anywhere from this year to next couple years)
c) Raise the limit but don't remove it                                                                                     
d) Remove the cap and hope the "free market" (which Bitcoin mining isn't) adapts without destroying this $1B experiment.
e) Implement some algorithm for raising the blocksize deterministically overtime.

In theory I prefer e over c but it should be discussed, analyzed, peer reviewed, and tested over an extended period of time, thus in the short term I prefer c.  I would also point out that despite the blocksize being 1MB most blocks (even with unconfirmed tx) are much smaller which means major miners are taking a cautious aproach to raising the actual block size they create.


As for low bandwidth residential users what I think really needs to happen is for the "wallet" and "node" functions of bitcoind to be separated*.  This would allow someone to run a full node on a VPS and their local wallet would communicate securely with their node.  The link between nodes won't get any lighter but the link between the user's wallet and their own full node will.  There are also alternatives like electrum, future SPV clients, eWallets, etc but I think the ability for a user to run a full node in the "cloud" and then connect securely to it would be powerful especially as the demands for a full node continue to rise. 


* Yes devs I have looked at the code and refactoring it will be a nightmare but it is something which needs to be done IMHO for a lot of reasons.  I would gladly contribute towards a bounty if someone with extensive knowledge is interested.

its not about microtransactions. In a year or two, 1mb wont be enough even for normal commerce with transactions only >10$.


btw the plan is to actually let the market decide the block size, not allow unlimited blocks.

Well said.  To put it into context PayPal is about 50tps.  I think a short term goal of Bitcoin eclipsing PayPal in transaction volume would be a pretty impressive milestone and that would require an average block size of ~10MB and given the transaction volume distribution by hour of the day (hmm maybe interesting to chart that out) that might require a max block size of ~20MB.

Is Gavin talk available on video?  I saw it at the conference but it might help in the discussion if the OP could link to the talk.

worse still, hitting the block size limit early, particularly before the clients start handling fees and pending transactions in a more graceful manner, might severly slow down bitcoin adoption. gavin thinks there is still around 12 month before we hit 1mb blocks. i think thats a very conservative estimation of bitcoin growth. imho, it might well happen within 3-6 months.


plus, current average computers and network connections can easily work with, say, 10mb blocks. there is no real risk or assumptions about future computer capabilities involved. a moderate increase in block size is a safe bet and it doesnt make any judgements about the necessity or viablity of some parallel or overlay technology to limit the number of on-chain transactions and blockchain size long-term.



dont make a practical discussion ideological. 1mb is much lower than necessary and might hurt bitcoin severly in the short term.

Agreed however there is a debate on if 1MB is "enough".  Most people would say it isn't and that likely means "enough" will be moved to a higher number at some point in the future and in some manner.  It would be smarter to focus on the how & when given that an increase eventually is an almost certainty.


Bitcoin was never designed with a 1MB limit initially.  You can check it doesn't exist in the early versions of the source code.  That was added later as a safety limit to prevent an early attacker from massively bloating the blockchain and thus killing off the project.  Imagine if in 2010 there was no block limit you had to download a 5TB blockchain just to start using this experimental currency with very little actual value or use.  Most people wouldn't and the "ecosystem" might have died in the crib.  1MB limited the size of the blockchain to no more than 52GB per year.  High and luckily early volume was much lower but it provided an upper bound while Bitcoin was young.  When the average block has 2 to 8 transactions it doesn't make sense for a single bad actor to add GB worth of transactions to hinder future users.  Bitcoin is far more developed now so it likely is time in the near future to take the training wheels off.


Sure.  However the debate becomes at what point and how much goes off blockchain.  In a perfect world I would say MAX_BLOCK_SIZE should be large enough to allow anyone to run a full node with "reasonable" resources.   Reasonably to be loosely defined as the resources (storage, computational and bandwidth) available to the dedicated user willing to pay for being a peer in a global network (in other words not everyone will be a full node but most "could" be a full node).  Yeah that is a very gray term but it is more important to look at what the MAX_BLOCK_SIZE does conceptually to the idea of centralization:

Lets look at two extremes futures where Bitcoin is massively adopted (say 100x current usage in terms of users, merchants, tx volume both on & off blockchain, etc):
average block size = 1MB.  max annual on blockchain tx volume = ~3.6 million transactions.  tx fees relatively high.  overwhelming majority of tx occur off blockchain.  the blockchain becomes sort of an open interbank settlement system *
average block size = 5GB.  max annual on blockchain tx volume = ~18 billion transactions.  tx fees relatively low.  most non-micro tx remain on blockchain.  the blockchain in theory can be used by anyone however the cost of a full node exclude most**

* At 1MB average block, while the cost of running a full node is relatively trivial the cost of transactions would exclude all but the largest bulk transactions.  Remember as subsidy declines the tx fees pay for the cost of securing the network.  So either Bitcoin is popular and thus fees are high (because only ~3.6 million tx can occur annually) or Bitcoin is unpopular and thus becomes less and less secure as the subsidy declines.

* at 5GB just about anyone running a full node can directly interact with the blockchain with low transaction cost however the resources for a full node would be on the order of:
- 262TB per year in storage requirements
- 500 mbps connectivity (bidirectional) this likely can be reduced up to 80% by optimal tx and blockheader sharing but it would still be high
- memory pool of ~2 blocks worth of tx would be ~26 million transaction thus RAM requirements (to avoid painfully slow disk lookups in validation) would be say something like 32GB.
- The UXTO is likely very large as the number of independent direct users of the blockchain are high.  It is hard to estimate but we can expect the UXTO to be large and efficient validation requires at lest a significant portion to be in high speed memory.

Both extremes result in centralization.
The low limit results in a centralization of transactions.  It becomes too limited and expensive to transaction on blockchain so most occur off blockchain.
The high limit results in a centralization of nodes. The extreme cost of running a node means there will be less of them.

The "optimal" blocksize would be one that perfectly balances the centralization of transactions against the centralization of nodes.   Now 1MB obviously isn't that perfect limit and whatever the limit is raised to likely isn't either but it certainly moving in the right direct.  In other words a 10MB limit is closer to optimal than 1MB is.

The "not designed for microtransactions" argument is irrelevant in this context, unless you consider $7.50 worth of bitcoins to be a microtransaction. As was stated earlier in the thread, a 1MB limit won't even allow for affordable MACRO transactions if we keep it where it is.

Current hardware could easily support 5-10-20 MB block sizes and we aren't even at a point where we need blocks that large. Stop making something out of nothing, folks.

In addition, a full-time dev has been 100% crowdfunded for the next 3-6 months to develop a lite node that is fully validating and requires 0 trust of any central server. This would make hardware issues moot for "average joe users" who don't want to rely on an online wallet if the full blockchain is too much for their 2008 box.

There is really no issue here aside from folks not doing their research and freaking out about problems that have already been solved.

Thanks @DeathAndTaxes
You have some good point here, that I had not considered.
Still, I don't quite understand the argument why 10MB is "better" than 1MB.
Better for who? And can to prove it?

Someone asked me whether $7.50 is a micro-transaction..
Well: if it's lower than the remaining 2000+ txs that went into a block - then yes.
Obviously whether something was a micro or not, is a relative term.
If you are aiming into Bitcoin becoming the new global currency, then even $1000 would be a micro-transaction.

I just mentioned that I read it all the time: "bitcoin is not for microtransactions" - and I agree with it.
But it was not my entry point - rather a by the way argument.

My point was: if it doesn't scale further, just get advantage of it's fine design that has a built in mechanisms to solve it.
Though, at the other hand, I understand the politics and the need to balance between the resource consumption vs. making the system available for anyone, in order for it to become successful.
So yeah, why not 10MB

This puppy ain't gonna fly with a 7 Transactions per second limit, even if it was only reserved for large transactions.