Jeff Garzik has been accused of a lot of things of late.

Since taking the lead on turning the Segwit2x scaling agreement into code, the CEO of blockchain startup Bloq has been accused of everything from closing off bitcoin’s open-source development to encouraging unnecessarily aggressive network changes to playing loose with facts to sway public sentiment on the plan.

But if the long-time developer, one of the first employed by a startup to work directly with bitcoin’s underlying software, has emerged as a lightning rod, Garzik seems enthusiastic about the role.

Fond of taking on critics head on in lengthy Twitter exchanges, Garzik may be unique among bitcoin developers in displaying a largely take-charge entrepreneurial mindset, one that finds him at odds with the project’s more security-conscious developer group, Bitcoin Core.

But if Garzik is under scrutiny now, he’s likely to be there for some time.

While there are a few steps left before bitcoin’s long-awaited capacity upgrade is a done deal (it’s looking increasingly likely that bitcoin miners will push a scaling upgrade by the end of August), the code changes he’s shepherding aren’t due to conclude until the fall.

That’s when they’ll perhaps hit a fever pitch that dwarfs the current debate, and in a new interview, Garzik doubled down on his intent to introduce the code for a hard fork that would further boost the network’s capabilities while putting it again on a path to a split.

Against this backdrop, Garzik sat down with CoinDesk to discuss his thoughts on the future of Segwit2x, addressing the key questions and controversies that have been bubbling behind the scenes of late.

Below, that interview is reproduced, though some of Garzik’s comments have been shortened for clarity.

Mining pools started signaling for BIP 91 earlier than expected this week – why given that they’ve been reluctant about SegWit in the past? 

They were chomping in the bit. One of the completely ridiculous narratives out there is that mining pools are blocking SegWit and don’t want SegWit for various reasons.

In real life, they’re chomping at the bit to activate SegWit.

They’re really ready to plunge and take the plunge to step two in scaling, which is raising the block size. They were ready to pull the trigger as soon as everyone could get their nodes spun up.

Didn’t the original deployment of SegWit stall because of lack of mining pool support?

Well, it was more than just miners.

That’s the thing about Segwit2x. SegWit wasn’t going to increase the block size at a speed that was realistic to a lot of the players in the space. By itself, it’s a two-step upgrade. First you upgrade the nodes to support those new rules, then you have a year-long process of updating the wallets. Upgrading the wallets, that second step, is where SegWit actually brings new capacity.

After this long, contentious debate, a SegWit-only path would only leave us with only the same capacity that we have now.

That’s why it stalled. And why Segwit2x moves that needle forward. It delivers guaranteed short-term capacity. That’s the base block size increase. And it sets the foundation for the long-term, and that’s SegWit.

Mining pools are already running the code. Is it safe for them to do so even if the final release isn’t out?

Absolutely. The consensus rules have not been changed. Those are the security rules changed across the entire network.

We’ll release the final version when it’s ready. If there are bugs, we’ll have a second, third, or even fourth release candidate.

It’s released when it’s ready. There are never guarantees with software.

Segwit2x introduces SegWit code to the network, but you’ve been critical of SegWit in the past, or at least soft forks. Did you change your mind in support of Segwit2x?

Nope. Basically what happens with Segwit2x is there’s a short, interim soft fork and a hard fork that locks in those SegWit rules. It locks in in a way in a A or B way. That’s what a hard fork does that a soft fork doesn’t. It gives users a choice to follow the chain or not.

But with a soft fork, all rules are already accepted by all rules in a soft fork. You can imagine many different situations where you don’t want to automatically accept new rules.

A hard fork is different in that the network doesn’t automatically accept the new rules.

I’ve been a proponent of SegWit as a hard fork, because you lock in those rules in a way that people endorse those rules or not. That’s the outcome of Segwit2x. Post-hard fork, the SegWit rules are locked in.

Segwit2x is most likely to result in one coin, whereas a big block hard fork or just a SegWit upgrade was stuck at 30% hashrate and no consensus from economic nodes. You have SegWit-only, Bitcoin Core supporters. Then you have partisans on the other side – the we need big blocks, Bitcoin Unlimited, etc.

Neither of those were getting full traction in the market. It got to 30% and then got stuck. The community was just at this gridlock stage.

Segwit2x at a high-level attempts to move past that gridlock, moves past the communities are stuck in a way that results in one coin that doesn’t result in a chain split. That riles up people in the big blocker community as well as some of the people in the SegWit-only, Bitcoin Core community. But there’s a lot of support for it and it’s getting rolled out on the network right now because Segwit2x is, ironically, the fastest path for activating SegWit.

Many in the community have criticised Segwit2x for its closed development process.

