Reading · Christine D. Kim

Good morning,

Today, I’m discussing two network-wide upgrades, also called “forks,” scheduled for activation on Bitcoin over the next two months. Below, I explain what Bitcoin users can expect from both the eCash hard fork and the BIP-110 soft fork, which are expected to activate in August and September, respectively.

Regarding Bitcoin Core development, neither of these forks is expected to affect Core or the broader Bitcoin network, as the changes introduced by these upgrades lack broad community support. For additional updates on Core, refer to the linked posts at the bottom of today’s newsletter.

As a reminder to subscribers, the visibility of my posts has changed. Free subscribers will now receive full posts in their inboxes a few days after publication, while paid subscribers will get early access to my insights.

Let’s get into it.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

☀️ I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business understand and stay ahead of protocol changes:

Protocol Watch

Over the next two months, Bitcoin is expected to undergo two network-wide upgrades, also called “forks.”

Upgrades that restrict Bitcoin’s ruleset so that older versions of Bitcoin software can still validate new blocks are called “soft” forks, while upgrades that expand the protocol’s ruleset and introduce new functionalities that prior versions of Bitcoin software cannot support are called “hard” forks.

Between August and September, Bitcoin will undergo both a hard fork and a soft fork. However, due to the lack of broad consensus for the protocol changes introduced by either of these forks, it is unlikely that either will succeed in changing Bitcoin. Both network-wide upgrades will likely result in an extended chain split and two new competing versions of the Bitcoin protocol.

Earlier this year, a pseudonymous Bitcoin developer using the screen name “Dathan Ohm” published a fork of the Bitcoin Core client that would temporarily limit the size of data fields, such as OP_RETURN, to curb non-financial use cases on Bitcoin.

The client name is tagged on GitHub as UASF BIP-110, which stands for User-Activated Soft Fork Bitcoin Improvement Proposal-110.

BIP-110 is Ohm's proposal that defines the technical specifications for limiting Bitcoin’s data fields at the consensus level.

UASF describes the high-level process for activating BIP-110, with or without support from Bitcoin miners.

Up until block height 961,632, which is expected to be mined around August 7, miners can signal their readiness for BIP-110 activation by adjusting their Core node settings to adopt BIP-110 consensus rules or by running alternative client versions that already support BIP-110.

If 55% of miners collectively signal support for BIP-110 by early August, then the features of BIP-110 will automatically activate in the software of supporting miners about two weeks after this minimum threshold is reached.

If the 55% threshold is not reached by block height 961,632, then the miners that have signaled their support for BIP-110 will begin rejecting blocks from miners who have not signaled their support. Then, starting at block height 965,664, expected around September 1, miners supporting BIP-110 will begin enforcing the proposal’s new consensus rules.

As of writing, only 1% of Bitcoin miners have signaled support for Ohm’s soft fork.

Thus, the Bitcoin ecosystem is now preparing for roughly 1% of these miners to split off and form their own chain starting early next month.

As a chain with an estimated 1% of mining support, it’s unlikely that many exchanges or wallets will support this Bitcoin fork when it splits off next month. Thus, for most users, nothing will change. When the Ohm fork is created, BTC held in self-custodied Bitcoin Core wallets, as well as in most other cryptocurrency wallets and exchanges, will be unaffected.

However, for the minority of users who are self-custodying their BTC using customized software supporting the Ohm fork or are custodying their BTC on a platform that will support this fork, they will now see two versions of Bitcoin, one that rejects blocks over certain data limits and the other that continues to validate and build upon them.

The version of Bitcoin that rejects blocks according to BIP-110 consensus rules is unlikely to attract economic value or significance due to its lack of community support and tooling. However, for users who still wish to support this minority fork of Bitcoin and care about the BTC holdings they have replicated on it, there are a few important considerations to keep in mind as August approaches.

In addition to concerns about the security and network stability of the Ohm fork due to its lack of miner support, there is the concern that transactions users create on the Ohm fork may be replayed on Bitcoin, and vice versa.

While UASF BIP-110 will operate under more restrictive consensus rules for data storage than the Bitcoin protocol itself, it will uphold the same ruleset for transaction validity. Thus, transactions validated on the Ohm fork can be replayed and validated on Bitcoin, provided they do not violate the consensus rules for data storage on either chain.

This means Ohm-fork users should be careful when constructing transactions, so that transactions intended for only one chain can't be replayed on the other. This can be done by deliberately including a feature that the other chain's rules reject, such as an oversized OP_RETURN, or by referencing a block hash that exists only on one chain after the split — either way, making the transaction inherently invalid on the chain it wasn't meant for.

Alongside the Ohm soft fork in August, there will also be a hard fork of Bitcoin called the eCash hard fork.

