Sparrow Wallet

This commit fixes how Sparrow Wallet updates its internal records when a user sends bitcoin to themselves using a 'silent payment' address. Previously, the wallet could fail to mark the coins being spent as spent, or could show an incorrect balance, because the wallet's update logic did not properly handle transactions discovered through the silent-payment channel. The patch makes the wallet consider both newly discovered silent-payment outputs and the inputs they spend in a single atomic update, and it also improves how broadcast transactions are tracked before they are sent to the network.

This commit changes how Sparrow Wallet creates address nodes when scanning silent payments. Previously, the wallet would fill a range of address indexes up to a target and then mark the matching one as a 'silent payment tweak' address. The new code adds a dedicated method that creates only the single silent-payment child node with its tweak value already set. The change appears intended to prevent silent-payment addresses from being created without their associated tweak data, which could otherwise lead to incorrect or missing balance tracking in single-sig (sp) wallets.

This commit is a code cleanup in Sparrow Wallet's transaction diagram display. It changes how the wallet classifies and draws transaction outputs on screen, introducing new output wrapper types for silent-payment change and consolidation. There is no direct evidence in the commit that it fixes a security vulnerability; it appears to be a UI refactor with minor correctness improvements.

This commit fixes a bug in Sparrow Wallet's silent payments feature. Previously, when scanning for incoming silent payments, the wallet only looked at transactions it had not already seen. This meant it could miss a special kind of transaction: one where the user sends bitcoin to themselves (a 'self-spend'). Because the wallet already knew about the transaction, it skipped re-scanning it for silent payment outputs, potentially causing the wallet to not display or account for those funds. The fix makes the wallet scan all relevant transactions, whether already known or not.

This commit adds support for loading and refreshing 'silent payments' (a newer Bitcoin privacy feature) wallets in Sparrow. It introduces server subscription management, scan caching, and UI wiring. There is no direct evidence in the commit of a security vulnerability, but the new code handles private scan keys and network state, so correctness matters. The change is large and touches concurrency, making subtle bugs possible, but nothing in the diff clearly enables theft, remote code execution, or data leakage.

This commit is a straightforward internal code cleanup: it moves the logic that fetches wallet transaction history out of a nested background-service class and into the main ElectrumServer class. The actual behavior, synchronization, and data flow remain essentially unchanged. There is no indication this fixes or introduces a security issue.

This commit adds support for a new Bitcoin privacy feature called 'silent payments' in the Sparrow Wallet. It lets the wallet ask compatible servers to scan for silent-payment transactions and report them back. The change also improves how Sparrow detects what a server can do, and it makes one error type more specific when Bitcoin Core cannot handle silent payments. There is no obvious security bug in the diff, but it does involve sending private scanning keys to an external server, which is inherent to the silent-payments protocol and is now done through a new RPC call.

This commit expands the list of hardware-wallet and air-gapped importers that Sparrow Wallet shows when a user creates a single-signature wallet using a 'single SP' policy type. Previously only ColdcardSinglesig was offered; now all singlesig file importers (Jade, Keystone, Passport, SeedSigner, etc.) and all card importers (Tapsigner, Satochip, etc.) are available. The change also broadens an exception handler in SpecterDIY so that non-IO errors during import are reported to the user instead of crashing or being swallowed. There is no direct security vulnerability in the diff; it is a feature/robustness improvement.

This commit simply swaps one SVG logo image for another in the Sparrow Wallet application. It changes the visual icon used for the BitView fee-rate source from a plain square to a stylized cube logo. There is no code change, no executable logic, and no security-relevant behavior.

This commit adds the ability to import a new kind of Bitcoin wallet—called a 'silent payment' (SP) singlesig wallet—through the same screens and file formats that already supported ordinary HD singlesig wallets. It updates dropdown menus, import logic, and several hardware-wallet/file parsers so users can choose between HD and SP when importing. There is no direct evidence in the commit of a security vulnerability; it reads as a feature expansion with explicit guardrails (some importers reject SP if they cannot support it).

This commit is a small internal cleanup: it stops converting a hardware wallet's extended public key (xpub) to a text string and back again, and instead keeps it as a typed object throughout the code. There is no visible user-facing change and no indication of a security fix.

This commit adds support for importing a special Bitcoin 'silent payments' scanning key from connected hardware wallets, while explicitly blocking three types of smartcards (Tapsigner, Keycard, Satochip) from being used with silent-payment wallets because they cannot support it. It is a feature addition, not a fix for an active security flaw.

This commit is a broad code change that threads a new 'policy type' value through many wallet import paths. The main practical effect visible in the diff is adding support for importing a new kind of Bitcoin wallet called 'silent payments' (policy type SINGLE_SP) from Coldcard hardware wallets. It also makes sure the correct extended public key or silent-payment scan key is set when a keystore is created, depending on the wallet type. There is no explicit mention of a security bug or fix in the commit message or code, but the change touches sensitive key-handling code and removes some workarounds that previously forced wallet-model labels.

