From a fundamental analysis perspective the attributes of cryptographically secured value tokens, mathematical consensus and censorship resistance are what gives Bitcoin its value. With a high degree of decentralization, these attributes become more meaningful and Bitcoin more valuable. In the face of centralization they become meaningless and Bitcoin loses its value, both perceived and real. Yet, no matter how valuable, if the network is not highly available or does not function reliably, the utility of Bitcoin diminishes and as usage decreases so does value. xbt.social presents an assessment of the objective conditions surrounding Bitcoin’s blocksize and how capacity scaling and its provision can affect Bitcoin’s valuation and price.
The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
– Satoshi Nakamoto
Block size is a sure and certain limitation on Bitcoin’s capacity that awaits us down the road. Currently, Bitcoin has adequate capacity to handle transactions reliably, but when block space starts running out transactions will get delayed and some may never be processed at all. Setting aside the extremes of the debate, namely the idea that the protocol should be super-capacitated to compete with Visa, or that block size should never be increased, a timely middle way is deemed preferable.
This report gives no preference to XT. In fact, there are some question marks over the project and its motives. Instead, the sound and correctly proposed Bitcoin Improvement Proposal (BIP) submitted by Gavin Andresen is recognized as having merit, and notably, it can be implemented in part, at least, by other node projects without the need to incorporate anything else from the XT fork project. Due process is what the market wants to see.
The existence of the block size way-point has been known since Bitcoin’s inception, and Satoshi Nakamoto addresses the topic in at least one forum post. Block size and block size change management is an important developer responsibility because it is not a once-off event but an ongoing process that will forever accompany Bitcoin in its cycles of growth and contraction. Block size is especially significant because of its impact on Bitcoin’s core attribute of decentralization. Threats to the quality of Bitcoin’s decentralization have a direct impact on the protocol’s perceived value and, therefore, its price.
Presently, block size is 1MB and at the current average peak of 130,000 transactions per day, the Bitcoin network is processing an average of less than 2 transactions per second (tps). The following chart shows the increase in the number of transactions during the past year:
The 1MB capacity of each of the 144 blocks mined every day is, conceivably, sufficient capacity for the next two years. However, once blocks start filling up, the consequence will be that users have to wait longer for transactions to confirm and, potentially, that some transactions may never make it into a block at all due to mempool limitations.
The next chart shows the average number of transactions being included in each block during the past year – its peak value falls just short of 1100 transactions per block with the mean value around 800:
According to the two charts, above, it is plain to see that the number of transactions being made on the network are increasing. An important metric the charts do not reflect is that the average size of individual transactions is also increasing as a result of the protocol’s utxo set expanding. The guestimate of a 2 year threshold to capacity is, therefore, too liberal and should, more realistically, be closer to mid- or end-2016 – provided there is not a ramp in transaction volume as a result of a flight to Bitcoin or a speculative rally.
Capacity planning and provision is not optional and developers have consensus on this point. The ongoing functionality and utility of the network should be serviced prior to capacity being reached or else risk users and speculators (investors and Bitcoin-based businesses are included in the latter category) losing confidence in the Bitcoin network’s availability and reliability.
So, why all the fuss about block size? Why had the debate among the developers taken so long and remained unresolved? Why not just agree to double or triple block size and ensure long-term capacity?
The short answer is that decisions about block size are complicated by considerations related to decentralization, and a variety of notions about the quality of that decentralization.
A larger block size needs more hard-disk storage and will require miners to host larger, more expensive hardware infrastructure. Double the block size and you effectively double the storage capacity needed.
Larger block size, therefore, biases mining to larger mining operators and those with the financial resources to afford the infrastructure. Of course, this has always been the case (and large mining installations certainly exist) but increase the block size too much and smaller single miners and pool operators are necessarily excluded from participating – they are forced out of the industry because of increased hardware and infrastructure costs imposed by a large block size. Consequently, the network stands to lose a diverse and populous layer of miners, and with fewer participants, the degree of decentralization is reduced while the risk of centralization increases.
Hence, a process of gradual block size increase that is paced to the mining industry landscape and that considers the effect on the quality of decentralization is critical. If block size is increased from x megabytes to y.x megabytes, what will be the effect on the number of miners who participate? Having as many miners as possible (perhaps every user) is desirable, but having a reliable network with adequate capacity is equally important. So there are complex trade-offs and this has been the point of contention in the multi-year debate around the complexities of increasing block size.
Bitcoin XT is a node implementation based on Bitcoin Core. There are many node implementations in existence, for example libbitcoin-server, btcd, etc. that connect to the Bitcoin network and become peers sharing the same block chain.
Bitcoin XT is, in essence the reference Bitcoin Core software that has been patched with code that includes (and I quote Mike Hearn) “a few protocol improvements” but does not change the fundamental functions or nature of Bitcoin. Anyone versed in C++ can verify the source code. As its development continues it will eventually (within a few weeks or months) include support for larger blocks – and the proposed block size of those blocks will be 8MB (current block size = 1MB).
In a draft Bitcoin Improvement Proposal (BIP), Gavin Andresen proposes a schedule of automatic protocol imposed block size increases, starting with 8MB on 11 January 2016 and doubling every 2 years until year 2036 when the final block size will be 8GB (gigabytes).
The blocksize increase activates, at fixed dates, if a super-majority of 75% of miners have opted for the new block size by indicating their preference in their submitted blocks. Without 75% miner consensus no block size increase activates.
What motive or agenda informs the XT fork or what may become of it down the line is uncertain and will not be speculated upon here. The objective condition is that a discussion around a block size increase date is now underway, and node developers, including Bitcoin Core developers have the option to update their protocols to accept or not accept the block size increase next year. The block size increase does not force miners, businesses or users to run XT.
Impact on Bitcoin price? For the rest of 2015 – Potentially Positive. Provided developers act on this cue and users become proactive and support those miners that represent their vote for blocksize. Some marketplace confusion and misinformation may cause temporary insecurity and see a price chart decline during the coming months until confidence is restored. Bitcoin’s fundamental attributes do not change in any way and the capacity planning and testing is in line with Bitcoin developer responsibilities and Satoshi Nakamoto’s design.
At the time that the block size increase is scheduled to be algorithmically activated there may be some surprises. Rejection of the larger block size, by consensus, will bring us right back to square one and with a capacity crisis looming. Market decline would ensue. In the event of a majority consensus in favor of the larger blocksize, a hardfork will be activated by the protocol and then we face the possibility of exceptions or errors caused by the forking process. None are specifically anticipated. In 2013 a hardfork happened, unintentionally, and was adequately handled and recovered from, as outlined in the linked document. Core developers are requesting tests of the new block size in action, and Gavin Andresen should reasonably acquiesce. The results and conditions of those tests should be informative when published. Jeff Garzik’s BIP 100 remains on the table and now seems attractive for its thoughtfulness and proposed protections.
Negative mood and a negative impact on price, either as a result of the XT fork or because of confusion surrounding the block size increase debate now coming to a head, may express itself in the price chart but is not expected to prevail beyond the next two or three months. Failure to act and to restore confidence in the market will increase insecurity, negative sentiment and short selling. The pessimistic mainstream media will have a field day and reinforce negative sentiment. Planning and provision of capacity is prudent at this time. There are pressing matters in the global economy, such as credit instability, liquidity concerns and Eurozone fracture that may soon see a flight to Bitcoin. The Core developers should choose between the two self-evident options and implement a scheduled block size increase to 2MB or slightly more and prepare for it to be utilized.
The writer trades Bitcoin. Trade and Investment is risky and subject to probability and market changes. CCN.LA accepts no liability for losses incurred as a result of anything written in this report. Images from Shutterstock and Blockchain.info.
Last modified (UTC): July 12, 2015 07:54