The integrity of Bitcoin transaction processing has come under renewed scrutiny following the discovery of two critical vulnerabilities within the widely utilized bitcoinjs-lib library. This software library, a cornerstone for developers building Bitcoin-centric applications, recently issued emergency patches to address flaws that could allow valid transactions to bypass essential safety checks, potentially resulting in the unintentional loss of massive amounts of capital through inflated miner fees. The security disclosures, released on October 26, highlight a significant risk for any application that relies on the library’s internal fee calculation or its safeguard mechanisms designed to prevent excessive fee payments.

The vulnerabilities primarily affect the processing of Partially Signed Bitcoin Transactions (PSBTs), a standard defined by BIP 174. PSBTs are instrumental in the modern Bitcoin ecosystem, allowing different participants to contribute signatures and transaction data without needing to share private keys or maintain a constant connection to the blockchain. However, the modular nature of PSBTs—where signing, combining signatures, and finalizing inputs are handled as distinct steps—created a logic gap that attackers or technical errors could exploit to hide the true cost of a transaction from the user or the automated wallet software.

The Technical Framework: Understanding PSBTs and BIP 174

To understand the gravity of these bugs, one must first grasp the mechanics of Bitcoin transaction fees and the role of the PSBT format. In the Bitcoin network, a transaction fee is not explicitly stated as a separate field. Instead, it is the implicit difference between the total value of the inputs being spent and the total value of the outputs being created. For example, if a user spends an input worth 1.0 BTC and creates an output for 0.9 BTC, the remaining 0.1 BTC is automatically claimed by the miner who includes the transaction in a block.

BIP 174 (Partially Signed Bitcoin Transaction) was introduced to standardize how metadata about these inputs and outputs is passed between different software and hardware components. It allows a "Creator" to build a transaction, a "Signer" to provide a digital signature, and a "Finalizer" to wrap the transaction for broadcast. Because the signer often does not have access to the full blockchain state, the PSBT includes "UTXO" (Unspent Transaction Output) information so the signer can verify exactly how much Bitcoin is being moved and what the resulting fee will be. The flaws in bitcoinjs-lib occurred precisely within this verification and accounting logic.

Analysis of the First Flaw: Conflicting Input Records

The first vulnerability identified in the security advisory involves a discrepancy between how the library handles digital signing and how it performs fee accounting. In certain scenarios, the library could be induced to use two different values for the same input. When a transaction is being prepared for a signature, the library utilizes the full previous transaction data to ensure the signature is valid. However, the fee accounting module—the part of the code that tells the user "you are paying X in fees"—could be directed to prefer a conflicting record containing a significantly smaller value.

This creates a "silent killer" scenario. A user might see a prompt in their wallet application stating that a transaction will cost 200 satoshis in fees. Behind the scenes, the actual transaction might be spending an input worth millions of satoshis more than the output. Because the signature remains valid for the real, higher value, the Bitcoin network accepts the transaction. The vulnerable software authorizes the real transaction while evaluating a completely incorrect, lower fee.

In a demonstration provided by security researchers using bitcoinjs-lib version 7.0.1, a transaction with an actual fee of 900,000,000 satoshis (9 BTC) was reported by the library as having a fee of only 200 satoshis. Despite this massive discrepancy, the signature verified correctly, and the software’s extraction tool returned the transaction without triggering the default "excessive fee-rate" warning. At current market prices, such a bug could result in the accidental loss of hundreds of thousands of dollars in a single click.

Analysis of the Second Flaw: The Zero-Value Assumption

The second advisory focuses on finalized inputs where the input-value records are entirely missing. In the PSBT workflow, once an input is "finalized," it contains the necessary scripts and signatures to be valid on the network. The bitcoinjs-lib calculator, when encountering a finalized input that lacked an explicit value record, would default to counting that input as zero for its fee calculation.

This logic is particularly dangerous when importing an already-signed PSBT from an external party. An attacker could present a PSBT to a victim’s software where the inputs are already signed but the metadata regarding the input values is stripped or omitted. The library would calculate the fee based only on the inputs it could "see" the value for. If it sees zero for a large input, it drastically understates the total fee.

