This article was originally published as a pdf on November 9th, 2017, and we wanted to bring it to the attention of our readers, investors, and all other cryptophites! ...
Bitcoin Is Dead! Long Live Bitcoin!
• It appears that the contentious SegWit2x hard fork scheduled for November 16th is now off. Leaders of the SegWit2x implementation and signers of the New York Agreement (NYA) backed down from the proposed implementation.
• This avoids a dangerous network split, which would have likely caused long and erratic block creation times, high transaction fees, and slow transaction confirmation times.
• The current network still has the original SegWit implementation, activated this past August, which has increased transaction throughput.
• Our calculations show that SegWit can scale the network to a theoretical maximum of 20.3 tps, but a more realistic maximum throughput is 11.7 tps.
• Vertical scaling solutions, such as SegWit and even the failed SegWit2x, still leave Bitcoin orders of magnitude behind the scale of centralized networks such as PayPal and Visa.
• Horizontal scaling solutions, such as the proposed Lightning Network, will need to be created if centralized networks are to be threatened.
On November 16, Bitcoin was scheduled to be forked into two separate blockchains, creating two different cryptocurrencies, BTC and B2X. This split stems from a long-standing disagreement between key stakeholders, such as developers, miners, and client software providers, with regards to how to scale the Bitcoin Network to increase the number of transactions it could handle. The proposed fork is now officially dead, according to prominent supporters of the project. We think this resolution is healthy for the ecosystem overall as it avoids potentially erratic block creation times, high transaction fees, and slow and unpredictable transaction confirmation times.
While we may not have 2MB blocks from SegWit2x, we still have the original SegWit, which continues to be adopted across the network. Because SegWit was activated through a soft fork, it is backwards compatible, and both legacy transactions and SegWit transactions can exist within the same block. SegWit has not been fully embraced by the community and its supporters still represent a minority. Bitcoin therefore has additional headroom to grow transaction throughput as measured by transactions per second (tps). Even if SegWit becomes fully adopted, the Bitcoin Network will still be orders of magnitude behind the transaction throughput of centralized systems, but it is a step in the right direction until horizontal scaling solutions, such as the Lightning Network are adopted.
As Bitcoin gained traction over the years, the network could not handle the number of transactions demanded by users, resulting in lengthy delays that could only be bypassed by paying higher fees. This became evident beginning in 2015 and led to the Block Size Debate, an ongoing discussion about the trade-offs related to increasing Bitcoin’s block size for more transactions to be allocated in each block. Since mining Bitcoin is capital-intensive, miners want to maximize the number of transactions on a per block basis to increase the amount of transaction fees. The easiest way to achieve this is by increasing Bitcoin’s block size, which had been 1MB since Bitcoin’s inception. Although the core development team understood the need for faster transactions, it feared that merely increasing block size would affect the underlying safety of the protocol. Another recurring argument against the block size increase was the possibility of further mining centralization, which was already a concern of the community, whose general philosophy revolves around decentralization.
Bitcoin Core developers preferred a different solution that increased transaction speed without increasing block size. This came to be known as SegWit or Segregated Witness — a change in Bitcoin’s code that optimizes block size by removing unnecessary information from each block, leaving more space for transaction data and ultimately reducing confirmation times. The update was welcomed by most of the community, but several prominent figures of the Bitcoin mining industry characterized SegWit as being an inefficient solution.
In February 2016, a group of miners and developers met in Hong Kong and reached a compromise where both SegWit and a block increase to 2MB would be implemented. This became known as the Hong Kong Agreement. However, the developers present in Hong Kong did not represent the entire core development team. In response, the core developers released on October 27, 2016, a new version of Bitcoin Core that contained SegWit, which would only be adopted if 95% of miners signaled that they would adopt it, but was not compatible with 2MB blocks. By May 2017, less than 30% of miners signaled their intention to adopt SegWit as many of them felt betrayed following the Hong Kong Agreement.
In May, Consensus, a major blockchain conference held in New York, was held by CoinDesk, a subsidiary of the Digital Currency Group. Until now, Bitcoin-related businesses had largely stayed out of the Block Size Debate, hoping that the miners and core developers could reach some resolution as they cared most that any safe scaling solution was implemented. It was clear that consensus was unlikely to be reached, but at Consensus, the Digital Currency Group brokered a deal where 58 Bitcoin-related companies and 83% of the hashing power of the Bitcoin Network supported the activation of SegWit at an 80% threshold and a 2MB block increase with a hard fork within six months. This became known as the New York Agreement. Although core developers were invited to this meeting, none attended, and the core developers decried the New York Agreement as “back room deal-making.” This led to Bitcoin Improvement Proposal 148 (BIP 148), which proposed a user activated soft fork (UASF) whereby any nodes running BIP 148 would reject any Bitcoin blocks that did not signal support for SegWit. The core developers implemented this mechanism in case a large percentage of Bitcoin miners refused to adopt SegWit and started mining on a new chain, thereby mitigating potential transaction delays.
Recognizing that the core developers did not support the New York Agreement and that between the activation of SegWit and the block size increase the core developers had their preferred SegWit solution that the miners would not otherwise allow, many in the Bitcoin Community Copyright© 2017 – DIGITAL ASSET RESEARCH 4 refused to support BIP 148 or the New York Agreement from the outset. In April, mining hardware manufacturer Bitmain was the first to suggest a hard fork and the idea for Bitcoin Cash began getting support. In the following month, the Bitcoin ABC Project (Adjustable Block Cap) announced it was developing a full node implementation of the Bitcoin protocol that is compatible with Bitcoin Cash. The project’s goal was to support a version of Bitcoin that rejected SegWit and increased the block limit to 8MB. The fork happened on August 1, and the first Bitcoin Cash block was mined 6 hours after Bitcoin Block 478558 by ViaBCT, a Chinese digital token exchange and mining pool.
Following the Bitcoin Cash hard fork, the concerns about the delay between the activation of SegWit and the block size increase came to fruition. People on both sides of the debate were maliciously attacked online and some signatories to the New York Agreement who supported SegWit but not the block size increase withdrew their support of the agreement. Although SegWit2x was scheduled to be activated at Bitcoin Block 494784 on November 16, on November 8, it was announced that the project had been suspended. In an email from Mike Belshe (CEO of BitGo), he, on behalf of Wences Casares (Xapo), Jihan Wu (Bitmain), Jeff Garzik (Bloq), Peter Smith (Blockchain.com) and Erik Voorhees (Shapeshift.io) announced that “we have not built sufficient consensus for a clean block size upgrade at this time. Continuing the current path could divide the community and be a setback to Bitcoin’s growth. This was never the goal of SegWit2x.”
Scaling Crypto Scaling open, decentralized networks such as Bitcoin is probably the first, second, and third most talked about issue in the industry. The heart of the discussion centers on how to increase transaction throughput from a pedestrian 4 tps for Bitcoin, to the levels of permissioned, centralized networks such as PayPal and Visa. This is an issue for other cryptocurrencies, like Ethereum, which although confirms transactions more quickly than Bitcoin (1.5 minutes vs 60 Copyright© 2017 – DIGITAL ASSET RESEARCH 5 minutes), still tops out at a theoretical maximum of ~23 tps. For comparison, PayPal handles nearly 200 tps and Visa regularly handles nearly 2,000 tps.
The heart of the debate for decentralized networks is the scalability trilemma, the balancing of the three vectors of a network: decentralization, security, and throughput. Said simply, a push in one direction of these vectors sacrifices one or more of the other vectors. For example, it is simple to have a high throughput system if you sacrifice decentralization. Most existing or implemented solutions for scaling blockchains have been vertical solutions, meaning that they aim to increase the number of transactions in each block. This is true of the initial implementation of SegWit, which made more room in each block for transactions by optimizing how data is stored. There are other, upcoming solutions that are classified as horizontal scaling solutions, such as state channels and blockchain sharding. State channels is a technology that involves opening direct off-chain payment paths between one or more parties. These promise instant transaction verifications and tps that can reach the millions. The Bitcoin and Litecoin Lightning Networks, as well at the Raiden Network on Ethereum, are examples of state channels. We will get a glimpse of Raiden’s potential when µRaiden launches on Ethereum’s main network, expected by the end of November. Database sharding is still a relatively new concept, but involves transaction verification by only a portion of the network, but still retains the security and transaction verifiability of full node validation. Ethereum’s Plasma proposal is an example of this technology. Developer Joseph Poon is a driving force behind Bitcoin’s Lightning Network, Ethereum’s Plasma proposal, and the ERC-20 token OmiseGO.
The implementation of SegWit was a step in the right direction for improving Bitcoin transaction scalability. Prior to the initial implementation of SegWit, the block size of Bitcoin had a hard cap of 1MB. After the implementation of SegWit, the notion of a 1MB fixed memory size was replaced by something called block weight. Block weight is a different accounting metric for block size where 1 byte of transaction data is counted as 4 bytes of block weight and the SegWit data (i.e. the scriptSig) is only counted as 1 byte of block weight. New blocks, which can have a mixture of both SegWit and non-SegWit transactions, have a maximum block weight of 4MB.
The Arguments Against Block Size Increases
Users that run full node Bitcoin clients are required to store a full copy of the blockchain and incur the storage costs of running the software. The current directory size of the Bitcoin blockchain is 160GB, which enables most personal computers to run the software. However, if blocks double in size, Bitcoin’s directory size will grow at a proportional rate, increasing users’ storage costs. Consequently, less users will be able to run full nodes thereby potentially increasing miner centralization, contradicting Bitcoin’s ethos of decentralization. Proponents of a block size increase often cite Moore’s Law to explain how users will be able to afford a larger directory size, but considering the growth rate seen in the 1MB legacy chain, there is an argument that a 2MB chain will outpace future reductions in storage costs.
While an increase in block size may temporarily relieve network transaction congestion, it is not a long-term solution and blocks will eventually fill in the future, assuming Bitcoin continues to grow and be adopted. There is also an argument that negative externalities resulting from a block size increase would disadvantage the network over the long term, as bigger blocks increase storage costs and make it costlier to operate full nodes. Larger blocks also require significant amounts of hashing power to be completed, which has also been a factor impacting centralization. Other negative externalities include an increase in the frequency of orphan blocks due to the broadcast latency of larger blocks.
Given these concerns, in 2015, Bitcoin’s core development team began researching scalability solutions that did not involve a block size increase. Since the assumption was that there will always be a constituency that denies changes that involve hard forking the protocol, research on these solutions focused on backwards compatible upgrades, or soft forks. Soft forks give users the option, but not the obligation, to adopt the proposed improvements and do not split the network when consensus cannot be reached. Many improvements can be implemented through soft forks. The Segregated Witness project was the first attempt to optimize the data structure of a transaction to increase the number of transactions that can be allocated into a block without increasing the block size.
Even though the short-term threat of a contentious hard fork has been avoided for now, the Block Size Debate is far from over. In the email announcing the suspension of SegWit2x, it seemed clear that the project was being suspended, but not necessarily abandoned, due to a lack of consensus. According to the same email, the leaders of the project “believe it will eventually become obvious that on-chain capacity increases are necessary” and “when that happens, [they] hope the community will come together and find a solution, possibly with a block size increase.”
Forking Bitcoin has become to the fastest way to get a cryptocurrency listed on an exchange, and contentious forks such as Bitcoin Cash are likely to reoccur. We will continue our research on scalability solutions that, like SegWit, increase transaction throughput without sacrificing decentralization and security. For the past two years, vertical scalability solutions, such as block size increases, have been suggested by prominent members of the community, and most have failed. Our analyses indicate that vertical scalability solutions will not sufficiently scale tokenized networks, and such proposals will always carry a risk of dividing the ecosystem. For these networks to achieve sufficient throughput to compete with their centralized counterparts, there needs to be more focus on horizontal scalability solutions that benefit from parallel computation. SegWit lays the foundation for such solutions, and we will continue to closely monitor future developments.