Sparrow Wallet

This commit fixes how Sparrow Wallet handles error responses from Bitcoin Core's RPC interface. Previously, the app could silently return a null value or crash with a confusing NullPointerException instead of telling the user what actually went wrong. The change makes error messages clearer and adds handling for HTTP 403 'forbidden' responses and non-JSON replies, which can happen when a proxy or TLS issue sits between Sparrow and Bitcoin Core.

This commit is a routine version bump from 2.5.4 to 2.5.5. It only changes version strings in four files: the build script, macOS app metadata, in-app version constant, and documentation example. There are no code logic changes, no bug fixes, and no security-related content.

This commit fixes automated test failures that only happen on Windows. It tells Git not to alter line endings in test resource files, updates a linked library (drongo), and skips one test on Windows because Windows cannot make a directory undeletable in the way the test expects. There is no user-facing security issue or vulnerability here.

This commit improves an error message in Sparrow Wallet. When a user enters an extended public key that is already used by another keystore in the same wallet, the app now names the conflicting keystore instead of giving a generic 'not unique' message. There is no security vulnerability here; it is a user-experience improvement.

This commit disables the Payjoin privacy feature when a Bitcoin transaction includes 'silent payment' outputs. Silent payments let someone receive Bitcoin without publicly revealing their address. The change prevents a risky combination where a Payjoin receiver adds their own inputs to the transaction, which would silently break the math that lets the real recipient detect and claim the silent payment. In short, the wallet now refuses to mix these two features so users don't accidentally send money to an address the recipient can no longer find.

This commit fixes a bug in Sparrow Wallet's QR code scanner. Previously, if one connected camera reported no supported video resolutions, the entire QR scan would fail. Now the app ignores such cameras and tries the next usable one instead. It also prevents a crash when the selected camera device becomes null. This is a robustness improvement, not a security vulnerability fix.

This commit changes how Sparrow Wallet checks that a connected hardware wallet is the correct one before letting the user display a receiving address, sign a message, or discover keystores. Previously, the app disabled the relevant buttons if the device's reported fingerprint did not match the wallet. The problem is that a PIN-protected device reports no fingerprint until after the PIN is entered, so the old check happened too early and could be bypassed. The new code waits until after PIN entry, re-enumerates the device to get its real fingerprint, and only then enables or disables the button. This prevents a user from accidentally using the wrong hardware wallet and, for example, displaying or signing with keys that do not belong to their wallet.

This commit changes how Sparrow Wallet's download verifier handles large manifest files. Previously, if a downloaded manifest exceeded 100 KB, the software would reject it outright and stop verification. Now, if the oversized file does not look like a manifest (no PGP signed-message header and no typical hash lines), it is treated as a release file that the signature signs directly. The change also adds a more descriptive error message. The commit title frames this as reporting an oversized manifest rather than only verifying the signature, suggesting a fix for a verification-logic edge case.

This commit changes how Sparrow Wallet remembers Payjoin payment instructions. Previously, the app stored Payjoin details keyed only by the destination Bitcoin address. That meant if you later made an unrelated payment to the same address, the app might still treat it as a Payjoin and contact the original Payjoin server. Now, Payjoin details are tied to the specific transaction (using its ID) and the payment tab, so they don't leak across separate payments to the same address. The included tests explicitly check that a later payment to the same address no longer retrieves the old Payjoin URI.

This commit adds a 'confirm your passphrase' step when importing a Bitcoin wallet seed in two places: the desktop wallet import screen and the terminal/command-line wallet creation. Previously, if a user typed a BIP39 passphrase (the extra password that unlocks a hidden wallet) with a typo, Sparrow would silently create a different wallet. The user might then send funds to addresses they do not actually control or cannot later reproduce. The fix forces the user to type the passphrase twice so typos are caught immediately.

This commit adds a security feature to Sparrow Wallet that verifies Bitcoin transaction inclusion proofs supplied by Electrum servers. Before this change, the wallet trusted the server when it reported a transaction as 'confirmed' in a particular block. Now, for newly confirmed transactions, the wallet asks the server for a cryptographic Merkle proof and checks it against a verified block header. If the proof is missing, wrong, or for a different block, the transaction is demoted to 'unconfirmed' and the user is warned that the server may be faulty or dishonest. The change protects users against a malicious or compromised server falsely claiming a transaction was confirmed.