This commit improves how Sparrow Wallet handles a newer Bitcoin address type called 'Silent Payments' (SP). It adds null-safety checks so the app doesn't crash when an extended public key is missing, supports exporting and importing labels tied to Silent Payment scan keys, and updates UI labels. Most changes are defensive or feature-related rather than fixes for active attacks.

This commit hides the 'gap limit' setting from the user interface for single-signature single-key (SP) wallets. The gap limit controls how many unused addresses Sparrow scans ahead for transactions. For this specific wallet type, the setting is now hidden because it is not applicable or could confuse users. There is no direct security vulnerability in the code change itself; it is a UI cleanup change.

This commit adds user-interface support for receiving Bitcoin 'silent payments' in Sparrow Wallet. It changes how receive addresses are displayed and copied when the wallet uses the new SINGLE_SP policy type. There is no security vulnerability visible in the diff; it is a feature implementation.

This commit adds support for silent payment change outputs in the Sparrow Wallet and fixes related silent payment issues. Silent payments are a newer Bitcoin privacy feature that lets someone receive payments without publicly revealing their receiving address on the blockchain. The changes touch how transactions are displayed, how change is created, and how the wallet interacts with Bitcoin Core. There is no clear security bug being fixed in the diff itself; it looks like a feature/enhancement commit with some defensive checks, such as blocking Bitcoin Core scanning for silent payment wallets because that is not yet supported.

This commit adds initial support for a new type of Bitcoin wallet called 'silent payments' (abbreviated as 'sp' or 'SINGLE_SP') to the Sparrow Wallet application. It updates many parts of the user interface and storage logic so that these wallets can be created, displayed, exported, and used alongside existing single-key and multi-key wallets. The changes are broad but appear to be a normal feature addition rather than a fix for a known security flaw.

This commit adds database and file-saving support for a new type of Bitcoin wallet called 'silent payments' in Sparrow Wallet. It renames some internal policy labels, adds new database columns to store silent-payment data, and updates how wallets are read from and written to disk. There is no indication in the commit or supplied references that this fixes a security vulnerability.

This commit is a large but mechanical rename in the Sparrow Wallet codebase. It replaces the old policy type constants `PolicyType.SINGLE` and `PolicyType.MULTI` with more specific names `PolicyType.SINGLE_HD` and `PolicyType.MULTI_HD`, and adds handling for a new `PolicyType.SINGLE_SILENT_PAYMENTS`. It also updates method calls in the underlying `drongo` library to pass the policy type explicitly. There is no direct evidence in the diff of a security vulnerability being fixed; it reads like preparation for adding silent-payment wallet support. A few import cleanups and one new guard against exporting silent-payment wallets are included.

This commit adds bitview.space as a new optional source for Bitcoin transaction fee estimates in Sparrow Wallet. It is a feature addition, not a fix. The new source is one of several fee-rate providers users can choose from. There is no direct evidence in the commit or supplied references that this change is a security patch or addresses a vulnerability.

This change tightens the rules for sending bitcoin to a BIP47 reusable payment code (PayNym). Previously, Sparrow would let you send to a payment code if it was already 'linked' in the wallet, even if no notification transaction had been sent. Now it also requires that a notification transaction has been sent. A notification transaction is the on-chain message that tells the recipient which payment code is paying them, so without it the recipient may not be able to derive and detect the incoming payment. The patch reduces the chance of sending funds that the recipient cannot find or spend.

This commit is a purely cosmetic tweak to how pop-up notification windows look in the Sparrow Wallet app after a user-interface library upgrade. It adds a CSS style class and adjusts spacing, padding, and minimum height so notifications display correctly. There is no security-relevant change.

This commit upgrades the user-interface toolkit (JavaFX) from version 18/25 to version 26 and switches the headless mode from an older 'Monocle' setup to JavaFX 26's built-in 'Headless' glass platform. It also removes a locally maintained copy of the JavaFX Gradle plugin in favor of the upstream published plugin. The changes are primarily build-system and UI-platform modernization. There is no direct evidence in the commit that this fixes a specific security vulnerability, but dependency upgrades can indirectly improve security by removing old, potentially vulnerable components and reducing custom build code.

This commit fixes a thread-safety bug in Sparrow Wallet's connection to a local Bitcoin node. Two internal data maps that track wallet descriptors could be modified by multiple threads at the same time, which can cause crashes, corrupted data, or unexpected behavior. The fix wraps one map in a synchronized wrapper and replaces the other with a thread-safe concurrent map.