Divisions in the ongoing block size debate grew more pronounced this week following a private conference and a spike in network activity that saw users waiting longer and paying more to have transactions confirmed.
The ongoing debate over how the bitcoin blockchain should be scaled to accommodate new users was reportedly a point of focus as the recent Satoshi Roundtable, an invite-only retreat that united developers and business leaders. However, signs suggest that attendees emerged from the event with a more negative view of the state of discourse.
But even as tensions linger, development on both two competing versions of the bitcoin software – Bitcoin Classic and Bitcoin Core – is continuing as the groups lobby for support from the network’s wider user base.
In late February, Bitcoin Core, the network’s largest and longest-tenured group of developers, released a new roadmap, and along with it, the latest release – version 0.12.0 – of the software.
Soon after, the team behind the alternative bitcoin implementation Bitcoin Classic announced its 2016 roadmap, and this week followed up with a release of the latest version of Classic, based on Core version 0.12.0.
The releases remain of interest to the community, as when it comes to a potential bitcoin fork, the result may be winner take all.
Leading technologists believe the group that is able to get consensus around their vision will quickly see their rule sets enacted, and that despite concerns, a risk of the network splitting into two incompatible versions of the blockchain remains low.
Bloq CEO Jeff Garzik told CoinDesk:
“The network will rapidly follow the winning fork, [there are] billions in incentives.”
This article looks at the makeup of these two releases and how both groups are moving forward to implement their vision for the bitcoin network.
Classic roadmap
In its official 2016 roadmap, the development team responsible for Classic released the intended plan for rolling out software over the next 11 months.
During the first phase, the team expects to implement BIP 109, originally proposed for Core by developer Gavin Andresen, which would increase the size of transaction blocks on the bitcoin network from the current 1 megabyte (MB) per block to 2 MB per block.
The threshold for this transition would be when 751 of the previous 1,000 blocks were mined with the code supporting bigger blocks. Upon reaching that 75% threshold, a 28-day activation period would begin.
Andresen told CoinDesk:
“The danger of a high threshold is a miner or pool operator may be coerced to exercise that veto – they might be threatened or blackmailed. This is not a theoretical risk. We do see denial-of-service attacks against pools or services ‘voting the wrong way’ and there have even been reports of death threats.”
The 28-day period has left some in the community concerned, but Andresen remarked in a recent blog post that “several of the major bitcoin miners, exchanges, [and] web-wallet providers” have indicated the activation period gives them “plenty of time” to change their software.
He further defended the 28-day grace period by comparing it to the last block version upgrade.
Andresen explained that it took approximately a month to reach 75% of the hashrate and once that happened, it only took a further seven days to reach 95% of the hashrate.
In other words, he believes there doesn’t appear to be significant concern regarding a 28-day transition window.
Future phases for Classic
In the event that the hard fork does commence, Classic will enter its second phase during Q2 or Q3 2016 with the intended goal of addressing block size concerns.
“The goal of phase two is to eliminate the technical barriers (due to an inefficient network protocol) that limit the capacity of the network. Instead of transmitting a huge burst of data when a new block is found, a tiny amount of data will be broadcast, referencing transaction data that must have already been broadcast,” Andresen explained.
He went on to state that these efficiencies are not a concern at 1 MB or 2 MB blocks, but that the ultimate goal of phase two was to “stop central decision-making about the ‘right’ maximum size and get back to Satoshi’s original vision of a self-regulating system”.
The final step for the Classic team is to introduce a dynamic block size limit, but only after “miners and companies confirm phase two successfully addressed their block size concerns.”
One proposal presented in the roadmap is to use a variation of the adaptive block size based on recent median block size outlined in a recent blog post by Stephen Pair, CEO of BitPay.
“To determine the block size limit, you compute the median block size over some recent sample of blocks and apply a multiple,” Pair wrote.
Pair goes on to explain that, unlike the average block size, median is much harder to game. With an average block size, miners could inflate the block size with their own transactions or, on the other hand, put no transactions into blocks. With median, “you would need coordinated action by more than 50% of the mining capacity”.
Of course, if someone controlled more than 50% of the mining capacity, bitcoin has bigger issues to contend with than the block size limit.
Along with an increase to the block size, Classic is planning to hold a conference “where these and future scaling solutions & concerns can be discussed among the community”.
The new release, published on 7th March, incorporates elements from Bitcoin Core’s 0.12.0 but notably leaves the opt-in replace-by-fee (RBF) feature, with which users can rebroadcast transactions with higher fees so long as they haven’t been included in a block, set to disabled by default.
Core releases latest software version
The Core development team announced the release of v0.12.0 on 23rd February, which the developers described as potentially being “the biggest one yet, with more significant improvements than any other before”.
The team framed the release as being focused on optimizing overall software performance. In many instances, it was meant to reduce needed computational resources or improve the speed at which actions can take place.
In November 2015, Core developer Pieter Wuille submitted a pull request to switch to a libsecp256k1-based ECDSA validation. In it, he explained that there would be three benefits to making that transition.
“Signature validation is anywhere between 2.5 and 5.5 times faster; Consensus code no longer depends on OpenSSL or its signature parser; Removes linking with OpenSSL from libconsensus,” he wrote.
There were also security implications to switching away from OpenSSL.
“OpenSSL is very comprehensive in its capabilities, but this enormous feature set means that its attack surface is fairly large as a result,” the team wrote in its v.0.12.0 announcement.
After spending nearly three years in development, libsecp256k1 has been merged with the Bitcoin Core client, resulting in what the team says is a seven-times improvement in signature validation speed. Further, because libsecp256k1 is focused primarily on signature validation, the area for security exploits is much smaller, according to Core.
Continuing with its optimization, the team also rolled out a mechanism to prevent node crashes due to memory pool limits.
Another key change has to do with how nodes store transactions that haven’t yet made it into a new block.
In a blog post published before he left the Bitcoin Core team, developer Mike Hearn warned about the potential for a significant decrease in network nodes.
As transactions are made, they enter into the memory pool where they are held until they show on the blockchain. As more transactions occur, more are forced into the memory pool. For nodes that have a lot of memory, this isn’t an issue; however, those that are operating with minimal amounts of memory face a potentially bad situation.
Hearn outlined three possible scenarios that could from this circumstance:
“The node might become incredibly slow as it enters swap hell; the node might crash when it tries to allocate memory and fails; the node might be killed by the operating system kernel.”
To counteract this, Core introduced a feature called memory pool limiting, which sets a default hard limit on the size of the memory pool; specifically, it is set to 300 MB in 0.12.0.
What effectively happens is that, as a node starts picking up more transactions, if the memory pool hits that 300 MB limit, the node will first drop transactions that offer the lowest fee per bye rather than simply accepting more transactions.
Cutting resource costs
0.12.0 also introduces an upload traffic limiting factor. With nodes constantly relaying transactions around the network, it can result in increased amount of upload resources, putting a burden on individual nodes.
An upload traffic limiting factor allows for the operator to limit how much data is uploaded and shared with the rest of the bitcoin network. In the event that it hits this limit, the node will serve the blocks that were requested within the past week, thus minimizing resource needs.
To further prevent nodes from being overwhelmed, the team introduced wallet pruning.
Presently, nodes store a complete copy of the blockchain. As of writing this article, that means each node needs to store 57.8 GB of transaction data. The larger this gets, the more storage space is needed.
The new ‘pruned mode’ allows those that use the Bitcoin Core wallet to cut back on the required disk space from 60 GB to only 2 GB.
“This means that the node will only focus on keeping track of unspent outputs and will forget previously-processed blocks as well as outputs that have been spent,” the team explained.
While there was controversy with the inclusion of replace-by-fee, fundamentally, the new release focused on making it less resource-intensive for nodes to operate.
As the number of nodes has dipped down over the past few years, reducing the necessary resources should result in more users opting to run nodes that fully validate the blockchain. The more nodes in the network, the safer bitcoin becomes.
Lost hiker image via Shutterstock