Unlimited, Classic and ‘BitPay Core': Bitcoin’s New Kids on the Blockchain

Referred to as the Satoshi client, Bitcoin QT, Bitcoin Core , or simply Bitcoin’s reference client, the original Bitcoin implementation as introduced by Satoshi Nakamoto has always set the standard for Bitcoin’s consensus rules. While alternative implementations were launched over the years, these were programmed to follow or even enforce existing conduct.

Bitcoin XT , the Bitcoin implementation by recent R3CEV -hire Mike Hearn, was a first attempt to break with that concept. Regarded a controversial move by many, Bitcoin XT is programed to break existing consensus rules in order to increase Bitcoin’s block-size limit from 1 megabyte to 8 megabytes, set to double every other year until it reaches 8 gigabytes. So far, Bitcoin XT has failed to gain sufficient adoption among the mining community.

But its intended strategy does seem to have started a trend. Over the past weeks and months, three additional Bitcoin implementations were introduced, all with the intention of breaking Bitcoin’s existing consensus rules in order to set a new block-size limit.

Bitcoin Unlimited

Bitcoin Unlimited , a fork of Bitcoin Core, was the first of three new Bitcoin implementations set to increase the block-size limit, and is maintained by lead developer Andrew “thezerg” Stone. Dr. Peter R. Rizun, aspiring managing editor for Ledger , the first peer-reviewed academic journal dedicated to Bitcoin and cryptocurrency research, is prominently involved with Bitcoin Unlimited as well.

Rizun, in particular, rose to fame within the Bitcoin community as one of the loudest voices in favor or a block-size limit increase, after publishing a controversial paper claiming a block-size limit is not required to establish a fee market.

Bitcoin Unlimited’s main differentiator, as the name suggests, is the absence of a hard-coded block-size limit. Instead, it allows users to manually set this limit on their own nodes; the Bitcoin Unlimited team expects consensus on a limit to emerge naturally at a so-called Schelling point . (Though it should be noted that setting the limit above 160 megabytes would be pointless, as the implemented message-size limit will invalidate blocks larger than this.)

Bitcoin Unlimited does include a default maximum block-size setting, or rather, two. The block creation limit, which is used by miners, is set at 1 megabyte. As such, miners will not create blocks that break existing consensus rules, unless they manually choose to do so. (Additionally, Bitcoin Unlimited nodes will not forward blocks larger than 1 megabyte to other nodes.)

The block acceptance limit is also set at 1 megabyte, but with an important exception. If a block up to 16 megabytes manages to be included in the longest chain at four blocks deep – meaning it has four confirmations – Bitcoin Unlimited nodes will consider these blocks (hence, the chain) valid. This number of required blocks is configurable by users as well, and is intended as a fail-safe to ensure Bitcoin Unlimited users accept only larger blocks if a significant amount of hashing power supports it.

This means two things. First, Bitcoin Unlimited will not break existing consensus rules by default, even if it were the only Bitcoin implementation people would even run. After all, miners would never create blocks larger than 1 megabyte. And even if one or several miner(s) manually increased their limit but were unable to find four blocks in a row, nothing would change for these miners exept that they would waste resources mining blocks no one accepts.

Second, if one or several miners create blocks larger than 1 megabyte (but smaller than 16 megabytes), and find four in a row, all default Bitcoin Unlimited nodes will consider these blocks valid. But since all nodes still adhering to a 1 megabyte block-size limit would consider these blocks invalid, the blockchain would split into two irreconcilable versions. This situation would last as long as the Bitcoin Unlimited chain remains longer, or until all non-Bitcoin Unlimited nodes switch to accept larger blocks.

Other than the default settings, Bitcoin Unlimited does not include an automated solution to make sure all nodes apply the same block-size limit. The implementation will, however, include methods for miners and nodes to signal the limits they have set.

Lastly, Bitcoin Unlimited intends to introduce a level of democracy into development and management of the implementation. Most importantly, the Bitcoin Unlimited lead developer is to be elected every other year by Bitcoin Unlimited members, and can be removed through a vote of no confidence. Bitcoin Unlimited will also have an elected president in charge of high level management, and an elected secretary to deal with administrative issues. No position has yet been elected, with first elections on January 15.

