Bitcoin Upgrade Governance, Hard Forks and Segregated Witness

When considering upgrades of production systems, details of the transition can be as important as the theoretical end state goal being sought.

The two major updates currently being evaluated in the bitcoin community are a 2M hard fork, and a soft fork enabling Segregated Witness. Both upgrades have risks, benefits, and time factors involved. Both transitions need to be gamed-out in terms of ecosystem impact, software upgrades required.

Issue #1: SegWit Trickle-up complexity

In terms of updates to production software, Segregated Witness pushes complexity up-layer, with a ripple-out impact of changes, from one team (bitcoin core) to many teams out in the ecosystem. To give a specific example, one notable bitcoin business is using a custom fork of a bitcoin lib to power their core business systems and user-facing properties. Their operations are otherwise not block-size-sensitive. Their menu of choices are

• Upgrade bitcoind in conjunction with community roll-out plan (2M hard fork)

and/or

• Upgrade bitcoind to continue fully validating chain in trustless manner.
• Wait for bitcoin lib to receive SW updates (or DIY).
• Wait for bitcoin lib to proceed through raw > beta > rc > production release cycle.
• Merge and upgrade in-house bitcoin lib fork, with its own production release cycle.
• Upgrade in-house bitcoin-based backend and frontend (ideally coupled with b4’s release cycle).

The contrast in manpower, code change and internal software update cycles is readily apparent. In terms of production planning, SegWit makes work for many more teams beyond core. Miners, exchanges, explorers, wallets and more are much more sensitive to transaction format/signing changes than block size changes.

This is not a criticism of the features delivered — This is a key element of transition planning. For these overly optimistic “2M by April!” capacity claims to be met, that presumes a rush to upgrade all major sources of transactions. It is that rush to upgrade that introduces risk, not SegWit itself.

Issue #2: SegWit lacks predictable time line

There are no dates on the SegWit-first roadmap. The capacity delivered by SegWit depends on the pace of up-layer (exchange/miner/wallet/merchant) production upgrades, no matter how fast P2P nodes are upgraded. For any business making capacity planning decisions about current and future projects, SegWit stacks unknowns on top of unknowns. Capacity delivered is also impacted by the free rider problem.

Meanwhile, the economic problems and usability problems associated with a core 1M block size remain. Core block space continues to be much more heavily contended. SegWit functions as a temporary capacity relief valve — assuming the aforementioned rush to upgrade up-layer systems.

A hard rule of “SegWit must deliver X capacity before Y HF can be considered” implicitly subjects all future changes to an unknown timeline, or, implies the ecosystem should embark on a risky “fire drill” upgrade of up-layer, user-facing production systems. Neither the hard rule or the rushed upgrade are desirable. As such, it does not make sense to make SegWit a blocker for other network upgrades.

Issue #3: SegWit retains block size problems, while layering economic complexities on top

While not inherently wrong (or right), the SegWit split-block approach is under-analyzed from an economic perspective. It presents a basket of two goods with two different use rates.

Consider blocks as buckets of water. Today, we have one bucket, and water is (transactions are) pouring into the bucket. It is periodically emptied.

With SegWit, we have a new bucket. At first, almost all the water continues to pour into the first bucket. Over time, the users begin to balance their use between the two buckets. However, the first bucket continues to fill up at a much higher rate than the 2nd.

The logic behind this basket’s pricing is very thin — and again, it is a hazard to insert another point in the code where a developer is setting an arbitrary price ratio.

Issue #4: (Opinion/Philosophy) Changing economic policy as a soft fork

A soft fork is a much lower barrier to achieve, to upgrade the network. Ultimately a majority of mining pools need to upgrade to enforce a new ruleset. This has worked for new script features such as P2SH or CLTV.

This is much more hazardous when enlarging an economically-limited resource such as block size as SegWit does. It becomes much easier for devs or miners to reboot the fee market on short notice. It becomes much easier to make the soft-forked block size expansion limit a policy tool.

Hard forks set a higher bar for changing bitcoin’s economic policies — and that’s a good check-and-balance.

Issue #5: Safe hard fork parameters — activation percentage

It goes without saying that users and businesses that depend on bitcoin want a safe roll-out of any network upgrade.

For activation percentage, calls for 90+% start to become unreasonable from a game theory perspective: 95% implies that you only need to rent 5% of hashpower to sway the outcome, a decreasing cost barrier.

Issue #6: Safe hard fork parameters — time and grace period

A key benefit of a safe hard fork is predictability. Rather than delivering unknown amount of capacity at an unknown date in the future, setting a date for a 2M hard fork gives users, businesses, the market a hard date + capacity target for planning, testing, preparation. Capacity planning can proceed for internal projects that have yet to be green-lit publicly. The hard fork either happens, or it doesn’t, and everyone knows well in advance.

A too-short time period such as T+28 days pushes the risk curve at the low end: The first >1M block will eject too many still-useful nodes, that serve as a key check-and-balance validating miners in true trustless fashion.

A too-long time period such as 12 months — or never adjusting 1M! — pushes the risk curve at the high end: Businesses and users cannot afford to wait that long. Several businesses will simply not exist or pivot away from bitcoin in that timeframe.

Issue #7: Safe hard fork — rollout/rollback plan

Users need a guide for how they will transition through the network upgrade, and what are the contingencies.

The blockchain structure implies we have the ability to roll back to a specified point in time, should problems arise.

Issue #8: Bitcoin Core and Bitcoin Classic governance

It is great that there seems to be consensus on a 2M hard fork. That is great progress.

Of course, both Bitcoin Core and Bitcoin Classic governance leave a lot to be desired, if you are a looking at timescales in terms of months and years. After spending much of year 2015 (and earlier years) asking “How/when does the block size occur?”, Bitcoin Core in December seemed to abruptly depart from the entire question of how/when to hard fork. This wasted much time that, in hindsight, could have been used to plan and execute a safe hard fork.

Bitcoin Classic in part was a reaction to that unfocused, undated roadmap of capacity-sometime-fork-sometime-later-eventually. Yet Bitcoin Classic is a new effort, and spinning up a useful alternate team and finding its own governance structure takes time. Although there is a truckload of self-interested bias here, I do think alternate trees are healthy for the ecosystem in the long run. Heterogenous environments are healthier, more competitive than homogenous environments — even though open source and especially consensus systems have some incentives towards monocultures.

The model of IETF Working Groups is imperfect, but seems light years better than what we have today. That sort of structure could work to manage the pacing of key bitcoin consensus rule changes — although the users are of course the ultimate arbiter of whether or not their money remains free.

Recommendations on moving forward:

1. Pick a date for the 2M hard fork and communicate that date widely, testnet it, etc. — give users plenty of time to understand the implications and evaluate it on their own terms. 28 days seems to be the consensus for an “if we must” hard fork. In the context of a production upgrade cycle at a financial shop, 28 days is more like an emergency update than planned update. 3–6 months is a minimum in that context.
2. SegWit cannot be an artificial pre-requisite, blocking other upgrades. Avoid logic trap of “SegWit must come first, now rush to upgrade up-layer”
3. Organize an IETF-like working group, in public, with transparency, inclusive of all geographies.

We all need to work together towards shared goals of improving bitcoin.