Soft Fork: How Bitcoin Upgrades Its Rules

At block 709,632 in 2021, Bitcoin activated Taproot, introducing new spending rules. The old nodes do not fully understand these new rules, but can still continue to follow the chain. Bitcoin had changed without requiring every participant to install the same update.

This is why a soft fork can be useful, but can also be an easy thing to overlook. Software can accept a block without checking every new condition inside it.

When reading the technical documentation to create this Coinminutes guide, I always came back to this point. This shows how Bitcoin can introduce new features, but also shows that compatibility does not always ensure a smooth upgrade.

Soft Fork Fundamentals: Stricter Rules and Backward Compatibility

The word “fork” suggests two diverging paths. In Bitcoin, however, it can also describe a change to consensus rules.

Soft Fork Meaning in Plain English

A soft fork is an update to the consensus rules of the blockchain that makes the set of valid blocks smaller. Every block valid under the new rules is also valid under the old rules. Once the soft fork activates, however, some blocks that the old rules would accept are rejected under the new rules.

A soft fork tightens blockchain consensus rules so that new valid blocks still satisfy the old rules.

This can be thought of like adding a new security check to the entrance of a building. Everyone who passes the new check will still pass through the original door. However, the original door will not know if they have passed the extra check.

This is why a soft fork is a one-way relationship. Older nodes can accept the upgraded chain, although they cannot independently enforce rules their software does not know.

The Blockchain Terms You Need First

The following terms make the rest easier:

• Block: A collection of transactions bound to the previous block.

• Consensus rules: Conditions that determine if transactions and blocks are valid.

• Full node: Software that independently enforces the rules to check blocks.

• Miner: A participant that uses their computing power to compete to create blocks.

• BIP: A Bitcoin Improvement Proposal that outlines a proposed change to the technology. Just because a BIP is published does not mean it will become a rule on the network.

• Wallet: Manages keys and builds payments. Some wallets will interact with your own full node while others will use external infrastructure. Therefore, just because you have a wallet does not mean you are personally enforcing the consensus rules.

Why Would a Blockchain Need a Soft Fork?

Bitcoin needs to protect existing funds and allow for improvements to the software. An upgrade may strengthen validation, improve transaction efficiency, or introduce new ways to authorize spending.

Bitcoin upgrades aim to improve validation, transaction efficiency, and spending authorization while protecting existing funds.

BIP66, for example, standardized the encoding of certain transaction signatures, reducing reliance on the behavior of an external software library. Other upgrades introduced capabilities visible to wallet users.

Updating your software does not necessarily involve a soft fork. If you are updating your software to make the interface faster or the database more efficient, the consensus rules are not changed. A fork concerns the rules defining acceptable blockchain history.

How Does a Soft Fork Work? From New Rules to Activation

Although there seems to be a contradiction, there are new possibilities when using stricter rules. The explanation lies in how old software interprets the transaction structures receiving those rules.

How Stricter Rules Can Enable New Features

An upgrade can give an existing script instruction a stricter meaning. BIP65 (CHECKLOCKTIMEVERIFY) made use of an existing command that the old software would ignore. This meant it could enforce a time-based spending rule.

The old software still accepts the transactions that pass the new check as the instruction did not break its existing rules. However, the upgraded software can now reject any attempts to spend that do not pass the new condition.

This provides an enforceable limitation for users. This can be useful for time-based payment systems. The network also gains a capability precisely due to the upgraded participants rejecting more situations. Feature expansion and stricter validation can happen together.

What Old Nodes Accept and Upgraded Nodes Verify

Once the soft fork has been activated, the upgraded nodes will reject any blocks that do not satisfy the new conditions. The old nodes will not perform this check and may accept the same blocks.

After a soft fork activates, upgraded and older nodes can follow the same chain, but only upgraded nodes enforce the additional rules.

If the soft fork has been successfully implemented, both older and upgraded nodes can follow the same chain as the blocks will pass both sets of rules. While they agree on the outcome, there is a difference in what they have actually enforced.

Consensus is separate from transaction relay policy. A node’s policy determines which unconfirmed transactions it accepts into its waiting area, the mempool, and relays to peers. These local restrictions are not applied when validating transactions already inside blocks. Changing relay policy alone does not constitute a soft fork.