That’s pretty typical of the mud slung by Peter Todd and Adam Back specifically. It’s not true at all. The GitHub is completely open, the mailing list completely open. All the feedback that’s been received has been thoughtfully addressed.

The feedback that we’ve received from Bitcoin Core to date has largely been make-this-change-that-breaks-all-of-the-wallets-type changes, signaling the hard fork in a different way, or just a disruptive, trolling GitHub comments.

There’s all sorts of mud being slung. There are some people who don’t like things being done in the way they wouldn’t have done them.

The main criticism that comes up is the 2 MB hard fork. Some developers think that it could be done in a safer way or think that the three-month timeline is too fast.

This gets into the weeds of the scaling debate. Those are criticisms from people who have delayed planning a hard fork for years. That’s really why supporters of Segwit2x wants to move on. They didn’t get more than 30% traction. SegWit is a great technology, but it’s not very good at delivering capacity.

Capacity, high transaction speed – and the proposal proposes to extend a years-long delay with another years-long delay as SegWit capacity ramps up. That’s the core at that disagreement.

Folks who’ve failed to plan for a hard fork who’ve thrown shade on all hard forks are throwing more shade on this one. That’s entirely expected. That’s part of the process of reaching across the isle and bringing these two camps together.

It’s no surprise that the democrats in bitcoin don’t like the republicans in bitcoin.

It seems like some are completely opposed to a hard fork, but some developers think that the timeline should extended to a year instead of three months.

I’ll disagree with that. If you go through the Twitter history, they’ve been saying that for years. There’s never enough time for a hard fork, yet that planning never happens.

The community has lost patience with that message. There’s no outcome other than delay.

Will Segwit2x add replay protection in the case of a hard fork? 

Definitely. There have been a few proposals.

One was proposed by a Bitcoin Core contributor. That replay protection would break every wallet, so we view that as a non-serious, disruptive proposal.

The other proposal was from [former lead bitcoin maintainer] Gavin Andresen. Others have proposed forms of opt-in replay protection.

That’s definitely something we’re looking into, but we’re not interested in breaking all wallets.

There is a contingent of bitcoin users who disagree with the hard fork aspect of Segwit2x. Will that impact whether it succeeds?

That’s actually why I think that hard forks are better than soft forks.

With soft forks you’re automatically accepting the new rules. If you disagree with a hard fork, then you do not automatically accept the new rules. From a governance perspective, that’s very, very healthy.

To answer your question, that won’t disrupt the hard fork.

Furthermore, it’s a good thing that people can disagree with the hard fork. Disagreement and freedom of choice is great and it’s what makes bitcoin great.

Do you think that could lead to a split then?

I do. My predicted outcome, as we’re seeing right now, is that the miners are adopting the BTC1 software. And that leaves the vast majority of mining software on one coin.

By definition, a minority chain behaves in a certain way. If a large amount of the hashpower splits away from the chain or in a UASF scenario, where many users run away from the hashpower, the software behaves in a very predictable and known way. The chain grounds to a halt. Instead of it taking 10 minutes to mine a block, it takes, say, a few hours per block. You have 2016 blocks before you have a difficulty ramp-down.

What that means for users is that it’s unusable for a while. What happens when there’s a hard fork is there’s going to be – the vast majority of hashpower will activate and secure the 2 MB chain.

There will be a chain that nobody uses. Number three, there will be a tiny amount of activist users who don’t want a hard fork at all. And that will continue as a much smaller security level.

Say it does split and the minority group coin doesn’t work as well in the way that you described. Isn’t that forcing choice?

I agree. That’s very true. There are unquestionably incentives that lend you to stick to the chain with the most hashpower.

But the governance point is that there’s a choice point. Whereas in a soft fork there’s not. But every user has to make that choice.

I think the more informed each user is, the better.

What do you think of other scaling proposals like BIP 148 or BitcoinABC?

UASF has no hashpower and no economic nodes supporting them.

If it weren’t for Segwit2x activating SegWit, they would fork themselves off into the unusable chain scenario that I described.

They would have to create a second chain fork to correct the difficulty to get back to the 10-minute block times. That’s how it will play out without hashpower, which looks like unlikely scenario. With hashpower, which is how things are playing out now, SegWit will get activated and the UASF folks will get what they were asking for – and there will be no chain split.

BitcoinABC is creating a new coin. Segwit2x is not going to have a major impact on BitcoinABC itself. There will be a slight reduction in hashpower, maybe 4% moves to BitcoinABC. It’s essentially an altcoin, where every bitcoin holder has a stake in the new coin.

It shouldn’t majorly impact bitcoin users or Segwit2x.

Some people are saying that the UASF is what led to Segwit2x, and that mining pools are are signaling for BIP 91 right now to avoid a UASF.