Unlike UASF BIP-110, the eCash fork is not intended to restrict Bitcoin’s ruleset but rather to expand it to support new functionality, specifically drivechains.

Drivechains are a type of layered scaling solution for Bitcoin defined by Bitcoin Improvement Proposals (BIPs) 300 and 301 that seeks to enhance the protocol’s programmability and scalability. It was designed by Paul Sztorc, the creator of the first blockchain-based prediction market, Truthcoin, and the founder and CEO of Layer Two Labs.

After developing the idea of drivechains for over a decade, Sztorc has started a new project, eCash, which will spawn a new version of Bitcoin that activates BIPs 300 and 301, as well as the following code changes:

Blocksize Reduction - Reduce blocksize by 10x – ie, from 4 MB to 400 KB.
Difficulty Reset – A one-time “special difficulty adjustment” down to the minimum difficulty on the fork date.
Satoshi Half-Airdrop – Half of Satoshi’s “patoshi” coins (about 550k of 1.1 M) will be allocated to eCash investors and supporters.
Transaction Replay Control – ECash transactions will have an optional extra byte such that transaction IDs can be distinct from Bitcoin transactions, and thus, allow users to opt in/out of transaction replay
Network differentiation – Superficial changes to differentiate the eCash network from Bitcoin, e.g., the name, seed node IPs.

eCash is designed to be a hard fork of Bitcoin that will activate the above changes starting from block height 963,648, expected around August 21. (Technically, only the last four features of eCash listed above are backward-incompatible, that is, requiring a hard fork of Bitcoin. BIP 300, 301, and a blocksize reduction can be activated through a soft fork of Bitcoin.)

Unlike UASF BIP-110, the protocol will launch with its own separate ticker, ECX, and developer tooling from Bitcoin. (As a side note, there is another blockchain protocol with the same name as this project that is already listed on certain exchanges. Its ticker is XEC, and it is unrelated to Sztorc’s eCash project.)

The impact of the eCash hard fork on Bitcoin users is expected to be similar to that of the UASF BIP-110 soft fork, given the project’s limited support amongst Bitcoin developers, exchanges, and wallets.

Thus, for most users, nothing will change. When the eCash fork is created, BTC held in self-custodied Bitcoin Core wallets, as well as in most other cryptocurrency wallets and exchanges, will be unaffected.

However, for the minority of users interested in supporting eCash and concerned about the value of their replicated BTC holdings on this forked chain, there are fewer considerations to note than for Ohm fork supporters.

As a fork that will be differentiated from Bitcoin from the start, eCash has built-in replay protection for its users. Further, there are network adjustments to account for the drop in mining participation that will occur at the time of the fork, which are intended to help stabilize the network from its genesis.

In summary, the key dates and block heights for the Ohm soft fork and the eCash hard fork are:

Block height 961,632 (~August 7): Mandatory UASF BIP-110 miner signaling period kicks off, and signaling miners begin rejecting blocks from non-signaling miners
Block height 963,648 (~August 21): eCash hard fork activation
Block height 963,648 (~September 1): BIP-110 soft fork activation

Both forks lack broad support from key Bitcoin stakeholders, such as major exchanges, miners, developers, and end users, which is why the changes they introduce to Bitcoin are unlikely to meaningfully impact the Bitcoin protocol.

Instead, it is anticipated that both forks will result in competing variants of Bitcoin, which only a minority of users who support the modifications in these versions will observe.

The next major Bitcoin Core release, version 32, is 75% complete and tentatively scheduled for finalization by October 10, 2026. (GitHub)
Bitcoin Core version 31.1 is now finalized. This minor release features various bug fixes and performance improvements. (Bitcoin Developers Mailing List)
Transcript of last Thursday’s July 9 Bitcoin Core Developers meeting. (Chaincode)
After two years and 1,000 review comments, developers have merged and finalized PR #35295, validation: fetch block input prevouts in parallel during ConnectBlock. (More information about this PR can be found in BTC Before Light Issue #42.)
Summary of Bitcoin Core development activity from July 6 to July 12. (This Week in Bitcoin)
A call for feedback on a draft proposal that enables a group of Bitcoin signers to compress their individual signatures into a single, fixed-size signature, thereby reducing transaction size and cost, especially for privacy-friendly multi-input transactions like CoinJoins. (Bitcoin Developers Mailing List)
An implementation report on SuperScalar, a protocol that allows multiple separate Lightning wallets to share a single on-chain Bitcoin transaction. This reduces the cost of joining Lightning while ensuring no single party can move another participant's funds. (Delving Bitcoin)

🙏 Thank you for reading. If you liked today’s issue, consider sharing it with a friend who might also enjoy the content.

💥If today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by leaving a comment.

What to expect when Bitcoin forks next month

Comments