Permanently keeping the 1MB (anti-spam) restriction is a great idea, if you are a bank. Those favoring a permanent 1MB cap, whilst asserting that Bitcoin can still be a financial backbone of sorts, don't know how right they are. The problem isn't a limit in general but that 1MB provides so little transaction capacity that, under any meaningful adoption scenario, it will push all individual users off the blockchain to rely on trusted third parties. 1MB is insufficient for end to end direct user access, but it is sufficient for a robust inter-‘bank’ settlement network.
If the cap is not raised to some higher limit; allowing a larger number of users to maintain direct access, then individuals will be priced out of the blockchain. When that happens Bitcoin becomes yet another network with no direct (peer) access; like FedWire, SWIFT, and other private closed transfer networks. There is no realistic scenario where a network capped permanently at 1MB can have meaningful adoption whilst still maintaining direct access to the blockchain by individuals. To be clear, by ‘direct access’ I mean both parties transacting directly on-chain without relying on an intermediary or trusted third party.
Bitcoin ... A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
Satoshi Nakamoto -
Bitcoin WhitepaperFinding a balanceIf the transaction capacity of a peer to peer network is very low then the resource requirements of running a full node will also be low but the cost of a transactions will be high. A network that keeps computing requirements low but which has priced direct access to that network out of the hands of individuals doesn't help decentralization. Likewise if the transaction capacity of the network is very high then the cost of transactions will be low but the resource requirements for running a full node will be high. A network that has sufficient transaction capacity for every possible transaction but which requires resources that put operation of a full node beyond the capabilities of individuals also doesn't help decentralization.
There is no "perfect" transaction rate. It is a compromise between two different centralization risks. Lowering the risk of transaction centralization raises the risk of node centralization and the reverse is also true. A robust network means minimizing overall risk not minimizing one risk at the expense of the other. This means that neither extreme is optimal. What level of transaction capacity (in terms of block size) provides the optimum balance will be saved for future discussions. Having a discussion on
how to change the network first requires an acceptance that the network
needs to change. So lets start with why the network must change.
Can we stop talking about a cup of coffee please?If you have been following the discussion you may have heard a claim such as "
Every $5 coffee doesn't need to be on the blockchain so there is no need to raise the limit". The implied meaning is that while the cost of permanently keeping the limit will exclude 'trivial' transactions you will still have direct access to the blockchain for everything else. This is misleading as the 1MB restriction is so restrictive that larger more meaningful transactions will eventually become uneconomical as well.
I don't really care if my morning coffee is paid for using a centralized service. Centralization and trusted third parties aren't always bad.
. Context matters so try to read the rest before freaking out. Have you ever given or received a gift card? Can't get more centralized than that. If I put $100 in Bitcoins under the control of a third party say in a ewallet or bitcoin debit card service, the risk and scope of that centralization are limited and manageable. As long as direct access to the network remains economical I can securely store and transfer my wealth using on-chain transactions and use centralized solutions where the risk is low such as day to day purchases. On the other hand if the imbalance between transaction demand and capacity makes individual transactions uneconomical I will lose direct access all together and that risk is more severe and the consequences more significant.
Sidechains, payment channels, and cross-chain atomic transactions are decentralized system that can move some of the transaction volume off the primary chain. In essence like centralized solutions they can act as a multiplier allowing a higher number of total transactions than the number of direct on-chain transactions. It is important to realize they still rely on the primary chain having sufficient transaction capacity or they aren't trustless. As an example a payment channel could allow hundreds or even thousands of off chain transactions but it requires periodic on-chain transactions to create, adjust, and takedown. If the individual user loses direct access to the primary chain they also lose trust free solutions like payment channels. If direct access becomes prohibitively expensive then only alternative which provides sufficient scale is using trusted third parties.
When demand significantly exceeds capacity it increases the utility and value of centralized solutions
If the transaction demand exceeds capacity by a magnitude or more it will lead to direct users being replaced by trusted third parties acting as aggregators. There are a lot of disadvantages to centralized services but they are more efficient and if the artificial limit is kept it will play right into the advantages of centralized services. A third party can facilitate instant off-chain transactions. If demand outstrips the very limited capacity it will force transactions off-chain using trusted third parties which I will call processors.
Today these processors would include online wallet providers, exchanges, merchant payment service providers, and services where the user maintains a balance under the control of the merchant (casino, poker room). In time even traditional financial companies and banks could be processors. The one thing they all have in common is that customers of these services do not have direct control over private keys and do not directly make transactions on the network. The processor has control over the private keys, keeps the Bitcoins in reserve and maintains an internal ledger of user transactions and balances. Processors can trivially facilitate transactions between two customers of their service. Since they control the private keys they simply update the ledger balances of the two customers and many of them do this today.
However transactions can still occur off-chain even if they involve customers of different processors. The process is not trustless but risk can be managed. Two processors would aggregate all the transactions which occur between their customers and then periodically settle the difference. When a payment from a customer of one processor is made to a customer of another processor the sending processor will notify the receiving processor. Both processors will update their internal ledgers. Over time this will result in an accumulated balanced owed by one processor to the other which can be settled with a single on-chain transaction. The key thing is that there is a one to many relationship between the settlement transactions and underlying customer transactions. While the 1MB block limit does not provide sufficient capacity for a large number of direct user transactions, third party processors can facilitate a very large number of off-chain transactions using a smaller number of on-chain settlements. Blocks of a finite size can support a nearly unlimited amount of off-chain transaction capacity with the limitation that it involves the use of trusted third parties.
You can't competing with a 'bank'
You might be considering the point above but dismissing it because you still 'could' submit a transaction to the network. The processors described above don't have the ability to close the network but a network that you have technical access to but which is uneconomical is effectively no access at all. The current block size realistically limits capacity to no more than two to four transactions per second. Two transactions per second is roughly 64 million transactions per year. A finite number of transactions can't support an infinite number of direct users. Say at some point there are ten million users and they wish to make two transactions per month. That is 240 million transactions but only 64 million will fit in the blocks. What happens to the excess. If third party processors are attractive the difference will be handled by them. When you consider a settlement network would allows these third party processors to offer instant, 'no risk' transactions at significantly lower fees than on chain transactions the excess demand will be processed off-chain. If the network continues to grow the profitability of these companies will grow and that will lead to more third party companies. Those settlement transactions allow more off-chain transactions but at the same time compete with direct user transactions for the limited on-chain capacity. In a settlement network the upper limit on the number of settlements required grows exponentially with the number of trusted peers. Just two hundred trusted peers (crypto banks) performing hourly settlements would fill the blocks, all the blocks perpetually. There may be billions of 'Bitcoin' transactions but they would be nothing more than updates on centralized ledgers. The blockchain would just handle the settlement between massive financial service providers. As these entities are collecting fees, and on chain transactions are a necessity of doing business, they can and will pay far more than you to ensure timely inclusion in a block. When you as an individual have been reduced to a position where you must outbid a 'bank' for space in the blockchain then you have effectively lost access to the blockchain.
Wait I don't get how off blockchain transactions could occur across entities
Imagine two large financial service providers where thousands of customers make payments to customers of the other entity. These may not be banks in the traditional sense, they can be any entity which acts as a third party to manage the bitcoins and transactions of customer. Today it could be major exchanges, payment processors, and ewallet providers but tomorrow it could include traditional financial service companies or even banks. For this example lets call the two entities Chase and HSBC. Chase and HSBC can notify each other when one of their customers makes a payment to a customer of the other entity. Both would update their internal ledgers and the payments would appear to occur instantly. Most importantly none of them would require an on-chain transaction. It is just updating numbers in a ledger. If you are a Coinbase customer and pay another coinbase customer this happens today. We are only taking it a step further and handling cross entity transactions. Now the entities have no real cost to perform these payments. They are just sharing a few bytes of information with their counterparty and updating numbers in a database. However over time, the net amount of the thousands of transactions will result in one entity accumulating a balanced owed to the other. This is why settlement networks require some level of trust. It requires trusted peers to extend mutual lines of credit to each other. The more they trust each other, the larger the lines of credit and the less frequently they need to settle. It is also why you will never be a peer on this network. The entities would enter into a legally binding agreements which set up the conditions of the settlement. The amount of funds the entities are risking is limited. The entities will limit the amount of credit they will extend and the terms are usually very short. These aren't long term loans, in the traditional banking world settlement might occur the next business day. The efficiency of the blockchain allows for lower capital requirements and lower risk by settling more frequently maybe even hourly.
Imagine that in a particular hour HSBC customers make thousands of payments to Chase customers totalling 10,000 BTC and Chase customers make thousands of payments to HSBC customers totalling 3,000 BTC. In total transaction volume is worth 13,000 BTC. As these payments occur Chase and HSBC notify the other party. This allows both to update their ledgers. A customer making a payment would see their balance be reduced 'instantly' and the customer receiving a payment would see their balance increase 'instantly'. The net flows however are not balanced. Chase has increased their customer balances 10,000 BTC and only reduced their customer balances 3,000 BTC. On the books both entities have a liability called 'Customer Deposits'. They keep reserves (hopefully >=100% to cover those liabilities). However Chase has seen its liability increase by 7,000 BTC and HSBC has seen its liability decrease by the same amount. To reconcile this HSBC will make a single on-chain transaction to Chase for 7,000 BTC. This will increase Chase's reserves by 7,000 BTC and decrease HSBC's reserves by 7,000 BTC. Everything is balanced again. Yes it did require a limited amount of trust between settlement peers and a single on-chain transaction but it facilitated thousands of off chain transactions. As soon as the next cross entity transaction happens a balance is owed by one entity and the net amount owed will increase and decrease until the next settlement which balances the books again and the cycle perpetually continues.
Now when demand for transactions exceeds what is possible who do you think can pay more in fees? You or a bank? If transaction demand exceeds capacity then some transactions will not make it into a block. Those paying the highest fee will be the ones who retain access to the blockchain and those unable or unwilling to will be excluded. It is delusional to think it will be the 'banks' that suffer in a situation like that.
The reported 7tps transaction capacity does not exist.
There is a myth that without raising the limit the network could handle 7tps. It can't. The limit is 1MB per block the actual transaction capacity depends on the average transaction size and realistically that provides no more than 2 to 4 tps. To achieve 7 tps using one block of 1 MB every 600 seconds means that the average transaction size must be 240 bytes (1,000,000 bytes / 600 seconds / 7tps = 240 bytes). If you have a Bitcoin wallet handy take a look at your last dozen transactions and if you don't have a wallet handy use a website to lookup the transactions in the most recent block. How many of the transactions were under 240 bytes? Not very many. I am going to say the majority of your transactions were probably between 300 and 700 bytes.
Can you form a 240 byte transaction? Sure as long as you only have only a single input. A transaction input is requires at least 147 bytes so an average of 240 bytes per transaction is not possible unless the average number of inputs is less than 2. While some transactions may have one input on average they are going to have more. The total number of inputs in the blockchain will roughly equal the the total number of outputs. As the number of blocks approaches infinity the ratio of inputs to outputs in a well functioning blockchain will approach 1:1.
Since most outputs will eventually become inputs it makes more sense to look at block capacity using a balanced transactions as a template for transaction size. A balanced transaction is one where the number of inputs equals the number of outputs. Single input, single output exceptions are both rare and have limited use. A 2 input, 2 output transaction using all compressed keys and P2PKH scripts is typical and weighs in at 373 bytes. At 373 bytes per transaction and 1MB per block the network will not exceed 4.4 tps.. This is already 37% less than claimed but it is still unrealistic as it represents the smallest possible balanced transaction.
Most transactions are going to be larger than 373 bytes due to the use of uncompressed keys being used, more complex scripts, and more inputs and outputs per transaction. Looking at the last million transactions in the blockchain I found the average txn size was 560 bytes. At 560 bytes per transaction and 1MB per block the network will not exceed 3.0 tps. So we have already lost over half of this claimed capacity but this is very likely to decrease over time as transaction sizes creep higher. Multisig and other more complex scripts are being used more frequently and that trend will continue. A good estimate for the network throughput when limited to 1MB blocks would be 2 to 4 tps depending on how optimistic you want to be.
Here is a direct comparison of the combined script size for some different types of scripts. The scriptPubKey is encoded in a transaction output and the scriptSig is encoded in the transaction that "spends" that output. Since outputs eventually become inputs in new transactions the combined size of the scriptPubKey and scriptSig represents the "roundtrip" script cost of a transaction.
P2PkH: 131 bytes per script round trip (25 byte scriptPubKey + 106 byte scriptSig)
2-of-3 P2SH: 253 bytes per script round trip (22 byte scriptPubKey + 231 byte scriptSig)
3-of-5 P2SH: 383 bytes per script round trip (22 byte scriptPubKey + 361 byte scriptSig)
15-of-15 P2SH: 1,481 bytes per script round trip (22 byte scriptPubKey + 1,459 byte scriptSig)
How many transactions are possible per megabyte of block capacity? Below is a the maximum capacity of the network at various average transaction sizes. Realistically 2 to 4 tps is all that is supported by a 1MB block and the lower end of that range is a far more likely.
Txn Size Upper Bound Example
373 4.4 tps (2in, 2out, P2PkH)
416 4.0 tps
520 3.3 tps Average of the last 1,000,000 transactions
555 3.0 tps
616 2.7 tps (2in, 2out, 2-of-3 P2SH)
833 2.0 tps
This same metric also applies to larger blocks. Advocates of larger blocks will often overestimate the capacity of larger blocks. It is realistic to estimate getting 2 to 4 tps per MB of block space regardless of the block size. If all blocks were 20MB that would provide a realistic throughput of 40 to 80 tps not 140 tps. Still 40 to 80 tps would be sufficient for 100 million users to make one or two transactions per month.
1MB can not support a sufficient number of direct users even if transaction frequency is very low
One argument made by those favoring the cap is that Bitcoin doesn't need to be used as a transactional currency to be successful. Users could primarily acquire Bitcoins as a way to secure store of value (savings) and continue to use other currencies for routine purchases. Bullion and other stores of value have a much lower velocity than transactional currencies. This means a block of the same size could support more more users. While the user of a non-transaction currency may not make dozens of transactions a day, meaningful access would at least require access on the order of dozens of transactions per year. If your savings or brokerage account restricted you to only one deposit per quarter and one withdrawal per year I don't think you would find that acceptable. Future users of Bitcoin will not find it any more acceptable if they are forced to transaction as infrequently.
Maximum supported users based on transaction frequency.
Assumptions: 1MB block, 821 bytes per txn
Throughput: 2.03 tps, 64,000,000 transactions annually
Total # Transactions per Transaction
direct users user annually Frequency
<8,000 8760 Once an hour
178,000 365 Once a day
500,000 128 A few (2.4) times a week
1,200,000 52 Once a week
2,600,000 24 Twice a month
5,300,000 12 Once a month
16,000,000 4 Once a quarter
64,000,000 1 Once a year
200,000,000 0.3 Less than once every few years
1,000,000,000 0.06 Less than once a decade
As you can see even with an average transaction frequency of just once a week or once a month the network can't support more than a token number of users. When someone advocates a permanent cap of 1MB what they are saying is I think Bitcoin will be great if it is never used by more than a couple million users making less than one transaction per month. Such a system will never flourish as a store of value as it is eclipsed by alternatives which are more inclusive. To support even 100 million direct users making an average of one transaction every two weeks would require a throughput of 82 tps and an average block size of 20 to 40 Megabytes.
1MB doesn't can't even keep up with existing non-retail payment networks.
Going back to that coffee meme, the implied message is that 1MB is fine unless for everything else. You know substantial stuff like paying your mortgage, business deals, major capital expenditures, or paying a supplier for inventory. This just isn't the case though. Do you know anyone who pays for coffee with a bank wire? The FedWire service (run by US federal reserve) processes ~150 million bank wires annually. The FedWire service only operates in the US. Internationally the largest clearinghouse is SWIFT and it processes more than 5 billion transfers annually. The US ACH network is even larger with 19 billion transactions annually (excluding converted checks). There are also about 2 billion international remittances annually (western union, moneygram, and other networks). A 1MB restricted Bitcoin network couldn't even keep up with these transfer networks even if you forget about retail sales completely. The idea keeping the 1MB restriction, only keeps limits the utility of small payments is simply incorrect.
Bitcoin block size to reach comparable network volume based on average txn size
Network txn volume Average transaction size
annually (mil) 373 bytes 560 bytes 833 bytes
FedWire 150 1.1 MB 1.7 MB 2.3 MB
Remittance 2,000 14.2 MB 21.3 MB 31.7 MB
SWIFT 5,000 35.5 MB 53.3 MB 79.3 MB
ACH 19,000 134.8 MB 202.4 MB 301.0 MB
On a transaction fee basis.
Currently the cost of the network is roughly $300 million annually. The users of the network are collectively purchasing $300 mil worth of security each year. If users paid $400 million the network would be more secure and if they paid $200 million it would be less secure. Today the majority of this cost is paid indirectly (or subsidized) through the creation of new coins but it is important to keep in mind the total unsubsidized security cost. At 2 tps the network the unsubsidized cost per transaction would be about $5. At 100 tps it would be $0.05. If Bitcoin was widely adopted, more users purchasing more coins should mean a higher exchange rate and thus the value of potential attacks also rises. The future cost of the network will need to rise to ensure that attacks are not economical and non-economic attacks are prohibitively expense relative to the benefit for the attacker. It may not rise linearly but it will need to rise. If someday one Bitcoin is worth $10,000 and we are still only spending $300 million a year on security we probably are going to have a problem. Now advocates of keeping the limit may argue that the majority of the network cost won't be paid by fees for many years but the reality is that with a low maximum transaction rate you can choose either much higher fees or much lower security.
Conclusion
Restricting the size of blocks to 1MB permanently is great if you are a major financial services company. You could co-opt a very robust network, act as a trusted intermediary and force direct users off the chain onto centralized services. For the same reasons, it is a horrible idea if you even want to keep open the possibility that individuals will be able to participate in that network without using a trusted third party as an intermediary.
On edit: fixed some typos. Cleaned up some poorly worded statements. Yeah there are a lot more. It is a work in progress. 
