Last February, in the midst of Bitcoin’s long-lasting block size dispute, a group of Bitcoin Core developers, Bitcoin miners, and representatives from the Bitcoin industry met in Hong Kong. Sealing their position with a signed letter, the attendees agreed to run only Bitcoin Core-compatible consensus software for the “foreseeable future.” This avoided a potential hard fork as proposed by Bitcoin Classic or Bitcoin Unlimited — at least temporarily.

On their own behalf, the Bitcoin Core developers present at the meeting — Cory Fields, Johnson Lau, Luke Dashjr, Matt Corallo, and Peter Todd — agreed to propose a block size hard fork, with a deadline set three months after the release of Segregated Witness. If accepted by other Bitcoin Core developers and the broader Bitcoin community, the proposal could pave the way to a block size limit increase.

After months of testing and some delay, Bitcoin Core 0.13.1 became available to the public in the last week of October. With that, Segregated Witness was officially released.

Per the original agreement from February, this leaves the signatories to the agreement—who we’ll call the “Hong Kong developers”—with about 10 more weeks to propose a hard fork.

Soft-hardfork

A typical hard fork essentially creates a new protocol and network to which all users must migrate, abandoning the old protocol in the process. Unfortunately, this presents an inherent risk that not all users switch. The original protocol can live on, essentially creating two distinct networks and currencies: a coin-split. That’s exactly what happened on the Ethereum blockchain as a result of a contentious hard fork last summer, splitting into Ethereum and Ethereum Classic.

The Hong Kong developers, therefore, prefer a “soft-hardfork,” also known as a “forced soft fork” or a “firm fork,” and sometimes referred to as an “evil soft fork.” Like a typical hard fork, a soft-hardfork can change any protocol rule, including the block size limit.

As Peter Todd told Bitcoin Magazine, “Many prefer a soft-hardfork for the perceived reduction in the chance that the currency will split.”

Specifically, miners apply a soft-hardfork, through hash-power majority, by only mining “empty” blocks on the original protocol — blocks that contain no transactions. Users that stay behind on this “old” chain therefore can neither accept nor send any payments. In other words, they run no risk of being defrauded on an otherwise abandoned network.

Meanwhile, all new transactions are moved to a sort of “add-on” blockchain that only nodes that have upgraded for the soft-hardfork can see. While the original blockchain is still used for proof-of-work security, the new protocol exists in parallel.

Coin-voting

The main drawback of a soft-hardfork is that it can be applied against the wish of users; in that sense, it’s somewhat coercive. Unless they want to await a possible “return” of miners to the original protocol, users have no choice but to upgrade to the new rules — or to hard fork to an entirely new protocol themselves, in effect creating a new network and currency after all.

To avoid both a coercive situation and a coin-split, the Hong Kong developers want solid indication that a soft-hardfork has consent from the Bitcoin community. They have therefore been considering two types of solutions to measure consent, both of them based on the coins controlled by users. Knows as “coin-signaling,” this solution “would allow for much safer hard forks, by showing that Bitcoin holders and users actually approve of the fork,” Todd said.

One of these methods — inspired by “hard fork opt-out bits” — lets users include extra data in all transactions they make, thereby signaling support for a potential fork. If all transactions over a certain time frame include this data, they serve as an indication that users are ready to fork.

Todd also has been developing a solution to let users vote with the coins they hold, even if they do not transact. On his blog, Todd explained in August:

“I’ve been working on coming up with more concrete mechanisms based on signaling/voting proportional to coins held, in particular, out-of-band mechanisms based on signed messages and probabilistic sampling that could potentially offer better privacy and censorship resistance, and give ‘holders’ who aren’t necessarily doing frequent transactions a voice as well.”

The Proposal

Yet, when it comes to a concrete proposal, some uncertainty remains.

Luke Dashjr, who in addition to Bitcoin Core also maintains Bitcoin Knots, presented an initial soft-hardfork proposal and preliminary code back in February, two weeks before the group met in Hong Kong. He kept improving it in the months that followed, and it’s this proposal that forms the most concrete basis of the proposed “Hong Kong hard fork.”

This proposal would increase the block size limit, though the exact size of the increase is yet to be specified. According to the Hong Kong Roundtable consensus, the increase should be around 2 MB, but will also include a reduced “discount” on witness-data to ensure that adversarial conditions don’t allow blocks bigger than 4 MB. The proposal also includes further — rather uncontroversial — optimizations.

Progress on development, though, has slowed down over the last months. This is in part because the Bitcoin miners did not seem very interested in the proposal, Todd said. Perhaps more importantly, several developers — both those in Hong Kong and others — consider the agreement to have been broken by at least one counterparty in the deal: the Chinese mining pool F2Pool.

“The whole point of putting ‘Run Bitcoin Core compatible clients’ in the agreement was for miners to stop playing political games for a few months,” Todd explained, “and to give developers a reason to work with them. By not doing that, we’ve been totally unable to get any other developers to consider joining the effort, and if anything, the experience soured them on the very idea.”

Additionally, most of the Hong Kong developers have seemingly come to believe that short-term community consensus on a block size limit hard fork is virtually impossible in the current climate.

“The community clearly doesn’t want a hard fork, and the Ethereum fiasco just sealed that,” Luke Dashjr told Bitcoin Magazine.

Moving Forward

That said, the Hong Kong developers will continue to work on the proposal — something Todd noted they were planning to do either way. Whether it will be finished within the allotted three months after the Segregated Witness release remains uncertain.

“Nothing in that agreement on the developers’ side was stuff we weren’t interested in doing anyways,” Todd said. “The whole point was to find some common ground that people didn’t previously know they had … So I’m still working on my part, which is to design and implement better approval mechanisms that don’t rely on miners to approve forks — both soft and hard.”

Dashjr also said he will continue to work on the proposal. While he is no longer strongly committed to presenting fully finalized hard-fork code within the original three-month deadline, he might. And he remains hopeful the solution will eventually be adopted.

“Maybe in a few years things will change,” Dashjr said. “After the ‘hard fork’ altcoiners go away.”

The post The Status of the ‘Hong Kong Hard Fork’: An Update appeared first on Bitcoin Magazine.