This commit adds a verified block-header store to the Sparrow Bitcoin wallet. It keeps a local copy of block headers above the built-in checkpoints, checks that each new header really links to the previous one, and automatically rewinds and refreshes wallet history if the Bitcoin chain reorganizes (a 'reorg'). The goal is to stop a malicious or buggy Electrum server from fooling the wallet with fake transaction confirmations.

This commit only adds plain-English documentation comments (Javadoc) above each method in an interface that describes how a Sparrow Wallet component talks to Electrum servers. No code behavior was changed, no bugs were fixed, and no security-sensitive logic was introduced.

This commit adds stronger verification when Sparrow Wallet talks to public Electrum servers on mainnet. It fetches and checks Merkle proofs for transactions and block headers from the server, and refuses to continue if the server cannot provide that proof. It also adds a new test task that checks built-in header checkpoints against live public servers. The change is defensive: it reduces the chance a malicious or buggy server can lie about transaction confirmations or chain history, but it is not a fix for a known active attack.

This commit only changes on-screen text labels and help messages in the wallet import flow. It clarifies that when using SLIP39 'shamir secret sharing' recovery, any passphrase applies to the whole reconstructed wallet secret, not to each individual recovery share. There is no code behavior change, no bug fix, and no security vulnerability being patched.

This commit fixes a race condition in how Sparrow Wallet talks to USB hardware wallets. Previously, a background check for connected devices could run at the same time as a user action such as entering a PIN, signing a transaction, or displaying an address. That overlap could interrupt the device mid-operation, clear the PIN screen, or return confusing results. The change wraps all USB device operations with a single lock so they cannot overlap, and the periodic background check now skips its run if any device operation is already in progress.

This commit tightens Sparrow Wallet's user interface so that once a Bitcoin transaction has been signed, the user can no longer edit its version number or locktime fields. Before the change, the form relied on a simpler 'isEditable' check that could leave these fields enabled after signatures were added. Editing those fields after signing would change the transaction's hash (TXID), making the existing signatures invalid and potentially confusing the user into broadcasting a transaction that wallets or the network will reject. The fix centralizes the disable logic and makes editability explicitly depend on whether the transaction already contains script signatures or witness data.

This commit fixes a minor cleanup issue in a single test file. When running a test that checks whether invalid wallet files are rejected, the test now properly closes a temporary storage object afterward. It does not change any production code or fix a security vulnerability in the wallet itself.

This is a small test-only cleanup. It adds a helper method that closes a temporary storage object after checking whether a wallet file is valid, and replaces four inline storage openings in tests with calls to that helper. There is no change to production code or user-facing behavior.

This commit updates two internal library submodules (drongo and lark) used by the Sparrow Wallet. The stated purpose is to require an anti-klepto protection feature for BitBox02 hardware wallets and to fix a Taproot signing issue. The actual code changes are not visible in this commit—only the submodule pointers were moved to new commits—so we cannot directly inspect what was fixed. Anti-klepto protections reduce the risk of a compromised hardware wallet leaking private key material through biased signatures. A Taproot signing issue could, in principle, affect the ability to spend or the validity of signatures, but the diff gives no details.

This commit adds broader error handling when reading hardware cards during wallet import. Previously, an unexpected or malformed response from a card could throw an unhandled exception and potentially crash or disrupt the import process for other cards. The change catches any runtime exception, logs it, and limits the failure to the specific card that caused it. It is a defensive hardening fix rather than a clear-cut vulnerability patch.

This commit fixes two situations where Sparrow Wallet could get stuck in an endless loop while talking to a hardware card (Coldcard/Satochip). Previously, if the card refused a 'wait' request or repeatedly rejected the secure channel setup, the software would retry forever. Now it throws an error or stops after three retries. This is a reliability/DoS fix rather than a direct theft-of-funds bug, but an attacker who can make the card misbehave could freeze the wallet interface.