The Block-Size Problem
The main concern with raising the block-size limit is that the blockchain will grow at an unsustainable rate that nodes will eventually not be able to support. Thus, the currently 60GB blockchain will eventually become 1TB, 100TB, and more as adoption grows, and this will be accelerated with an increased block-size.
However, in order for a currency to be useful people MUST be able to spend it. The artificial 1MB block-size limit puts a cap on this, and so because of the growth we will soon hit this artificial barrier, at which point it will not be possible for everyone who wants to perform a transaction to be able to perform a transaction regardless of the fees paid. This is good for miners in the short-term because fees will be driven up, but bad for both them and the Bitcoin economy because again, a currency is ONLY useful if you can spend it.
There is no way around keeping the entire transaction history of the world in the blockchain, and there is no way around that it will be massive if world-wide adoption happens. Satoshi knew this that and believed Moore's law would let technology improve fast enough where storage space for the entire chain would not be an issue for those wanting to run full nodes, and I believe he's correct. However, if Bitcoin is widely adopted only an elite group of full nodes dedicated to this will be able to handle this amount of data.*
Satoshi knew this, and so in his original paper he foresaw that most clients would not care about the entire transactional history of the world, and would instead only care about the values in each account. Thus, he mentioned the concept of nodes "pruning" the blockchain. However, his idea was that this pruning process would be off the blockchain, and so currently to prune the chain you must either download the entire chain and prune it yourself or download the pruned chain from a trusted source. Since a main design principle of Bitcoin is that it tries to eliminate the need for trust, any node who agrees with this must download the full chain, validate it, and prune it.
"Pruning Blocks" Proposal
Add a special block at regular intervals into the blockchain called the "Pruning Block". This block will eliminates the need to download or keep the entire chain for partial nodes, but still gives them a very similar level of trust as downloading the full chain.
Pruning Block Requirements
1. The Pruning Block shall be a special block that occurs every X blocks
a. X shall be determined by votes from the community. For example, to have the pruning block approximately once per week it could start at 6 * 24 * 7 = 1008
2. The Pruning Block shall contain the regular transaction information so as not to disrupt normal business
3. The Pruning Block shall contain an appended list of all addresses that contained a balance along with the associated balance as of the previous block.**
a. The amended balances shall NOT be included in the calculation of the hash of the block***
b. The hash of the amended balances SHALL be included in the block***
c. The hash of the amended balances SHALL be included in calculation of the hash of the block***
d. The balances shall not take into account the transactions for this pruning block***
4. The Pruning Block shall only be accepted by clients if it matches all of the regular block requirements plus the aforementioned requirements.
a. The block-size cap shall not consider the appended list of balances in its block-size calculation
Problems
The main problem with this is if someone maliciously inflates the number of addresses to increase the size of the pruning blocks. For example, they could take 10 bitcoins and split them into 1 billion addresses with 1 satoshi in each as an attack, which would blow the pruning block size from 13.5MB to 27GB. This would normally be prevented because of transaction fees and block-size caps. However, if the block-size cap was removed completely and the attacker mined a block and sent the transactions through with zero-fees, this would be theoretically possible. In the process of doing this they would be hurting themselves, as they would not only be throwing money away, but also devaluing the currency they are significantly invested in with their mining operation (as it takes a lot of power to mine a block nowadays). However, because of this problem it is recommended that the block-size limit be removed entirely.
Results on blockchain
If Pruning Blocks were implemented today, the effect on the entire blockchain size would be minimal. For example, if we assume the current max block-size of 1MB was used for each block, the Pruning Block would be about 14.5MB**. If the pruning block was set to occur weekly (every 1008 blocks), the growth-rate of the blockchain would be only 1.34% faster than without pruning blocks (1021.5MB/week vs 1008MB/week). Thus, full nodes would only be affected by this change by a small amount.
However, the effect for partial nodes is very noticeable. Instead of downloading the full 60GB blockchain and pruning, miners would only need to download blocks back to the last pruning block. With 1MB block sizes and a pruning block weekly, this would range anywhere from .0145GB to 1.0215GB. Furthermore, once the next valid pruning block arrives, the node can clear out all the previous blocks. In this way the storage requirements for the pruned blockchain will be much more manageable and consistent, as they would only grow when Bitcoin adoption/use increases.
More importantly, this solution will remove many of the concerns about raising the artificial block-size limit. This is because storage/download requirements for nodes will no longer be based on the number of transactions in the history of the world, but instead be based on the number of addresses with a balance and a small subset of recent transactions. This will lend itself to nodes being much more willing to accept larger and larger transaction blocks, as they only need to keep them until the next pruning block. For example, 60GB is very low upper-limit for current storage requirement for each node, as that is what full nodes are storing right now, and also what untrusting partial nodes must initially download. To get this value for partial nodes, the maximum block-size can be set to 50MB, which would allow the current Bitcoin ecosystem to be able to process 50 times more transactions than it supports today, while at the same time putting no extra memory burden on the existing nodes of today.
*If all 7.125 billion people averaged 1 transaction per day at 500 bytes/transaction (the current average), the blockchain size would increase by 3.5625 TB daily
**A bitcoin address is 20 bytes (160 bits), and you can currently have anywhere from 1 satoshi to 21,000,000BTC, which can be represented without loss as 7 bytes, so optimally you can store the current balance of one address with 27 bytes per address, or the balance of all addresses with 27*numAddresses. Currently there are about 500,000 addresses, which would yield a minimum pruned block size of 13.5MB. Carrying this forward, if everyone in the world had bitcoin addresses that would be 7.125 billion * 27 bytes = 192.375 GB. That may seem large, but to put things into perspective, if everyone averaged 1 transaction/day the blockchain would grow by over 18 times that amount daily (3.5625 TB*).
***These requirements are included for performance reasons to make it less expensive when adding new transactions to the pruning block. Following these requirements gives you the ability to add a transaction without needing to include or recalculate the full balance information of the world to calculate your new block hash.
