"Nutty."

No, developer James Hilliard isn't describing his lunch.

Rather, that's his choice of description for Segwit2x, the controversial technical roadmap announced by bitcoin's startups and miners in May, and that has been the center of widespread debate ever since.

Like many developers, Hilliard is openly critical of the proposal and the timelines it is seeking to impose on development. Still, his skepticism is particularly notable as he's played perhaps the biggest role in helping boost perceptions the plan is moving forward.

If you went so far as to argue he's the reason the Segwit2x timeline is being met (and that bitcoin hasn't split into two competing assets), you wouldn't find many detractors.

That's because Hilliard has been the driving force behind a code proposal called BIP 91. Aimed at coordinating miners to push through the long-awaited code optimization Segregated Witness (SegWit), it's been called the first of the two pieces to the Segwit2x roadmap, though that may obscure that it was actually an outsider's idea.

After BIP 91's approval by miners last week, and barring any bumps, SegWit could activate by the end of August. Not to be undersold, it's a major milestone for the network, one that moves a long-heralded technical development out of political gridlock and one step closer to activation.

And to many, Hilliard deserves the credit.

Given the heavy politicization of the development of late, it shouldn't be a surprise that Hilliard's motivations for his role in the code upgrade have been questioned.

Does he support an eventual and controversial upgrade to a 2MB block size? Is he doing it largely to avoid a split? Which developer team does he prefer?

In a new interview, however, Hilliard made clear he's not a fan of the full Segwit2x agreement, particularly the move to 2MB that it seeks to enact later this year.

The next step for Segwit2x is to boost the block size via a hard fork, a process that's been heavily debated (not to mention denounced as dangerous if not properly implemented).

Already, Segwit2x developer Jeff Garzik is marshaling the charge toward this milestone. But, Hilliard is concerned about this approach. For example, he believes Segwit2x's three-month timeline is too short to say the least.

"Three months for a hard fork is completely unrealistic," he told CoinDesk, adding:

Many other developers

argue that there's little chance a 2MB hard fork can be safely executed in three months, since it's a change that could lead users to lose bitcoin if not implemented correctly.

And Hilliard's opinion should matter on the issue.

When not working as a technician for mining firm BitmainWarranty, Hilliard has put time researching safe hard forks. As a result, he believes changes to bitcoin's "consensus" code (the rules that keep the network in one piece), are naturally difficult.

"Nothing's simple when it comes to consensus code, especially not this one. It's something that looks simple on the surface, but when you actually start looking at it, it's really complicated,” he said, adding:

He offered SegWit as an example, noting that it took months to fix all the "known" issues with the code. But developers, he noted, have to deal with "unknown unknowns."

"As you're implementing it, you realize, 'Oh, here’s one issue that you need to deal with.' And another comes up, and another," he said.

That's why many Bitcoin Core contributors are wary of hard timelines, like those encouraged by the Segwit2x agreement. "You really don't know how long until it's going to take until the change is done," he added.

And some would argue that the Segwit2x group isn't taking these software security concerns very seriously.

As evidence that others are beginning to think similarly, Hilliard went as far as to assert that bitcoin mining pools might not follow through with running code created by Segwit2x developers, even though they have pledged to.

In other words, they might just switch back to Bitcoin Core's software before the hard fork, since they don't necessarily have to commit to new software.

Indeed, mining pool F2pool, and possibly other mining pools, are running Bitcoin Core with BIP 91 instead of Segwit2x's software already, a move that does much to indicate which code is trusted.

An issue that goes hand-in-hand with this is that some users have criticized the Segwit2x group for closing itself off from some of the industry's most knowledgeable developers.

Only select developers and companies were originally invited to the mailing list and the Slack group where testing is being done and talked about. (Although, the Slack opened to new members as of yesterday.)

And even though his idea was accepted by the group, Hilliard thinks it's true that Segwit2x's review process is closed.

Bitcoin Core contributors unanimously reject the proposal, for instance, yet their feedback has been ignored (or outright dismissed).

He told CoinDesk:

Though it might seem like a large reaction to a small thing, he's hardly alone in feeling that Segwit2x's goal is to put the needs of high-risk startups over users of a true, decentralized online currency.

Blockstream CEO Adam Back, who has been another outspoken opponent of Segwit2x for a similar reason, told CoinDesk that he believes the closed development process is "highly unethical" and "not remotely in the spirit of open internet protocol development."

Such comments to point to the likelihood that technical debates will continue, even though bitcoin's capacity may soon increase.

Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which helped organized the Segwit2x proposal.

James Hilliard image via Flickr