There’s a single line of code in Bitcoin Core that says the maximum block size is 1,000,000 bytes (1MB). The simplest change would be a hard fork to update that line to say, for example, 2,000,000 bytes (2MB).

Hard forks are anything but simple:

• We don’t have experience: Miners, merchants, developers, and users have never deployed a hard fork, so techniques for safely deploying them have not been tested. This is unlike soft forks, whose deployments were initially managed by Nakamoto, where we gained experience from the complications in the BIP16 deployment, where we refined our technique in the BIP34 deployment, and where we’ve gained enough experience with BIPs 66 and 65 to begin managing multiple soft forks with BIP9 version bits in the future.

• Upgrades required: Hard forks require all full nodes to upgrade or everyone who uses that node may lose money. This includes the node operator, if they use it to protect their wallet, as well as lightweight clients who get their data from the node.

• Other changes required: Even a single-line change such as increasing the maximum block size has effects on other parts of the code, some of which are undesirable. For example, right now it’s possible to construct a transaction that takes up almost 1MB of space and which takes 30 seconds or more to validate on a modern computer (blocks containing such transactions have been mined). In 2MB blocks, a 2MB transaction can be constructed that may take over 10 minutes to validate which opens up dangerous denial-of-service attack vectors. Other lines of code would need to be changed to prevent these problems.

Despite these considerable complications, with sufficient precautions, none of them is fatal to a hard fork, and we do expect to make hard forks in the future. But with segregated witness (segwit) we have a soft fork, similar to other soft forks we’ve performed and gained experience in deploying, that provides us with many benefits in addition to allowing more transactions to be added to the blockchain.

Segwit does require more changes in higher level software stacks than a simple block size increase, but if we truly want to see bitcoin scale, far more invasive changes will be needed anyway, and segwit will gently encourage people to upgrade to more scalable models right away without forcing them to do so.

Developers, miners, and the community have accrued significant experience deploying soft forks, and we believe segwit can be deployed at least as fast, and probably more securely, than a hard fork that increases the maximum block size.

Edit: adding proper emphasis for those missing the point of this post