this is perhaps more of an economics question than a bitcoin question, but i'm wondering if it would be viable to leave the block size capped at 1MB for all time and simply let a series of rules govern which transactions get included into a mined block, eg:

  • paying a higher fee gives higher priority
  • older coins get higher priority
  • bigger spend gets higher priority
  • etc

this would incentivize people to rely more on off-chain transactions (eg gyft cards), or sidechains, to accumulate many payments into a single transaction, and perhaps to delay transactions if they do not wish to pay high fees. and one benefit would be that the blockchain would not grow beyond a size which would fit on a single user's hard disk. this would keep bitcoin decentralized without any need for a hardfork.

are there any fatal flaws to this notion?

The blocksize topic correlates directly with the current 7 transaction per second (TPS) ceiling Bitcoin has that was recently brought to light before US Congressional Testimony. describes the 7 TPS ceilings under "Current bottlenecks". Ignore block framing data fields, the 7 TPS limit implies that ~4200 transaction (10*60*7) with each being ~238 bytes in size fitting nicely into the 1MB block brown bag. A careful examination of the top of blockchain-dot-info will indicate the real world is a little more complex, and the 7 TPS ceiling is extremely optimistic, most transactions will be significantly larger than 238 bytes size! My mining Payouts alone are ~4K in size.