It’s basically to maintain unity. Not to avoid UASF, but to make sure that everyone on the main chain stays on the chain by activating SegWit. It’s the unity path. Everyone, including the UASF activists, get what they want, which is SegWit activating.

It’s going through the Segwit2x path by activating at ‘bit 4,’ which should lock-in today. That will flip on ‘bit 1’ which will activate SegWit.

That ‘bit 4’ activation three months in the future will also trigger the fork rule change.

Some have argued that sidechains are a better alternative to a 2MB hard fork, since users can opt-in to a system with whatever blocksize parameter they want.

Bloq sponsors the Drivechain project, which is a project for adding usable sidechains to bitcoin in the future. Blockstream originated the sidechain proposal, but their sidechain never really made it to bitcoin.

Drivechain technology potentially allows you to have a sidechain that has huge blocks, it doesn’t matter what rules are on there.

The issue with that is maturity level. It’s an in-the-lab science project. Were it more secure, it might be a better solution today, but like Lightning it’s a very promising technology that’s still getting baked.

So the 2 MB parameter increase is a short-term solution. Then, maybe Drivechain come later?

Exactly. Basically, the 2 MB hard fork is the one path that we know with 100% that guarantees increased capacity.

We don’t know how much capacity SegWit will deliver because we don’t know how many or how few people will update their wallet software to enable SegWit. That’s an unknown. Lightning, we don’t know anything about the trust model or economics of that. So, we don’t know if that will be used.

Sidechains are similarly just getting baked. All of these are promising projects that we don’t know will be a solution yet.

The 2 MB hard fork is definitely a stopgap until we get something better. But as I always say, mind the gap. It’s pragmatism versus a years-long science project that may or may not work out.

How long do you plan to work on Segwit2x? Are you in it for the longhaul or do you plan to stop after the hard fork?

No, it’s a very focused. It will not expand its charter at all. This is in keeping with IETF working groups. We have this one charter to activate SegWit and activate a hard fork and that’s it. It’s a one-and-done. You see the same thing at Red Hat, where I used to work, for developing software and hardware specifications.

When working on the Linux kernel, we got people who hated each other and they actually worked together in a focused setting, accomplishing a specific goal, such as developing USB specifications. Segwit2x is modeled after that. It will be disbanded after that’s in place.

Now, the BTC1 project, I’m calling the Fedora of bitcoin. It will be around after the Segwit2x .

Any plans on what you’ll do with BTC1 after that?

I really want to create a community that’s more professional that doesn’t spin narratives and sling mud and that welcomes more developers. When I worked at Linux we helped new developers up the steep learning curve.

We could do that, but instead, to my sadness, we have certain portions of the community who are very negative about any new developments and negative in pushing the bounds.

Ethereum has been very welcoming. Bitcoin is by far the most secure blockchain out there, and much more secure than ethereum. But ethereum is doing a better job of attracting new developers.

I want BTC1 to be sort of that welcome sign that I chose as an icon for the project. We want to welcome new projects, welcoming new ideas, rather than attacking ideas that are outside a self-defined bubble.

Is the plan to replace Bitcoin Core?

Absolutely not. This is a patchset on top of Bitcoin Core. We’ll use the best of Bitcoin Core, and we very much welcome those contributions, but also other contributions as well.

We want to work with Bitcoin Core, not against Core. Even if they disagree with us working with them, we want to work with them.

That’s what’s so amusingly ironic. The original SegWit authors are doing everything that they can to delay the rollout of SegWit, which is what Segwit2x is actually accomplishing.

You mentioned ethereum. A lot of people do mention that they’re more welcoming to new developers or new ideas. But some people argue that that could be a problem for the security of the software.

That’s absolutely right. We’re securing money. With new ideas, comes new risks.

Where Segwit2x comes in is it that, the core contingent is way too much on the conservative side where we’re letting bitcoin slam into this fee wall, which was predictable years ago, rather than prepare for a hard fork.

You can risk-adjust yourself into a corner and hurt market share where you’re being so conservative that nobody can use it.

Now that BIP91 has locked in, what do you see ahead?

Ultimately I think the best path for SegWit, which is not going to happen, would be to deploy it on a sidechain, test it on money for a year and integrate it into bitcoin. It’s seen some real money testing in litecoin, but that’s it.

Litecoin, they’ve only done the first step. Wallets aren’t using SegWit. The ideal scenario would have been a much longer cycle of real-money testing on a sidechain. That was the original vision of sidechains.

But we have what we have today. I think that Segwit2x is the best chance to deploy SegWit and to keep everyone on one coin.

It clearly has a large amount of buy-in, so we’re confident of its success.

Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which has an ownership stake in Bloq.

Jeff Garzik image via TEDx video