01 Sep What Soft Forks are Currently Being Debated in Bitcoin?

In Bitcoin, a “soft fork” is a change to the protocol that is backward-compatible with older versions of the Bitcoin software. Today, we’ll take a look at some of the current soft fork proposals being discussed and debated within the Bitcoin community.

What is a Soft Fork in Bitcoin and Why Does it Matter?

In the Bitcoin network, a soft fork serves as an upgrade that is compatible with earlier versions of the protocol. This ensures that nodes operating on older software can still confirm transactions and blocks produced by nodes using the updated software, although they won’t be able to take advantage of new features. 

The approval and implementation of such soft forks is an intricate procedure that requires several steps and involves a diverse group of participants from the Bitcoin community. Soft forks must achieve an overwhelming consensus within the community to be implemented into the Bitcoin mainnet. Soft forks can be activated in various ways, but typically the process involves:

1. A proposal or BIP (Bitcoin Improvement Proposal) for the desired soft fork, explaining what it is, why it is needed, and how it works.
   
2. A period of peer review where Bitcoin developers and community members debate the pros and cons of the potential changes, and the trade-offs or consequences of the soft fork. This debate period could last years before reaching a conclusion.
   
3. A code implementation on testnet and a developer review of the code where it is rigorously reviewed for bugs, security vulnerabilities, and other issues.
   
4. Signalling and Activation, this could be things like miner signalling and node adoption, upon which the soft fork may activate at a certain block height, or it may use a more complex system like BIP 9‘s version bits to allow for coordinated activation.
   
5. Enforcement is the final stage, once the soft fork is activated, miners start enforcing the new rules. Transactions or blocks not following the new rules are rejected.

Soft forks allow Bitcoin to introduce new features or improve existing ones without forcing everyone in the network to upgrade their software. However, for a soft fork to be successful, it usually requires broad community support, especially from miners and node operators.

Some examples of soft forks in Bitcoin’s history include the activation of Segregated Witness (SegWit) and the implementation of BIP 66, which dealt with signature validation, as well as the recent Taproot activation. All of these changes aimed to improve the Bitcoin protocol without disrupting the existing ecosystem.

A Look at Current Soft Fork Proposals

BIP 300 & 301 – Drivechain

BIP 300 and BIP 301 are Bitcoin Improvement Proposals associated with the concept of Drivechains, a type of sidechain for Bitcoin. The concept was developed primarily by Paul Sztorc. Sidechains are alternative chains where Bitcoin can be moved and then returned to the main chain. The idea is to enable new features, scaling solutions, or other types of experimentation without affecting the main Bitcoin blockchain.

BIP 300 (Hashrate Escrows)

Under the  drivechain proposal, miners validate the blocks of the sidechain as well as the main chain. BIP 300 proposes a mechanism for hashrate escrows, a way to lock up Bitcoin as a form of assurance or collateral. Miners would, in effect, have skin in the game to honestly validate the sidechain, as misbehaviour would lead to financial penalties.

BIP 301 (Blind Merged Mining)

Blind merged mining is proposed as a mechanism for miners to validate sidechain blocks without requiring them to run a full node for every sidechain. This would make it more feasible for miners to support multiple sidechains without significant overhead.

Drivechains

A drivechain is a specific kind of sidechain that allows Bitcoin to be transferred from the main Bitcoin blockchain to a completely separate blockchain and then back. The sidechain can have its own rules, block size, and methods of operation. For instance, one could create a sidechain that has faster block times, improved privacy, or that supports more complex smart contracts than Bitcoin does.

One of the major challenges with any type of sidechain, including drivechains, is ensuring the security of the funds that move to the sidechain. In the drivechain concept, this is achieved by using the mining power of the Bitcoin network itself to secure the sidechain. This is where blind merged mining and hashrate escrows come into play: they provide the mechanisms by which miners can be incentivized to secure a sidechain honestly.

Drivechains aim to offer a “best of both worlds” solution, where the stability and security of the Bitcoin network can be leveraged to safely experiment with new features and capabilities without risking the main chain. However, like all such proposals, drivechains have been the subject of much debate within the Bitcoin community.

OP_CHECKTEMPLATEVERIFY (CTV) and SIGHASH_NOINPUT/ANYPREVOUT (APO)