The tweaking of the blocksize a very hot/political topic. Remember the March 12, 2013 Bitcoin forked Blockchain issue??? ( It is too early for me to tell what the trade space pros & cons [system's engineering truth concerning the trade space analysis of alternative (AoA) results for backward compatibility, scalability, security, sustained decentralization... measures of effectiveness (MOE) and measures of performance (MOP)] is for increasing the current 1MB block size in the Blockchain.

Ignoring state politics, in the end, the dynamics between stability of developer solutions, hardware engine solutions, miners and pools will ultimately determine the block size(s) supported in the future.


  • +1 Concerning your "censoring the sharing of truthful public information really sucks". I am not sure what you are referring to. New users can only use a limited number of external links in posts, somebody already suggested an edit to your answer in order to fix them. If you are referring to something else, please feel free to open a question in Bitcoin Meta. Altogether, it is more constructive to keep content (Q&A) and discussions about how bitcoin.SE works separate. – Murch Dec 8 '13 at 19:42

It's worth the time to read the December 2013 three page "Chicago Fed Letter" titled "Bitcoin: A primer" description that the Federal Reserve has about Bitcoin, see There is truth in the assertion that "There are on average about 30 bitcoin transactions per minute (Visa transactions average 200,000 per minute). The average bitcoin transaction size is about 16, i.e., on the order of $2,000 (the average Visa transaction is about $80)". See for the truth about Bitcoin transaction rates. This is at the heart why the Bitcoin block size is so contentious. For existential reasons, extreme care has to be exercised by the Bitcoin Community for picking a course of action. Strategies need to be established to not grow too quickly, and establishing symbiotic crypto currency allies to load balance the anticipated demand for crypto currency transactions while an optimal an optimal decentralized architecture is identified enabling Bitcoin to scale by at least three orders of magnitude while sustaining it decentralized characteristics. Making block sizes too large will leave mining operations in the hands of only a few, which puts us back into the same centralized banking paradigm. This is the big challenge! Some big decisions need to be made. Bitcoin Technology is in its propeller-driven bi-plane era, getting it into the space/jet-age will take considerable work and cooperation.

up vote 1 down vote accepted

According to Andreas Antonopolis:

Blockchains are never going to scale in the base layer, but Bitcoin can [scale] and its going to be a combination of both second and third layer scaling, as well as base layer scaling. We'll increase the block size again - already did - we'll do it again, if necessary - not to support bare transactions, but to support more second layer scale on the base layer, when necessary.

I think by "second layer technology" Andreas would include:

  • lightning networks
  • sidechains
  • other kinds of off-chain transactions
  • etc

And it should be noted that he has said before that he would not advocate any current implementation of bitcoin technologies at risk of getting burnt again.

simply let a series of rules govern which transactions get included into a mined block

The Bitcoin protocol has no way to enforce such rules. Miners have complete discretion as to which transactions they include in a block. Your first suggestion (higher fee gives higher priority) will happen naturally if miners are greedy, but there's no way to make them select blocks on any other basis, nor any clear way to incentivize them to include older or larger transactions.

If such rules were to be mandatory, at minimum there would have to be a hard fork to adopt them into the protocol, and even then it's not at all clear what the new protocol would look like. Suppose a miner omits a "high-priority" transaction in favor of one to which your rules give lower priority. If the rule is mandatory, then his block should therefore be invalid.

But remember that it has to be possible to validate the blockchain after the fact. If someone is downloading and verifying the blockchain months later, how will they have any way of knowing that this high-priority transaction was in the mempool at the time and therefore this block is not acceptable? This seems unworkable.

Bitcoin Core used to follow priority rules by default, with some block space reserved for transactions with high "bitcoin days destroyed" (older and larger), but this was strictly voluntary, and any miner could patch the code or use different software if they wanted to do something different. Their blocks would be accepted just the same either way. And in fact, as soon as transaction volume reached the point where it was more lucrative to include higher-fee transactions over those with higher BDD, miners began to do so in short order, and eventually Bitcoin Core gave up and removed its BDD rules in favor of a purely greedy algorithm.

  • "eg" means "for example". You could really put anything in the dot points in the original question - it doesn't have to be exactly what I wrote there. And likewise with the example of gyft. Also what you write here, is not true: "But remember that it has to be possible to validate the blockchain after the fact." segwit is one case where it is no longer possible to validate a block by purely relying on the bitcoin protocol (signatures are no longer stored on the blockchain with segwit). – mulllhausen Jan 25 at 6:19
  • Actually, I believe it fits the classical definition of a soft fork, since no previously invalid block would be declared valid. Enforcement would require only that previously valid blocks/transactions are made invalid, which is a soft fork. Soft Fork on | Softfork and Hardfork in Bitcoin terminology on bitcoin SE – Willtech Jan 25 at 8:42
  • @mulllhausen: There might be a semantic argument here. You could say segwit adds additional data to the blockchain. Alternatively, under segwit you can still validate the blockchain after the fact if you have some additional data which can itself be validated after the fact. But for any prioritization rules I can imagine, I can't think of any way that you could prove after the fact that they were obeyed, that doesn't create severe vulnerabilities or centralize the currency. Even allowing for a soft or hard fork. – Nate Eldredge Jan 25 at 14:33
  • @NateEldredge yes i think it is a semantic argument. you misunderstood my usage of the word "rules" in the question. i was not necessarily intending "rules" to mean "the bitcoin protocol". i was mainly thinking of economic rules, which is why i said, "this is perhaps more of an economics question than a bitcoin question" and went on to talk about incentives. – mulllhausen Jan 26 at 11:58
  • @mulllhausen: Okay. But it's not clear to me how you could give miners an incentive to prioritize in any way except highest fee. – Nate Eldredge Jan 26 at 13:44

Increasing the 1MB limit is already in the works. It will happen soon. Having users run into this limitation would ultimately hurt bitcoin. It wouldn't make sense to cripple bitcoin in one area in attempt to incentivise it in another. I think there are better ways to incentivise bitcoin gyft cards.

  • do you know what the new limit will be? and will it result in an unmanageably large blockchain? or are there other changes planned to compress/prune the blockchain being implemented simultaneously too? – mulllhausen Dec 6 '13 at 6:54
  • I don't think they have decided yet on the new limit. Bitcoin clients don't have to hold the entire blockchain. Right now most clients do, but I'm sure we'll see options to let users opt out. – Matt Dec 7 '13 at 7:50
  • Interesting looking back at this: "soon" was about four years, and even then it was increased modestly and in a roundabout manner (segwit). – Nate Eldredge Jan 25 at 4:25

I do not believe that blocks will remain capped at 1MB forever and BIP141 changes things slightly. For one thing, it doesn't make economic sense for blocks to remain so small as the block reward is reduced, as it erodes the utility value of bitcoin through ever higher fees as demand is increased. This is also reflected in the value of BTC.

I do not believe that block size should be unregulated or any larger than is necessary.

In simple terms, if each miner makes a block that is (current average valid network-wide mempool transaction count) x ( 1 / (144 x n days ) ) = number of transactions to be included in block then in n days all valid transactions will be confirmed and all fees collected. This could account for a far higher amount (and cash value!) of fees than current user frustration through limited supply and all its complications would eventually allow. At the moment this user frustration is called an auction model for limited bandwidth.

The first difficulty to resolve is, how to determine current average valid network-wide mempool transaction count since the mempool is not in consensus? And how many should be n days?

See also this answer:

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.