AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 63 Bitcoin

derive the fee of a wallet transaction from the transactions funding its inputs rather than the value its history entry reports

Public commit record

What the developer wrote

Authored by Craig Raw

50/100 · Thin
derive the fee of a wallet transaction from the transactions funding its inputs rather than the value its history entry reports
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit changes how Sparrow Wallet calculates transaction fees. Previously, the wallet trusted the fee value reported by the Electrum server for each transaction. Now, when the wallet already knows the transactions that fund a given transaction's inputs, it calculates the fee directly from those input amounts minus the outputs. The server's reported fee is only used as a fallback when the wallet cannot derive the fee itself. This reduces the risk that a malicious or faulty server could trick the wallet into using an incorrect fee—particularly when the user later tries to bump a transaction's fee using RBF or CPFP.

Recommended action

Treat this as a security-hardening fix. Review the drongo submodule diff (commit 22546c2166adb652e2e8e95c68a8826b9e5347ff) to confirm getFee(Function<Sha256Hash, Transaction>) handles all input types, edge cases, and null returns safely. Ensure the fallback ordering (derived → server-reported → cached) is consistently applied across all code paths that display or use fees, especially RBF/CPFP dialogs. Consider whether any UI still displays a server-reported mempool fee before local derivation completes, which could briefly mislead users.

Security signals we found

01

Server-reported fee no longer trusted blindly when wallet can derive fee from input transactions

02

Fee derivation added in transaction fetch path before wallet stores BlockTransaction

03

Nullable fee type introduced to distinguish unknown fees from zero fees

04

New unit tests model inflated/malicious server fee and assert local derivation wins

05

RBF/CPFP fee-bumping context explicitly mentioned in commit message and tests as motivation

Risk score

Why this scored 63/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 12/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.