September 1st What soft fork is currently being discussed in Bitcoin?
education
In Bitcoin, a “soft fork” is a change in the protocol that makes it compatible with previous versions of Bitcoin software. Today we will take a look at some of the current soft fork proposals that are being discussed and debated within the Bitcoin community.
What is a Bitcoin soft fork and why is it important?
In the Bitcoin network, a soft fork serves as a compatible upgrade from previous versions of the protocol. This allows nodes operating on older software to continue to verify transactions and blocks produced by nodes using the updated software, even if they cannot take advantage of the new features.
The approval and implementation of such a soft fork is a complex process that requires multiple steps and involves a diverse group of participants in the Bitcoin community. A soft fork must achieve overwhelming consensus within the community to be implemented on the Bitcoin mainnet. A soft fork can be activated in a variety of ways, but the process typically involves:
- A proposal for a desired soft fork, or a Bitcoin Improvement Proposal (BIP) that explains what it is, why it is needed, and how it works.
- A peer review period during which Bitcoin developers and community members discuss the pros and cons of potential changes and the pros and cons or consequences of a soft fork. This period of discussion may last for years before a conclusion is reached.
- A developer review of the code, which rigorously reviews the code implementation on the testnet and the code for bugs, security vulnerabilities, and other issues.
- Signaling and activation, this could be something like a miner signal and node adoption where a soft fork can be activated at a certain block height, or it could be using a more complex system like version bits in BIP 9 to allow for coordinated activation.
- Enforcement is the final step, once the soft fork is activated miners will begin enforcing the new rules. Transactions or blocks that do not follow the new rules will be rejected.
Soft forks allow Bitcoin to introduce new features or improve existing features without forcing everyone on 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.
Examples of soft forks in Bitcoin history include enabling Segregated Witness (SegWit), implementing BIP 66 to handle signature verification, and recently enabling Taproot. All of these changes were aimed at improving the Bitcoin protocol without disrupting the existing ecosystem.
Explore current soft fork proposals
BIP 300 & 301 – Drive Chain
BIP 300 and BIP 301 are Bitcoin improvement proposals related to the concept of Drivechain, a type of Bitcoin sidechain. This concept was mainly developed by: Paul Stork. A sidechain is an alternative chain that allows you to move bitcoins and then return them to the main chain. The idea is to enable new features, solution extensions, or other types of experiments without affecting the main Bitcoin blockchain.
BIP 300 (Hashrate Escrow)
Under the DriveChain proposal, miners verify blocks on the sidechain as well as the main chain. BIP 300 proposes a hashrate escrow mechanism, a way to lock up Bitcoin in the form of a guarantee or collateral. Since misbehavior can lead to financial penalties, miners effectively have the power to honestly verify sidechains in the game.
BIP 301 (Blind Merge Mining)
Blind merge mining has been proposed as a mechanism to allow miners to verify sidechain blocks without having to run a full node for every sidechain. This will allow miners to support multiple sidechains without significant overhead.
drive chain
Drivechain is a specific type of sidechain that allows Bitcoin to be transferred from the main Bitcoin blockchain to a completely separate blockchain and then back again. Sidechains can have their own rules, block sizes, and methods of operation. For example, you could create a sidechain that has faster block times, improved privacy, or supports more complex smart contracts than Bitcoin.
One of the key challenges for any type of sidechain, including Drivechain, is ensuring the security of funds moving into the sidechain. The Drivechain concept achieves this by using the mining power of the Bitcoin network itself to secure sidechains. This is where blind merge mining and hashrate escrow come into play. This provides a mechanism for miners to be incentivized to secure sidechains honestly.
DriveChain aims to provide a “best of both worlds” solution that leverages the stability and security of the Bitcoin network to safely experiment with new features without putting the main chain at risk. However, like all these proposals, DriveChain has been the subject of much debate within the Bitcoin community.
OP_CHECKTEMPLATEVERIFY (CTV) and SIGHASH_NOINPUT/ANYPREVOUT (APO)
OP_CHECKTEMPLATEVERIFY and SIGHASH_NOINPUT/ANYPREVOUT are both BIPs that aim to extend Bitcoin’s scripting capabilities, make transactions more flexible, and potentially open the door to new layer 2 solutions. Let’s look at both.
OP_CHECKTEMPLATEVERIFY (BIP 119)
OP_CHECKTEMPLATEVERIFY (formerly OP_SECURETHEBAG) is a Bitcoin script opcode proposed in BIP 119. “opcode” is essentially a function in the Bitcoin script language. This particular opcode aims to make it easier to create commitments, a type of smart contract in Bitcoin where the spending terms for transaction outputs are limited in some way.
OP_CHECKTEMPLATEVERIFY’s output allows you to specify a template for how funds should be used in the next transaction. This forms a commitment, limiting how the funds can be used, but does not require you to know the full transaction details in advance. For example, you can specify that output can only be consumed by transactions that pay a certain amount (such as a fee or donation) to a certain address.
Why should it be added to Bitcoin?
- Predictable Transactions: Participants can have strong certainty about how their funds will be used in the future.
- Layer 2 Solutions: Opens the door for new layer 2 protocols, potentially further improving Bitcoin’s scalability. For example, the proposed ARK Bitcoin Layer 2 protocol could benefit from OP_CHECKTEMPLATEVERIFY and commitments.
- Improved usability: Allowing for more complex contracts makes decentralized finance (DeFi) solutions on Bitcoin more viable.
- Simplified Vault Design: Secure vaults can be designed more simply, increasing the security of large Bitcoin holdings.
SIGHASH_NOINPUT / SIGHASH_ANYPREVOUT (BIP 118)
This is a new signature hash type proposed to make it easier to create certain types of flexible transactions. In particular, BIP 118 proposes SIGHASH_NOINPUT and an updated form, SIGHASH_ANYPREVOUT.
In a standard Bitcoin transaction, the input to spend explicitly references the output (by txid and output index) of a specific previous transaction. SIGHASH_NOINPUT and SIGHASH_ANYPREVOUT allow you to generate a valid signature for all transactions with a matching scriptPubKey (i.e. the same receiving address), regardless of txid or output index.
Why is this desirable for Bitcoin?
- Simplified Layer 2 Protocols: Similar to the Lightning Network, these signature types can simplify protocol design and reduce the amount of data that needs to be stored.
- “Modify” a transaction: If a transaction is aborted due to a low fee, another transaction can easily be created to “crash” the fee without requiring a new signature.
- Improved smart contracts: Bitcoin can be used more dynamically in smart contracts, as transactions can be constructed without knowing exactly which UTXOs will be used.
- Optimize multi-signature wallets: Potentially simplify multi-signature operations by ensuring that signatures do not depend on the input being consumed.
potential drawbacks
These features can add powerful new capabilities, but they also come with risks. For example, if you don’t manage SIGHASH_NOINPUT/ANYPREVOUT carefully, you may inadvertently end up double spending your coins. The Bitcoin community is currently still debating the risks and rewards of making these changes to the Bitcoin protocol.
Recent Bitcoin Soft Fork Proposals
There are also several recent features or improvements presented as soft forks that have recently been implemented or are proposed to be implemented in the near future, following community consensus surrounding Bitcoin’s potential upgrade path. The following suggestions are by no means an exhaustive list and simply reflect some of the most recent suggestions.
Taproot: A proposal to improve Bitcoin’s scripting capabilities and enhance privacy. Taproot has been successfully activated in 2021.
Schnorr Signatures: Sometimes discussed alongside Taproot, Schnorr Signatures aim to improve the efficiency and privacy of multi-signature transactions. This was also bundled with the Taproot upgrade.
Merkelized Abstract Syntax Trees (MAST): 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 versatility to Bitcoin transactions.
OP_CHECKTEMPLATEVERIFY: The proposal described above that aims to improve Bitcoin’s functionality for certain types of smart contracts and on-chain contracts.
SIGHASH_NOINPUT / ANYPREVOUT: These proposals are described above and aim to enable a more flexible form of transaction signing that can be used to improve layer 2 protocols such as the Lightning Network.