In a clearly stated analysis and opinion blog post about the costs and benefits of doing either a hard fork to a 2 MB block size limit versus going with the “Hong Kong Compromise” Segregated Witness (Segwit) upgrade, Sam Cole offers the perspective from that of a Bitcoin miner in what options lie ahead.

From a pragmatic perspective, Cole gives a very clear explanation of how the Segwit solution is the much safer, simpler and easier one and all of the potential risks of failure and negative disruption that the hard fork has. However, it’s clear from Cole’s post that he believes there’s actually too much currently at stake to not take the risks associated with the hard fork.

From a development, testing and deployment process, Cole makes his argument clear that the Segwit soft fork is a lot more straightforward for everyone involved except for the developers involved with interacting with Bitcoin wallets. It’s voluntary to implement it, but it cannot be tested until it’s been activated. He believes that this will result in miners taking a very long time to implement Segwit because they’ll want to be sure of its effects on their systems.

From a developer’s perspective, the hard fork is a lot simpler and as long as it’s done carefully and in sync with the entire network, it can have much more impact on the problems that Bitcoin is facing.

As far as potential impacts and likely impacts, Cole really draws a line in the sand on where he sees the most benefits coming from. With Segwit being a voluntary soft fork, the benefits throughout the network will likely be negligible until there’s a mass adoption of it. Cole doesn’t see this adoption happening any time soon based on the timelines of “many months” it took to deploy other updates within the Bitcoin system. With the 2MB hard fork the effects should be felt right away.

Cole talks about his skepticism of Segwit’s real impact stating:

The biggest issue I can see here is that it’s impact will be low. In fact I think very low. It simply won’t solve anything. The network will still be slow the transaction volume from the same sources will continue to grow not taking advantage of the SegWit space. We will be back to where we started before long.

What Cole concludes his piece with is the issue around the Bitcoin network being spammed. Spammers are able to fill up blocks by sending many small payments through the network and it proves a serious problem for jamming up the whole system and causing massive delays.

Cole believes the Segwit solution will actually do nothing at all to solve this spamming issue. He also points out to the fact that spamming isn’t a cheap endeavor and that it costs about $40,000 USD for an attacker to fill up about 100k of blocks. For a spammer to do the same if a 2MB hard fork is implemented will cost them approximately $440,000 USD.

The difference of cost for spammers is prohibitive and could alleviate many issues being had on the network with confirmation delays.

Cole’s blog post makes it extremely clear that this debate, while it may be a clear and decisive win on one side in his view, is not one to be taken lightly. The repercussions if a hard fork is done poorly could be awful for the entire Bitcoin network.

However, the effects of going with Segwit and essentially causing no change in the near term could also seriously harm Bitcoin’s chances of continuing to grow in use and adoption. Despite what he seeing as a clear solution, Cole concludes he doesn’t realistically see anything happening one way or another any time soon because of how far apart both side are on the matter. Let’s hope he’s wrong on that, at least.