Bitcoin developers are probing deeper into how best to execute a so-called hard fork, a contentious upgrading tool that's been at the heart of the nearly $16bn network's most divisive debate for years now.

The issue is that to be used cleanly and without unintentional consequences, a hard fork requires all the digital currency's miners to move to a new blockchain, or version of its transaction history. One case study of what can otherwise happen came last summer, when ethereum inadvertently split into two networks after executing a hard fork some users disagreed with.

That's not to say that all hard forks have the same outcome.

Interestingly, the following two ethereum hard forks went according to plan, as they were non-contentious changes to fix attacks on the network, perhaps demonstrating that they can go well if all participants agree.

Meanwhile, against this backdrop, some in the bitcoin community have long been calling for a hard fork to increase transaction capacity by raising the blocksize parameter to 2MB or more, with Bitcoin Unlimited being the latest software to take up the call for action.

One impediment is that, since increasing the block size is a contentious change, a similar ethereum-like split could occur in bitcoin if a hard fork were executed.

For that reason and others, the engineering consensus seems to be that more research needs to be done before giving it a try in bitcoin.

BitmainWarranty's James Hilliard, who has tested code for Bitcoin Core, said that, though he's generally “conservative” on the issue of a hard fork (as are the most active contributors), there might be a potential need for one in the future, especially since it's the only way to make certain types of changes.

Hilliard told CoinDesk:

Of late, there's been an uptake in research in this direction, with some bitcoin code contributors continuing long-standing studies into how a hard fork might be used.

Lengthy analysis has been posted to the bitcoin developer mailing list over the last couple of months, and there's now even an open-source website filled with links to notable public hard fork research.

Bitcoin developers appear to be approaching the option carefully, looking into a range of considerations, such as how to safely execute such a change.

Along those lines, a batch of new hard fork proposals have been released in the last few months.

None have received much support in terms of near-term execution, but they have generated discussion and show an uptake in attention.

Perhaps most notably, Bitcoin Core contributor Johnson Lau, who has been perhaps the most prolific in terms of posting hard fork write-ups to the mailing list, just this week coded up a second experimental hard fork, called 'Spoonnet', with new features that bitcoin currently doesn't have.

He hinted that trying to activate it right now, without unanimous consensus, would not lead to positive results.

"Trying to activate it on testnet will get you banned. Trying to activate it on mainnet before consensus is reached will make you lose money," he wrote.

Despite the long write-up and code accompanying it, he mentioned that there are plenty of details to iron out before Spoonnet is ready to use, such as ensuring that wallets in the post-hard fork world would support transactions on the new network.

Lau’s other hard fork proposal, called Forcenet, codes up a type of hard fork known as a 'soft-hard fork', that makes old nodes follow the new rules, based on an earlier proposal by Bitcoin Core contributor Luke Dashjr.

It puts into practice a new block header format that adds room for more data, among other things.

Then, there are some hard fork proposals that relate more specifically to the block size debate.

Dashjr posted two hard fork proposals last month, one of which proposes an initial optional decrease to the block size that would switch to a steady increase to 31 MB.

Hilliard pointed out that hard fork research pertaining to the block size in particular has been going on for a while. He drew up with his own hard fork proposal last February, though perhaps owing to the speed of R&D, he said he wouldn’t vouch for it because it’s "overly complicated".

Notably, few of the newer proposals are related to making hard forks safer. For instance, addressing the issue that stakeholders could lose money (or see the value of their investment decline) if the blockchain splits.

One such proposal is for a 'hard fork warning system', with which wallets and miners can warn others in the case of a hard fork.

"With a hard fork warning system, users and merchants may stop trading when there is abnormality on the network until they are able to make an informed decision," Lau explained, mentioning that this might have been useful in former unintentional bitcoin splits, as well as that of ethereum.

Further, replay attacks featured heavily in the aftermath of ethereum’s fork and resulting blockchain split. In a nutshell, because the transaction histories were the same on each resulting network, users could send transactions on both networks, which caused confusion – at least up until the issue was fixed.

Proposals from Dashjr and Lau grapple with this issue using different techniques.

Interestingly, even the details of this protective action were cause for disagreement, with Bitcoin Core contributor Matt Corallo arguing in response to Lau’s bitcoin improvement proposal (BIP) that replay attack protection should be mandatory rather than opt-in.

Hilliard noted that another safety measure would be to have a "reasonably long" activation timeline of a year or so.

As far as for what reason to carry out a hard fork, the block size debate continues to be the elephant in the room.

In Hilliard’s opinion, the block size is not a good enough reason to hard fork, at least right now, where the split in opinion could manifest in two networks, and increasing the block size could increase the burden of running a volunteer node.

He added:

Still, figuring out a way to carry out hard forks safely might be beneficial, as there’s no other way to make certain technical changes to bitcoin.

"Fixing tech issues would be a good reason, in my opinion," Hilliard said.

He pointed to a long list of bug fixes and other potential changes on the so-called 'hard-fork wish list', including header format changes that would "make it so that miners mining on pools can't withhold blocks".

One other such change could bundle in what Lau called a "secondary block header", which could store new data that, for one, could potentially boost the security of SPV nodes (which store less data than regular nodes).

"None of the core devs are really against hard forks, they are just conservative," Hilliard said.

Lau similarly indicated that it could happen as long as most one day agree with a change.

"When the vast majority of bitcoin users believe the system is too inefficient (in many aspects, not just transaction throughput) and they believe the benefits outweigh the risks, a hard fork will happen," he said.

Hilliard, though, doesn't seem to be in a hurry, noting that it might take a while to find a solution that everyone agrees with.

He concluded:

Research image via Shutterstock