Bitcoin Improvement Proposals (BIPs) are the fundamental documents used to propose enhancement to the Bitcoin protocol. Any proposal has to undergo a thorough review process before being added to the BIPs repository. The process, recently updated by maintainer Murchandamus, is described in BIP3 and anyone proposing a new feature, expansion, or standard must follow it. Moreover, more developers have been granted the role of BIP Editor, thus more BIPs are being evaluated, numbered, and published.
From now on, the Insider will cover all new BIPs being published and new proposals getting assigned a number. Since this is the first issue of this series, we will cover all the BIPs discussed during February.
Before starting, an important clarification is needed. A BIP being published does not mean that it has been added to Bitcoin Core, or that it has been adopted by a project. It just means that the BIP has been assigned a number and its PR merged because Editors have deemed it mature enough. The BIP will remain in Draft status until “authors have concluded all planned work on the proposal, and are confident that their BIP represents a net improvement, is clear, comprehensive, and is ready for adoption by the Bitcoin community”.
Published BIPs
A list of recently published BIPs
BIP360: Pay-To-Merkle-Root
Authors: Hunter Beast, Ethan Heilman, Isabel Foxen Duke
Publishing Date: February 11th, 2026
Layer: Consensus
BIP360 proposes a soft fork to create a new output type called Pay-To-Merkle-Root (P2MR). This new output aims to provide protection against long-exposure attacks by Cryptographically Relevant Quantum Computers (CRQCs) for outputs that support Tapscript and script trees.
This new output commits to the Merkle Root of a script tree and provides nearly most of the functionalities of P2TR outputs. However, it removes the quantum vulnerable key path spend, which exposes scripts of spent outputs which could be leveraged by a CRQC to derive the private key, through a process called quantum key recovery.
BIP110: Reduced Data Temporary Softfork
Authors: Dathon Ohm
Publishing Date: February 7th, 2026
Layer: Consensus
BIP110 is a proposed soft fork that aims to temporarily limit the size of data fields at the consensus level. To do so, it restores the previous 83-byte policy limit on OP_RETURN outputs.
BIP89: Chain Code Delegation
Authors: Jesse Posner, Jurvis Tan
Publishing Date: February 4th, 2026
Layer: Applications
BIP89 defines Chain Code Delegation (CCD), a method for multi-signature wallets to withhold BIP32 chain codes from non-privileged participants. In particular, it limits the visibility on extended XPUBs or descriptors to a multisig counterparty , allowing him to receive only the minimum data needed for signing. This methodology keeps policy enforcement feasible for a non-privileged signer, while preserving privacy for the main actor.
Numbered BIPs
A list of BIPs that recently got assigned a number
BIP392: Silent Payments Output Script Descriptor
Authors: Craig Raw
Assigned Date: February 6th, 2026
Layer: Applications
PR2047 introduces BIP392, which specifies a new output script descriptor for silent payments, sp() . The descriptor, proposed by the creator of Sparrow Wallet, provides a standardized way to represent silent payment outputs within the output descriptor framework, enabling wallet interoperability and recovery using existing descriptor-based infrastructure. Iin particular, the new descriptor takes silent payment key material and describes P2TR outputs when combined with the sender’s input public key, as defined in BIP352.
BIP446: OP_TEMPLATEHASH
Authors: Gregory Sanders, Antoine Poinsot, Steven Roose
Assigned Date: February 6th, 2026
Layer: Consensus
PR1974 introduces BIP446, which proposed a soft fork to activate a new operator for Tapscript, called OP_TEMPLATEHASH. The new opcode could be used to commit to the transaction spending an output, a capability that could replace the need for pre-signed transactions in second-layer protocols. This BIP is being proposed by Core contributors, Gregory Sanders and Antoine Poinsot, and Second CEO Steven Roose.
The PR also introduces another BIP, bundling together OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK, and OP_INTERNALKEY. However, this BIP has not been assigned a number yet.
BIP361: Post Quantum Migration and Legacy Signature Sunset
Authors: Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers
Assigned Date: February 11th, 2026
Layer: Consensus
PR1895 introduces BIP361, a proposed soft fork to implement a post-quantum output type and to provide a multi-phase plan to sunset legacy ECDSA/Schnorr signatures. According to the authors, the goal is to make upgrading to post-quantum outputs a matter of incentives, providing a clear timeline to align the entire ecosystem.
BIP376: Spending Silent Payment Outputs with PSBTs
Authors: Nymius
Assigned Date: February 5th, 2026
Layer: Applications
PR2089 introduces BIP376, which proposes adding new per-input fields in Partially Signed Bitcoin Transactions (PSBTs) v2, described in BIP370, to allow for silent payment outputs spending.
While BIP375 already specifies how to create outputs locked with silent payments in PSBTs, a specification on how to unlock them is still not available. The BIP, proposed by BDK contributor Nymius, closes this gap in the specifications.
BIP128: Timelock-Recovery Storage Format
Authors: Oren Z
Assigned Date: February 5th, 2026
Layer: Applications
PR2068 introduces BIP128, which specifies a standard format for storing timelock-recovery plans. The goal of this proposal is to allow users to simply importing these type of plans into services that provide automatic monitoring and execution.
