by Albert Szmigielski
Currently Bitcoin blocks are limited to 1 MB. This limit implies a certain number of transactions per time frame. Bitcoin blocks are found on average every 10 minutes, therefore on average we can expect 7 transactions per second. In order to compete with established companies, Bitcoin must scale up and therefore increase the blocksize to allow more transactions per time frame. Increasing the blocksize would require a hard fork. Anytime major changes are required to the Bitcoin protocol different interest groups raise their concerns and lobby for their interest.
There were four proposals for increasing the blocksize put forward. They can be found in BIPs 100 through 103, and BIPs 105, 106, the unofficial 248, and the “no-change” BIP 000. Perhaps the most popular one is BIP 101, known as BitcoinXT. BIP 100 has Jeff Garzik as its champion, the proposal suggests removing the 1MB limit and lets miners vote on a new limit that is greater than the current 1MB, but less than 32MB. It also allows for further increase (or decrease) by a maximum of 1.2 times every 12000 blocks (2 weeks), this is accomplished by miners voting on the next block size. BIP 101 is championed by Gavin Andresen and it proposes to increase the blocksize limit to 8MB, and then double it every two years. BIP 102 is another proposal by Jeff Garzik, it suggests to increase the blocksize to 2MB and then increase it by 20 bytes in every block. BIP 103 was put forth by Pieter Wullie and it proposes to increase the blocksize by 4.4% every 97 days (17.7% annually), starting in January 2017. BIP 105 proposes a mechanism whereby miners vote the blocksize up or down by a maximum of 10% per difficulty period. BIP 106 is also a dynamic size proposal, which aims to either double or halve the block size per difficulty period depending on whether the first 2000 blocks of the previous difficulty period have been either almost full or less than half empty. There is also another variant in 106, but it has been mostly ignored as the formula to calculate the new blocksize is too complex. BIP 248 has been proposed by Adam Beck, it is simple and it proposes an increase to 2MB now, 4MB in 2 years, and 8 MB in 4 years. BIP 000 is to keep the status quo, 1MB limit.
BIP 100 attempts to let miners decide the blocksize. This puts the blocksize control solely in the miners hands, other members of the community have no way of voting on the blocksize. It also allows pools to make decisions that its members may not support. The consensus in the community has been that this proposal gives too much power to the miners. In my opinion this proposal does favor miners too much, furthermore the blocksize increase or decrease is not predictable in the long term. As a result I do not support this BIP.
BIP 101 also know as BitcoinXT is straight forward and predictable. This is the reason I like the proposal. One thing that is perhaps unnecessary is the big immediate jump to 8MB. I would like the increase to be to 2MB and then double every two years. Overall the community agrees that 8MB seems a little bit too large. BitcoinXT also postpones the “fee market” as large block sizes will not force users to pay significant transaction fees. This is a good feature in my opinion. I would like to see a big user growth before requiring meaningful fees. If fees were to be raised too much as a result of too small blocks, Bitcoin may fail to attract much needed new users. Overall I would support this proposal if the initial increase of the blocksize was changed to 2MB.
BIP 102 has been dubbed “the backup plan”, it is a short term solution that simply postpones the blocksize discussion into the future. In my opinion a long term solution would be much more preferable. BIP 102 only buys us around a year or two before we have to have the blocksize discussion again. Principally I do not support this BIP, however if the community fails to reach consensus on all other proposals, I do think that this BIP will be necessary.
BIP103 is predictable, which is a positive. The biggest drawback of this BIP is that the increase is a bit too small. The community feedback has been thin. The most commonly raised issue is that the proposal does not address free market economics. Overall I think this proposal is adequate, but I do agree that the increase is too small. Furthermore the start day is a bit too far into the future. Bitcoin is already hitting the 1MB limit now. I do not support this proposal as it stands now.
BIP 105 allows for dynamic blocksize, but just as with BIP 100 the decision process favours miners. The community has not given a lot of feedback on this BIP. In my opinion this BIP ignores all the other stakeholders in the Bitcoin community and gives miners all the decision making power. As a result I do not support this BIP. I think taking into account other actors in the system would improve this proposal.
BIP 106 dynamically sets the blocksize which is a desirable feature. The community has given little feedback on this proposal. I do like this proposal as it varies the blocksize depending on the number of transaction in previous blocks. However miners can game this proposal by including either lots of transactions or less than half of the 1MB thereby controlling the blocksize and perhaps putting pressure on fees. This ‘hole’ in the proposal is the reason I ultimately do not support it.
BIP 248 is very predictable and simple, and therefore I do like it and would support it. However it will require the debate to reopen in 4 years. 8MB is only 56 transactions per second which is not a lot for a worldwide payment system.
BIP 000 which proposes to do nothing is not an acceptable form of action.
The various BIPs all argue for a blocksize increase, some want to make it dynamic, while others want to make it static and predictable. There is no silver bullet here, no proposal is perfect. The only thing that the community agrees on in large part is that an increase is necessary in order for Bitcoin to scale. I would like to see a proposal where other groups besides miners have the power to change the future blocksize. My desired proposal would be doubling the blocksize based on the number of transactions in blocks (similar to BIP106) but also taking into account the transactions in the mempool.