How Miner Signaling, Lock-In, and Activation Differ

A proposal needs to be put in place to dictate when the upgraded software will enforce the new rules. BIP9 outlines how this can be done using signals within the block headers. Three stages matter:

• Signaling: Miners mark blocks to show they are ready to follow the rules.

• Lock-in: The threshold has been met. This means the deployment is locked in for activation.

• Activation: The upgraded nodes will enforce the new consensus rules.

These stages need not happen together. For example, Taproot had a ‘Speedy Trial’ deployment. This required at least 1,815 of the 2,016 blocks in a qualifying period to be signaled (approximately 90%). The enforcement did not happen until block height 709,632.

Thresholds and schedules vary between deployments. A signaling percentage measures qualifying blocks, not a poll of individual Bitcoin owners, and a signal cannot prove that mining software actually performs the promised checks.

Who Decides? Developers, Miners, and Node Operators

Developers will propose changes, review designs and release implementations. Miners will decide how to build blocks and will participate in signaling if required. Node operators will decide what software to use to determine what blocks are accepted. Businesses and wallet providers will decide to adopt.

Bitcoin upgrades involve developers, miners, node operators, and businesses and wallet providers.

There is a lot of interaction between the different roles but no one role will have the ‘admin password’. No amount of computing power will make an enforcing node accept a block that does not pass the rules. However, just having lots of nodes will not create a one-node-one-vote parliament.

The 2017 BIP148 user-activated soft fork illustrates a different coordination approach: participating nodes required SegWit signaling from a specified date under the proposal’s conditions. It was an activation strategy, distinct from the SegWit spending rules themselves.

Soft Fork vs. Hard Fork: The Differences That Matter

It can be helpful to compare what is accepted under each rule set. It is not helpful to say one upgrade is small and one is large.

Backward Compatibility, Rule Changes, and Upgrade Requirements

A hard fork makes at least some blocks valid that older rules reject. Older validating nodes therefore cannot follow those blocks without changing their rules.

Comparisons between soft fork and hard fork.

These differences describe compatibility, not the size or importance of an upgrade.

For Coinminutes readers, the practical question is which rules their software verifies. “Backward compatible” describes a technical relationship; it does not promise identical protection from every software version.

Does a Fork Always Create a New Coin?

Not necessarily. P2SH, SegWit and Taproot have all been implemented without creating new currencies. Just because there is a planned rule change does not automatically mean there will be a second marketable asset.

A permanent split can occur if there are incompatible chains and participants support each chain. However, even with a hard fork, there may not be two lasting currencies if there is coordination on the network. Temporary forks may also not create new assets.

Just because there is a fork does not mean there will be a new coin.

Bitcoin Soft Fork Examples: P2SH, SegWit, and Taproot

These 3 upgrades show different ways the same compatibility can be used. It can be helpful to think about what each upgrade was trying to improve.

P2SH: Making Complex Spending Conditions Easier to Fund

Introduced in 2012 through BIP16, P2SH shifted responsibility for supplying detailed spending conditions from the sender to the eventual spender. The sender could fund a compact hash representing those conditions.

P2SH lets senders fund a hash of spending conditions that the eventual spender must reveal and satisfy.

If a business requires 2 out of 3 authorized people to agree to a payment, its customer should not have to assemble that approval arrangement just to pay an invoice. P2SH means the customer can send to a short destination. The business will provide the script and will meet the conditions.

A key point I noticed with BIP16 was that the sender could have an easier time while the recipient still had conditions to meet. The technical change meant the sender did not have to do as much.

SegWit: Witness Data and Transaction Design

Segregated Witness (SegWit) introduced a new structure for witness data. This includes signatures to authorize spending. This data is still used to validate the blockchain.

SegWit separates witness data, including spending signatures, into a distinct structure while keeping it part of blockchain validation.

The redesign addressed unwanted changes to transaction identifiers for appropriately constructed transactions, known as transaction malleability. This made chains of transactions depending on one another more reliable, supporting designs such as Lightning payment channels.