Anyone who wants to become a Bitcoin Unlimited member can do so, anonymously if they so please. The Bitcoin Unlimited team intends to limit vote manipulation, but is still considering possible solutions.

Bitcoin Classic

Bitcoin miner and developer Jonathan Toomim, FinalHash CEO Marshall Long and former Bitcoin Foundation board member Olivier Janssens launched another Bitcoin implementation this week. Named Bitcoin Classic , the Bitcoin Core fork intends to increase the block-size limit to 2 megabytes later this year.

Two megabytes was picked based on data collected by Toomim, who forked the Bitcoin testnet earlier this year to test global block propagation with large blocks. Additionally, Toomim talked to many Bitcoin miners and – particularly – mining pools, and believes the consensus among them also is to increase the block-size limit to 2 megabytes.

Similar to Bitcoin XT, Bitcoin Classic will probably increase the block-size limit to 2 megabytes once 750 of the last 1,000 blocks include a message in favor of such an increase. If that happens, a grace period of several weeks will commence, after which all Bitcoin Classic software will automatically accept blocks up to 2 megabytes. If, at that point, other Bitcoin nodes have not changed their software to accept 2 megabyte blocks as well, the blockchain might split into two incompatible versions.

Like Bitcoin Unlimited, Bitcoin Classic also intends to establish democratic decision-making on code changes, using miner and user input. To establish preference topics, Bitcoin Classic has collaborated with Consider.it to establish bitcoinclassic.consider.it . Anyone can create an account on the website, open polls on development topics and vote. If a majority of both users and miners (the latter will need to provide proof they are indeed a miner) supports a change, it should be implemented.

That does not mean, however, that votes on bitcoinclassic.consider.it are binding. If there are signs of vote manipulation, Toomim will judge whether the voting procedure was conducted fairly. Furthermore, neither Toomim nor other developers are obliged to write code they don’t want to, even if the poll shows a preference for a specific solution that requires coding. And since an automated process to merge code has not been installed (yet), Toomim will still need to manually approve of any change as well.

According to its website and this GitHub page , Bitcoin Classic is so far endorsed by former Bitcoin Core lead and Bitcoin XT developer Gavin Andresen (who has done some code review), mining pools AntPool (24 percent of hash power) and BW Pool (6 percent of hash power), companies Coinbase and OKCoin and more.

‘BitPay Core’

Lastly, major payment processor BitPay released a fork of Bitcoin Core . In a series of blog posts, CEO Stephen Pair announced that the company will experiment with an adaptive block-size limit, in an implementation we will dub “BitPay Core” for now. BitPay might soon start to officially convince others (most importantly, miners) to adopt this proposal as well.

In his fourth and last blog post of the series, Pair laid out his belief that Bitcoin could essentially work without a fixed limit. However, he believes that would leave a lot of uncertainty for miners – presumably because other miners might reject blocks of a certain size even without a set limit. As such, he prefers there to be a clear and simple consensus rule for it that all miners follow.

Pair essentially wants to implement two types of block-size limits. One “hard limit,” which is the real limit: the maximum block size miners will accept as valid. According to the initially proposed parameters as described by Pair, this limit might be set at twice the size of the medium block size of the last 2016 blocks (about two weeks – like the difficulty adjustment).

Additionally, Pair proposes to implement a “soft limit,” which miners could manually increase or decrease if they choose to. This soft limit is the default limit miners will use to create blocks themselves. Like the hard limit, it will be based on the median of the last 2016 blocks (or so), but with a smaller multiplier – such as 1.5 instead of 2. As such, blocks miners using the default setting could produce bigger blocks than average.

BitPay Core is currently still in an experimental phase. BitPay is (presumably) not using the implementation for their services quite yet, and the company is not yet actively promoting it either.

Thanks go out to aspiring Bitcoin Unlimited secretary “Aquentin” and Bitcoin Classic lead developer Jonathan Toomim for providing additional information.

Note: Bitcoin Magazine has not tested or reviewed the code of any of these implementations. Breaking Bitcoin’s consensus rules prior to network-wide consensus, as well as other potential bugs, could cost users money.

Photo Idaho National Laboratory / Flickr(CC)

The post Unlimited, Classic and ‘BitPay Core': Bitcoin’s New Kids on the Blockchain appeared first on Bitcoin Magazine.