A hypothetical example provided in the disclosure illustrated a transaction with a true fee of 91,000 satoshis, while the library reported a fee of only 1,000 satoshis. Because the finalized scripts and signatures alone do not establish the missing input’s value to the library’s internal logic, the software proceeds under the false assumption that the transaction is "cheap," when in reality, it is siphoning away value to the miners.

Chronology of Discovery and Remediation

The vulnerabilities were addressed through a coordinated disclosure and patching process. The maintainers of bitcoinjs-lib released the following versions to mitigate the risks:

• Version 5.2.2 for the v5 release line.
• Version 6.1.9 for the v6 release line.
• Version 7.0.4 for the v7 release line.

The timeline of the flaw’s existence varies by version. For the "conflicting records" flaw, the affected releases included versions 5.2.0 through 5.2.1, the entire 6.0.0 through 6.1.8 range, and the 7.0.0 pre-releases through 7.0.3. The "missing record" flaw had a broader reach, affecting the v5 line as far back as version 5.1.0.

The remediation strategy implemented by the developers involves a fundamental change in how the library resolves previous outputs. The patch introduces a shared method for both signing and accounting, ensuring that the software cannot "see" two different values for the same piece of data. Furthermore, the library now strictly rejects any PSBT that contains conflicting values or scripts for the same input. Most importantly, the patched versions now require a confirmed amount for every single input during the fee calculation process; if a value is missing, the calculation will fail rather than defaulting to zero.

Additionally, the update ensures that cached fees and extracted transactions are cleared immediately after any relevant metadata changes or combinations, preventing the software from relying on "stale" or manipulated data from a previous state of the PSBT.

Broader Implications for the Bitcoin Ecosystem

The discovery of these bugs highlights a systemic risk in the "Lego-block" nature of cryptocurrency development. Bitcoinjs-lib is not just a niche tool; it is a foundational library used by web-based wallets, exchange backends, and hardware wallet integration layers. Because many developers "trust" the library to handle the complexities of BIP 174, they may not have implemented independent verification of input values.

For the end-user, the risk is not that their private keys will be stolen, but that their funds will be "burned" as miner fees. In the Bitcoin protocol, a miner fee is a non-refundable payment to the network’s validators. Once a transaction with a 9 BTC fee is broadcast and confirmed, there is no central authority to reverse it. This makes the accuracy of fee-calculation libraries a critical security concern, equal in importance to the security of the private keys themselves.

Industry analysts suggest that this event may lead to a shift in how wallet developers approach third-party dependencies. "The assumption that a library’s internal fee-guard will catch anomalies is a single point of failure," noted one blockchain security consultant. "We are likely to see more ‘defense-in-depth’ where applications perform a ‘sanity check’ on the raw transaction hex independently of the library they used to build it."

Recommendations for Developers and Maintainers

The security advisory offers clear guidance for developers currently utilizing bitcoinjs-lib in their tech stacks. The primary recommendation is an immediate upgrade to the latest patched versions (5.2.2, 6.1.9, or 7.0.4).

For maintainers who are unable to upgrade immediately due to legacy constraints or complex dependency trees, the advisory suggests several manual mitigation steps:

1. Independent Verification: Developers should write custom logic to independently verify all referenced output values against a trusted blockchain source (like a local node or a reputable API) before signing.
2. Strict Validation: Applications should explicitly check for and reject any PSBT that contains conflicting records for the same input.
3. Input Value Mandatory: Ensure that every input in a PSBT has an associated value before allowing the software to trust a fee calculation or extract a transaction for broadcast.

As the Bitcoin network continues to evolve with more complex transaction types—including Taproot and various Layer 2 protocols—the complexity of transaction construction will only increase. This incident serves as a stark reminder that in the world of decentralized finance, the code is the only law, and even a small logic error in a widely used library can have multi-million dollar consequences. The swift response from the bitcoinjs-lib maintainers has likely prevented significant financial loss, but the event underscores the ongoing need for rigorous auditing of the open-source infrastructure that powers the global crypto economy.