Both OP_CHECKTEMPLATEVERIFY and SIGHASH_NOINPUT/ANYPREVOUT are BIPs aimed at expanding Bitcoin’s scripting capabilities, making transactions more flexible, and potentially opening doors to new Layer 2 solutions. Let’s take a look at both.

OP_CHECKTEMPLATEVERIFY (BIP 119)

OP_CHECKTEMPLATEVERIFY (formerly known as OP_SECURETHEBAG) is a Bitcoin script opcode proposed in BIP 119. An “opcode” is essentially a function in the Bitcoin script language. This specific opcode aims to make it easier to create covenants, a type of smart contract in Bitcoin where the spending conditions on the transaction outputs are restricted in some manner.

OP_CHECKTEMPLATEVERIFY enables an output to specify the template for how its funds should be spent in the next transaction. This creates a covenant, limiting how the funds can be spent but not requiring the full transaction details to be known ahead of time. For example, you could specify that an output can only be spent in a transaction that also pays a certain amount to a specific address (perhaps a fee or a donation).

Why Should it be Added to Bitcoin?

• Predictable Transactions: Participants can have strong assurances about how funds will be used in the future.

• Layer 2 Solutions: It opens doors for novel layer 2 protocols, potentially making Bitcoin more scalable. For example, the proposed ARK Bitcoin Layer Two protocol, would benefit from OP_CHECKTEMPLATEVERIFY and covenants.

• Improved Usability: By allowing more complex contracts, it could make Decentralised Finance (DeFi) solutions more practical on Bitcoin.

• Simplified Vault Designs: Allows for more straightforward designs for security vaults, increasing the security of large Bitcoin holdings.

SIGHASH_NOINPUT / SIGHASH_ANYPREVOUT (BIP 118)

These are proposed new signature hash types that would make it easier to create certain types of flexible transactions. Specifically, BIP 118 proposes the SIGHASH_NOINPUT and its updated form SIGHASH_ANYPREVOUT.

In a standard Bitcoin transaction, the input you are spending explicitly refers to a specific previous transaction’s output (by its txid and output index). SIGHASH_NOINPUT and SIGHASH_ANYPREVOUT would allow you to create a signature that is valid for any transaction with a matching scriptPubKey (i.e., the same receiving address), regardless of the txid or output index.

Why are They Desirable for Bitcoin?

• Simplified Layer 2 Protocols: Like the Lightning Network, these signature types could simplify protocol design and reduce the amount of data that needs to be stored.

• Transaction “Fixing”: If a transaction gets stuck due to low fees, another transaction could be easily created to “bump” the fee without requiring new signatures.

• Improved Smart Contracts: They allow for more dynamic use of Bitcoin in smart contracts, as a transaction can be constructed without knowing exactly which UTXO will be spent.

• Optimizations for Multi-Signature Wallets: By making the signature not dependent on the input being spent, you could potentially streamline multi-signature operations.

Potential Drawbacks

While these features could add powerful new capabilities, they also come with risks. For example, SIGHASH_NOINPUT/ANYPREVOUT could inadvertently lead to the double-spending of coins if not carefully managed. The Bitcoin community is currently still debating the risk vs. reward factor for making these changes to the Bitcoin protocol. 

Recent Soft Fork Proposals in Bitcoin

There are also several recent features or improvements that have been put forth as proposed soft forks either recently implemented or proposed for implementation in the near future, depending on the community consensus surrounding Bitcoin’s potential upgrade path. The following proposals are by no means an exhaustive list and simply reflect some of the most recent proposals.

Taproot: A proposal to improve Bitcoin’s scripting capabilities and increase privacy. Taproot was successfully activated in 2021.

Schnorr Signatures: Sometimes discussed in conjunction with Taproot, Schnorr signatures aim to improve the efficiency and privacy of multi-signature transactions. These were also bundled into the Taproot upgrade.

MAST (Merkelized Abstract Syntax Trees): A proposal to improve the efficiency and privacy of complex smart contracts on the Bitcoin network. MAST is sometimes discussed as a future upgrade which could add versatility to Bitcoin transactions.

OP_CHECKTEMPLATEVERIFY: A proposal described above, aimed at improving Bitcoin’s capabilities for certain types of smart contracts and on-chain covenants.

SIGHASH_NOINPUT / ANYPREVOUT: These proposals are outlined above and are aimed at enabling a more flexible form of transaction signing that can be used to improve Layer 2 protocols like the Lightning Network.