SegWit also introduced a limit to the block weight of 4 million weight units. This does not mean there will be 4 million normal bytes of arbitrary transaction data. It also does not guarantee low fees during high demand.

When Bitcoin Core released their September 2017 announcement, they stated SegWit was active. However, they also said that wider support for wallets would come. This is a useful reminder that a feature can be active under consensus but not convenient to use in software.

Taproot: More Flexible Spending and Selective Disclosure

Taproot was activated in 2021. This introduced spending rules associated with Schnorr signatures. This also meant there was more selective disclosure.

A Taproot output can be spent using a key path (valid signature) or a script path (specific spending condition and proof that it belongs to the committed setup). Unused alternatives can remain undisclosed.

Taproot enables spending through a signature-based key path or a script path that reveals only the chosen spending condition and its proof, leaving unused alternatives undisclosed.

If participants are working together, they may agree to use the key path to settle. This can help with privacy and efficiency for suitable setups.

However, there are limitations. Taproot does not hide the transaction amounts or make all payments anonymous. Its privacy benefits depend on how transactions are constructed and used. The upgrade provides capabilities; wallet design and user behavior determine how much of that potential becomes practical.

Soft Fork Benefits, Risks, and What They Mean for You

How the upgrade is named is not as important as how it is enforced and what software is being used. The most useful thing to consider is what benefits each upgrade provides and under what conditions.

What Are the Main Benefits of a Soft Fork?

Backward compatibility means new consensus features can be introduced without everyone having to upgrade their software. Users can gradually adopt supported spending formats while keeping the existing transaction history.

Backward compatibility lets a network introduce new consensus features and users adopt supported spending formats gradually while preserving transaction history.

Depending on the upgrade, there can be many benefits. These can include easier funding, better transaction design, tighter validation or more selective disclosure. “Soft fork” refers to how it is implemented.

For a Coinminutes assessment, I would separate three questions: what the rules enable, which software supports it, and whether the improvement helps a particular user. Activation answers only part of that inquiry.

Can a Soft Fork Cause a Chain Split or Other Risks?

Yes. Just because it is compatible does not mean there will not be disputes, bugs in implementation or miners building on blocks that have not been properly validated.

During the enforcement of BIP66 in July 2015, some miners built on an invalid block despite having signaled readiness. Bitcoin.org documented there was a six-block invalid chain. They also warned that affected software could show unreliable confirmations.

This shows me that the main issue is there is a difference between signaling and validation. Just because they have signaled does not mean they will run reliably.

This shows why it is important to coordinate the deployment. An older node may follow a branch violating rules it cannot check, while upgraded nodes reject it. While this may not create a new currency it can cause issues with confidence in payments.

Does a Soft Fork Change Your Coins or Create Free Tokens?

The Bitcoin soft forks discussed here did not require holders to exchange their BTC for a replacement coin. They changed validation or spending rules while preserving existing holdings.

These Bitcoin upgrades changed validation or spending capabilities while preserving the existing ledger.

Using a new output type may require a normal transaction, but holding existing coins does not itself require moving them. A soft fork also creates no automatic entitlement to free tokens.

An offer to “activate” upgraded coins by entering a seed phrase into a website is no part of these consensus mechanisms. Your recovery phrase controls wallet access; it is not an upgrade registration code.

Do You Need to Update Your Wallet or Full Node?

Check if your wallet supports the address formats and spending features you want to use. Just because it has been activated on the network does not mean all applications will have these features.

Use software that enforces the rules you want to validate independently. Continuing to recognize the chain with older software leaves the new conditions unchecked. The Taproot release notes from Bitcoin Core recommended upgrading before activation.

If you have a custodial account, the provider will be managing the relevant infrastructure. Check what upgrades they have and what deposit formats they support. You will not be able to tell what consensus checks are being performed from the account interface.

Final Thoughts on Soft Fork

Upgrading Bitcoin is a challenging task. You want to improve a shared system, but people are using it. There is no central switch to upgrade everyone’s machines.

A soft fork addresses that problem through a careful overlap between old and new rules. It relies on people implementing the specifications.

The key thing to note is that the older node still follows along. It sees continuity. An upgraded node sees continuity with extra conditions and does the extra work to check them.