Sparrow Wallet

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.

This commit only changes the wording of an on-screen instruction shown to users after they change the passphrase on a Trezor hardware wallet. It tells users to restart the device and adds guidance for battery-powered devices. There is no code behavior change and no security fix.

This commit fixes UI bugs in Sparrow Wallet's transaction editor when working with PSBT v2 (a modern format for partially-signed Bitcoin transactions) and 'DST' (likely descriptor/transaction templates). Previously, when a user changed transaction version, locktime, or input sequence numbers in the editor, the underlying PSBT object was not updated to match. This could cause the displayed/edited transaction to disagree with the actual PSBT being signed or exported, potentially leading to unexpected transaction behavior or failed signing. The patch makes the editor keep the PSBT in sync and also disables locktime controls when the form is read-only.

This commit adds new ways to sign Bitcoin messages using the BIP-322 standard through QR codes and PSBT files in Sparrow Wallet. It changes how the wallet decides which signing formats are allowed and removes a fallback that previously forced older P2PKH-style signing for wallets that couldn't sign BIP-322. The main concern is that the new logic may let users select a signing format their hardware wallet or keystore doesn't actually support, or may mishandle PSBT files imported back from an external signer. There is no direct evidence in the commit of a vulnerability being fixed or introduced, but the change touches security-sensitive signing code.

This commit fixes how Sparrow Wallet writes output descriptors when a wallet uses a non-standard key derivation path. Previously, the code stripped the leading 'm/' from the derivation path in a simplistic way, which could produce incorrect descriptors for unusual paths. The fix now uses a dedicated parser/formatter (KeyDerivation.parsePath/writePath) to handle the path correctly. This is primarily a correctness/reliability fix, but incorrect descriptors could in theory lead to users backing up or sharing wrong wallet configuration data.

This commit adds a brand-new feature to Sparrow Wallet: support for Keycard hardware wallets via a smart card interface. It introduces many new Java files that handle low-level smart card communication, secure channel encryption, PIN handling, key derivation, and signing. The change is a large feature addition (+3,250 lines) rather than a small bug fix. There is no direct evidence in the commit message or diff that this fixes a known security vulnerability, and no external references were provided. Some implementation details—such as hardcoded pairing passwords, a TODO comment about device certificate verification, and a fallback to a default derivation path—could become security concerns if misused, but they are not proven vulnerabilities on their own.

This commit changes Sparrow Wallet so that, when a user chooses a wallet to sign a Bitcoin transaction (PSBT), the app automatically fills in any missing key-path details needed for signing. The change is small and appears to be a usability/fix improvement rather than a clear security patch. There is no vendor statement or external reference saying this fixes a vulnerability, so we cannot confidently label it as a security fix.

This commit improves the user interface for pairing a Trezor hardware wallet with Sparrow Wallet. It adds a numeric-only input filter for the pairing code, makes the text larger, and shows the device name in pairing messages. There is no clear security vulnerability in the changes.

This commit makes two small user-interface tweaks to the screen where a user imports a master private key: it changes a title to say 'Enter master private key', makes the Import button the default button that activates when the user presses Enter, and adds a period to a description sentence. There is no security-relevant code change.

This commit updates a dependency or submodule named 'drongo' specifically for BIP32 (a Bitcoin wallet key-derivation standard) tests. The change is a single-line version bump in a test-related component. There is no diff available and no security-relevant description in the commit message.

This commit changes how Sparrow Wallet matches incoming PSBTs (Partially Signed Bitcoin Transactions) against already-open transaction tabs, and adds verification of signatures before combining them. Previously, the app matched transactions by exact byte-for-byte equality and then merged PSBTs without checking that signatures in the incoming PSBT were valid. Now it matches by transaction ID and witness data, warns when two transactions share the same ID but have different witnesses, verifies signatures before merging, and warns users about silent-payments transactions whose recipient addresses cannot be verified. The change reduces the risk that a malicious or malformed PSBT could silently overwrite or merge with an existing transaction.

This commit adds error handling for a new type of PSBT (Partially Signed Bitcoin Transaction) validation failure related to silent payments. Previously, if silent payment proof validation failed during transaction extraction, broadcasting, saving, sweeping private keys, or payjoin, the application would likely crash or propagate an unhandled exception. Now it shows an error dialog instead. The commit also makes some related payjoin logic more robust, such as computing the additional fee contribution before serialization and fixing a change-output value comparison bug.

This commit changes Sparrow Wallet to use PSBT version 2 as its default internal format instead of converting PSBTv2 files down to PSBTv0. It also adjusts how transactions are compared (by transaction ID instead of object equality) and changes how a PayJoin PSBT is prepared before being exported. These are internal refactoring changes; there is no direct evidence in the commit that they fix a security vulnerability.

This commit adds a small UI label that shows which signing keystores have already signed a multisig transaction when viewing it in the transaction details form. It is a user-interface improvement, not a security fix or vulnerability.

This commit fixes a Windows build script bug. Previously, the build process granted file permissions to a group literally named 'Users', which fails on non-English Windows versions where that group has a translated name. The change uses the universal numeric identifier (SID) for the Users group instead, so the build works on all language versions of Windows. It is a reliability/localization fix, not a security vulnerability fix.

This commit changes how the wallet's build packaging handles file metadata. It removes settings that make archive files (like ZIPs) bit-for-bit identical every time they are built, and instead restores an older Gradle behavior that preserves file permissions (such as whether a file is executable). This is likely a build-fix rather than a direct security patch, but it could affect whether downloaded archives have correct executable bits, which matters for usability and trust in reproducible builds.

This commit refines how Sparrow Wallet stores DNS payment details extracted from a Bitcoin PSBT (a transaction template). The old code tried to cache DNS payment info for both regular addresses and silent payment addresses in one combined flow, using helper methods like hasAddress() and hasSilentPaymentAddress(). The new code separates the two cases and, importantly, validates that the DNS payment record actually matches the address/silent payment address before caching it. This looks like a hardening change: it reduces the chance that a malicious or malformed PSBT could trick the wallet into caching a DNS payment entry for an unrelated address.

This appears to be a one-line change to a test file named 'drongo' with the description 'fix non bip32 child derivation test'. There is no actual diff content available, and no security-related context is provided. Based solely on the title and stats, this looks like a routine correction to a unit test for Bitcoin BIP32 hierarchical deterministic wallet key derivation logic. Nothing in the supplied materials indicates a security vulnerability, exploit, or user-facing bug.