What soft forks are currently being discussed in Bitcoin?

September 01 What soft forks are currently being discussed in Bitcoin?

In Bitcoin, a “soft fork” is a change in the protocol that is backward compatible with Bitcoin software. Today, we will 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 is it important?

In the Bitcoin network, a soft fork acts as a backward compatible upgrade of the protocol. This ensures that nodes running on older software are still able to confirm transactions and blocks produced by nodes using the updated software, even though they will not be able to take advantage of the new features.

Approving and implementing such soft forks is a complex procedure that requires several steps and involves a variety of participants from the Bitcoin community. Soft forks must achieve overwhelming consensus within the community to be implemented in the Bitcoin mainnet. A soft fork can be activated in several ways, but the process usually 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 during which Bitcoin developers and community members discuss the pros and cons of potential changes, and the trade-offs or consequences of a soft fork. This period of discussion may continue for years before a conclusion is reached.
3. Executing code on the testnet and developer reviewing the code where it is thoroughly reviewed for bugs, vulnerabilities, and other issues.
4. Signaling and Activation These could be things like mining signals and node approval, through which the soft fork might be activated at a certain block height, or they might use a more complex system like BIP 9 release bits to allow coordinated activation.
5. Implementation is the final stage, once the soft fork is activated, miners start implementing the new rules. Transactions or blocks that do not follow 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 typically requires widespread support from the community, especially from miners and node operators.

Some examples of soft forks in Bitcoin history include the activation of Segregated Witness (SegWit) and the implementation of BIP 66, which handles signature verification, as well as the recent activation of Taproot. All of these changes are aimed at improving the Bitcoin protocol without harming the existing ecosystem.

A look at current soft fork proposals

BIP 300 and 301 – Chain of Command

BIP 300 and BIP 301 are Bitcoin improvement proposals linked to the concept of Drivechains, a type of Bitcoin sidechain. This concept was developed primarily by Paul Stork. Sidechains are alternative chains where bitcoins can be transferred and then returned to the main chain. The idea is to enable new features, scaling solutions, or other types of experiments without impacting the main Bitcoin blockchain.

BIP 300 (Retail Accounts)

Under the chain of command proposal, miners validate the sidechain blocks in addition to the main chain. BIP 300 proposes a mechanism for hash accounts, a way of locking up Bitcoin as a form of collateral or security. In fact, miners will have a role in the game to honestly validate the sidechain, as misconduct could result in financial penalties.

BIP 301 (Blind Integrated Mining)

Embedded blind mining is proposed as a mechanism for miners to validate sidechain blocks without having to run a full node for each sidechain. This would make it easier for miners to support multiple sidechains without incurring significant costs.

Drive chains

A lead chain is a specific type of sidechain that allows Bitcoin to be transferred from the main Bitcoin blockchain to a completely separate blockchain and back again. The sidechain can have its own rules, block size, and operating methods. For example, one could create a sidechain that has faster block times, improved privacy, or supports smart contracts that are more complex than those supported by Bitcoin.

One of the main challenges facing any type of sidechain, including lead chains, is ensuring the security of funds moving to the sidechain. In the chain of command concept, this is achieved by using the mining power of the Bitcoin network itself to secure the side chain. This is where embedded blind mining and hash guarantees come into play: they provide mechanisms by which miners can be incentivized to secure a sidechain honestly.

Drivechains aims 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, chains of command 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 intended to expand 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 OP_SECURETHEBAG) is the Bitcoin script opcode proposed in BIP 119. The “opcode” is essentially a function in the Bitcoin script language. This specific opcode is intended to facilitate the creation of covenants, a type of smart contract in Bitcoin where the terms of spending on the outcome of a transaction are restricted in some way.

OP_CHECKTEMPLATEVERIFY allows an output to define the template for how to spend its money in the next transaction. This creates a covenant, which limits how the money can be spent but does not require knowing the full transaction details beforehand. For example, you can 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?

• Predicted Transactions: Participants can get solid assurances about how the funds will be used in the future.

• Layer 2 Solutions: Opens the doors to new Layer 2 protocols, which could make Bitcoin more scalable. For example, the proposed ARK Bitcoin Layer Two protocol would take advantage of OP_CHECKTEMPLATEVERIFY and conventions.

• Improved usability: By allowing more complex contracts, it could make decentralized finance (DeFi) solutions more practical on Bitcoin.

• Simplified Vault Designs: Allows for clearer security vault designs, 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 SIGHASH_NOINPUT and its updated model SIGHASH_ANYPREVOUT.

In a standard Bitcoin transaction, the input you spend explicitly refers to the output of a specific previous transaction (through the txid pointer and the output pointer). SIGHASH_NOINPUT and SIGHASH_ANYPREVOUT will allow you to generate a valid signature for any transaction with the matching scriptPubKey (i.e. the same receiving address), regardless of the txid or output index.

Why are Bitcoin desirable?

• Simplified Layer 2 Protocols: Like Accelerator Network, these signature types can simplify protocol design and reduce the amount of data that must be stored.

• “Fix” the transaction: If a transaction stops due to a low fee, another transaction can easily be created to “raise” the fee without requiring new signatures.

• Improved Smart Contracts: Allows for a more dynamic use of Bitcoin in smart contracts, where a transaction can be created without knowing exactly what UTXO will be spent.

• Improvements for multi-signature wallets: By making signing not dependent on the input being spent, you can simplify multi-signature processes.

Possible defects

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

Recent Soft Fork Proposals in Bitcoin

There are also several recent features or improvements that have been rolled out as proposed soft forks that have recently been implemented or are 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, but simply reflect some of the most recent proposals.

Taproot: Proposed 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 are intended to improve the efficiency and privacy of multi-signature transactions. Also bundled in 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 that could add diversity to Bitcoin transactions.

OP_CHECKTEMPLATEVERIFY: The proposal described above, aims to improve Bitcoin's capabilities for certain types of smart contracts and on-chain agreements.

SIGHASH_NOINPUT / ANYPREVOUT: These proposals are described above and aim to enable a more flexible model of transaction signing which can be used to improve Layer 2 protocols such as Accelerator Network.