Bitcoinjs-lib Patches Two Fee Bugs After Demo Showed 900m-Satoshi Fee Reported as 200

Bitcoinjs-lib, an open-source library that developers use to build Bitcoin applications, has fixed two bugs that can cause software to understate the miner fee a valid transaction would pay. The security disclosures, published on 26 October, point to patched releases 5.2.2, 6.1.9 and 7.0.4 across the library's three active release lines.

The flaws sit in the code that handles partially signed Bitcoin transactions, or PSBTs. Neither bug creates signatures or lets an outsider move funds unaided, but both can lead an application to approve a transaction while believing it carries a far smaller fee than it does.

What the bugs do

A Bitcoin transaction's fee is not stated directly. It is the difference between the total value of the inputs being spent and the total value of the outputs being created. Whatever is not assigned to an output goes to the miner who includes the transaction in a block.

That arithmetic means an understated input value produces an understated fee. If software believes an input is worth less than it really is, it will calculate a smaller fee than the network will actually collect.

The first flaw arises when a PSBT contains conflicting information about the same input. According to the advisory, the signing process relies on the full previous transaction, while the fee calculation favours a separate record that carries a lower value. The result is that vulnerable software can authorise the genuine transaction while assessing its fee using the wrong figure.

The second flaw concerns finalised inputs where both of the records that would normally state the input's value are absent. In that case the fee calculator treats those inputs as worth zero. Because the PSBT may already have been signed by another party, it can reach the fee calculation without the importing application performing any further signing step.

The numbers in the advisories

The disclosures include examples that illustrate how large the gap can become. In a demonstration of the first bug on version 7.0.1, the real fee was 900,000,000 satoshi, yet the library reported just 200 satoshi. The signature still verified, and the transaction was extracted without triggering the library's default warning about an excessive fee rate.

The second advisory sets out a hypothetical case in which the true fee is 91,000 satoshi while the reported fee is 1,000 satoshi. The maintainers note that finalised scripts and signatures by themselves do not prove what a missing input is worth.

The affected versions differ slightly between the two issues:

• Conflicting records: 5.2.0 to 5.2.1, 6.0.0 to 6.1.8 (including 6.1.0-rc.0), and 7.0.0-rc.0 to 7.0.3.
• Missing records: the same v6 and v7 ranges, plus 5.1.0 to 5.2.1 in the v5 line.

Why PSBTs matter here

The PSBT format is defined in BIP 174, a Bitcoin Improvement Proposal that standardises how transaction data and signatures are passed between different pieces of software. It is the plumbing behind many multi-party and hardware-assisted workflows, where one tool builds a transaction, another signs it and a third broadcasts it.

Under the specification, signing, combining signatures, finalising inputs and extracting the finished transaction are distinct roles, even when a single application carries out several of them. That separation is useful, but it also means each stage may be trusting data that originated elsewhere.

The bugs exploit precisely that trust. An application that imports a PSBT from a counterparty and leans on bitcoinjs-lib's fee figure, or on its built-in safeguard against excessive fees, could be misled if it does not independently check the outputs being spent. The fee check is meant to be a last line of defence against costly mistakes; a check that can be fed the wrong inputs offers false reassurance.

Limits on the risk

The advisories are careful to bound the danger. Actual loss requires a transaction that has been properly authorised, is valid, and is then broadcast and accepted by the network. The defects do not forge signatures, and any excess value does not flow to an attacker's address directly; it becomes a fee collected by a miner.

That distinction matters for assessing exposure. The most plausible harm is a user or service overpaying fees, potentially by a very large amount, because its software reported a reassuringly small number. Whether a malicious party could profit would depend on circumstances the advisories do not describe in detail.

The risk is also concentrated in applications that import these packages and treat the library's fee output as authoritative. Software that already verifies the value of every input it spends against its own records would not be relying on the flawed calculation in the same way.

Even so, the scale of the demonstrated discrepancy, with a fee several million times larger than reported, shows how severe the consequences could be for software that relies entirely on the library's figure.

How the fix works

The remediation tackles both problems at the root. Signing and fee accounting now use a shared method to determine the previous outputs being spent, so the two processes can no longer reach different conclusions about the same input. Conflicting values or scripts are rejected outright.

The fee calculation now also requires an amount for every input, closing the path by which missing records were silently counted as zero. In addition, cached fee figures and extracted transactions are cleared whenever relevant metadata changes or PSBTs are combined, preventing stale results from being reused.

For teams that cannot upgrade immediately, the maintainers recommend independently confirming the values of the referenced outputs. Conflicting records should be rejected before any signing or reliance on fee figures, and every input's value should be verified before the fee is trusted or a transaction is extracted.

What to watch next

The immediate task falls to developers and maintainers of wallets, payment tools and services built on bitcoinjs-lib. They will need to check which release they depend on, including indirectly through other packages, and review how their software validates PSBTs received from third parties.

The episode is also a reminder of the layered trust involved in modern Bitcoin software. Open-source libraries allow developers to avoid reimplementing complex transaction logic, but a single flaw can propagate into every application that relies on them. How quickly downstream projects adopt versions 5.2.2, 6.1.9 and 7.0.4 will determine how long the window of exposure remains open.

More broadly, the advisories underline a principle that applies beyond this library: fee safeguards are only as reliable as the data feeding them. Applications handling PSBTs from external sources may wish to treat independent verification of input values as standard practice rather than an optional extra.