Sparrow Wallet

This commit removes leftover code that checked whether signatures from hardware card signers were valid, but then threw away the result. The signatures are still verified later by a different part of the wallet when the signed transaction is combined. The change is essentially a cleanup with no known security flaw, though it slightly reduces defense-in-depth by removing an early, unused sanity check.

This commit adds a user-facing checkbox labeled 'Ignore dust' to the private-key sweep feature in Sparrow Wallet. When enabled, very small ('dust') unspent outputs linked to the swept key are excluded from the transaction. This is a usability and privacy improvement, not a security fix, because dust outputs are often sent by third parties to track wallets or to make sweeps uneconomical due to fees. There is no evidence in the commit or supplied references that this addresses a vulnerability or was disclosed as a security issue.

This commit hardens how Sparrow Wallet talks to an external Tor proxy's control port. Previously, when asking Tor for a new identity, the app used an older authentication method that could send the contents of a secret cookie file over the local connection. The update switches to Tor's 'SAFECOOKIE' challenge-response authentication, verifies the server before revealing anything, and refuses to open the control connection unless the target address is on the local computer (loopback). This reduces the risk that a malicious or misconfigured remote proxy could steal the Tor cookie or abuse the control port.

This commit tightens how Sparrow Wallet checks that a scanned QR code or loaded file matches the transaction the user is currently working on. Previously, the app only compared the new transaction/PSBT against the single currently open tab. Now it checks all open transaction tabs. This reduces the chance that a user accidentally accepts a wrong or maliciously substituted transaction because they had the wrong tab active. It is a defensive hardening fix, not a clear-cut remote exploit.

This commit adds a safety check in the Sparrow Wallet desktop app to make sure a transaction loaded from a file or scanned from a QR code actually matches the PSBT (a partially-signed Bitcoin transaction) that was already open. Before this change, the app would accept any transaction or PSBT from a file/scan and display it, which could mislead a user into thinking a different transaction was the one they intended to sign. The fix shows an error dialog when the loaded or scanned data does not match the original PSBT, and includes a special message for silent-payment transactions that cannot be verified from a final transaction alone.

This commit changes the project's automated build workflow to lock down the exact versions of external GitHub Actions it uses by specifying their cryptographic SHA fingerprints instead of version tags. This is a defensive hardening measure that reduces the risk of a supply-chain attack, where a malicious or compromised update to a third-party action could tamper with the wallet's build artifacts or signing certificates.

This commit adds a GitHub Actions workflow that automatically updates the project's Gradle dependency verification files. These files are a security control that helps ensure downloaded build dependencies have not been tampered with. The change itself is a defensive automation improvement and does not introduce a vulnerability or malicious behavior.

This commit fixes how Sparrow Wallet exports coin labels in the BIP-329 format. Previously, the export incorrectly marked every unspent coin as 'spendable=true' in the exported file, even though the BIP-329 specification says the 'spendable' field should only be used to mark coins as frozen (not spendable). Other wallets importing this file could have treated frozen coins as spendable, or made incorrect assumptions about the user's coins. The fix now only writes 'spendable=false' for frozen coins and leaves the field out otherwise.

This commit adds a safety check in Sparrow Wallet when opening a PSBT (a file format used to pass partially-signed Bitcoin transactions between wallets). Before this change, the wallet did not verify the signature-hash types declared inside the PSBT. A malicious or malformed PSBT could ask the wallet to sign in a way that unexpectedly alters what the signature covers, potentially leading to loss of funds. After the change, Sparrow warns the user and asks whether to continue.

This commit tightens the checks on web addresses used during two login-style features, Auth47 and LNURL-auth. Previously, a malicious or malformed callback address could use insecure schemes such as plain HTTP on the regular internet or non-web schemes like file:// or ftp://. The patch now requires callbacks to be HTTPS, a special 'srbn' scheme, or a Tor .onion address over HTTP, and adds tests to confirm the new behavior. This reduces the risk that an attacker could trick the wallet into sending authentication data to an unintended destination.

This commit adds a standard right-click menu (copy, paste, clear) to the signature text box in Sparrow Wallet's message signing dialog. It is a routine user-interface convenience improvement with no security relevance visible in the code or commit message.

This commit changes how Sparrow Wallet checks the silent payment addresses inside a loaded PSBT (a partially signed Bitcoin transaction). Previously, the wallet extracted and trusted the silent payment addresses directly from the PSBT file itself. Now it passes the PSBT to a wallet method that performs verification before returning the addresses. The change suggests the previous code may have accepted unverified or spoofed silent payment addresses from an external PSBT, which could lead to sending funds to an attacker's address, but the diff alone does not show what the new verification actually does or whether any bug was exploitable in practice.

This commit adds a safety check when extracting a BIP-322 signature from a signed PSBT file. Before, Sparrow would blindly copy the signature into the dialog even if the message inside the PSBT did not match the message the user originally asked to sign. Now it warns the user and asks whether to continue, and if the user declines (or the extraction returns null), it no longer overwrites the signature field. This reduces the risk of a malicious or mismatched PSBT tricking a user into accepting a signature for a different message than intended.

This commit fixes a problem where Sparrow Wallet did not properly 'finalize' transaction inputs that belong to another wallet when creating or handling cross-wallet PSBTs (Partially Signed Bitcoin Transactions). Without finalization, those inputs could end up with empty witness data, which may cause a signed transaction to be rejected by the Bitcoin network or to behave unexpectedly. In practical terms, this could affect multi-party or multi-wallet transactions where one wallet provides inputs it does not fully control.

This commit adds the ability for Sparrow Wallet users with 'silent payments' wallets to sign messages using the BIP322 standard. It is a feature addition that extends existing message-signing support to a new wallet type. There is no indication in the commit that it fixes a security bug or vulnerability.

This commit changes Sparrow Wallet so that newly created or renamed single-signature (SINGLE_SP) wallets get a default 'birth date' set to the current time. The birth date tells the wallet how far back in the blockchain it needs to scan for transactions. Without it, the wallet would perform a full rescan of the entire blockchain, which is slow and resource-intensive. The change is a performance/usability improvement, not a security fix.

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 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 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 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 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 a fallback path for finding the correct private signing keys when a Bitcoin wallet handles unusual transaction inputs that use very high address indexes. Without the fallback, Sparrow might fail to locate the right key and therefore be unable to sign a valid transaction the user actually owns. The change is tiny (one line) and appears to be a bug fix rather than a clear security patch, but because it touches key derivation it could affect whether funds can be spent or whether the wallet behaves safely with non-standard inputs.

This commit fixes a null pointer exception (a common software crash) that could occur when Sparrow Wallet tried to extract a signature from a special type of Bitcoin proof-of-ownership transaction (BIP322 PSBT). Without seeing the actual code change, we can only say it appears to be a defensive bug fix that prevents a crash during signature handling. There is no evidence in the commit message that this was disclosed or treated as a security vulnerability by the project.

This commit changes how Sparrow Wallet exports BIP-322 message-signing PSBTs (Partially Signed Bitcoin Transactions) to QR codes and files. Instead of serializing the PSBT in whatever internal version it was created, it now explicitly requests a PSBT version 0 format for export. This is likely a compatibility fix to ensure other wallets and tools can read the exported PSBT correctly.