Electrum

This commit updates Electrum's internal CI (continuous integration) script that runs an automated security review using Anthropic's Claude Code tool. It changes the AI model version used for reviews from 'claude-opus-5' to 'claude-opus-5-5', switches the output format to a streaming JSON format, and adds detection and warning logic for cases where Claude Code silently falls back to a different (presumably weaker) model. There is no change to Electrum wallet code, cryptography, networking, or user-facing behavior.

This commit updates Electrum's own CI security-review script. It adds detection and warnings when the automated code reviewer (Claude Code) silently falls back to a different AI model, for example after a content-policy refusal. It does not change Electrum wallet code, network behavior, cryptography, or anything end users install. It is purely an internal CI/quality-assurance improvement.

This commit fixes a bug where Electrum failed to recognize certain already-signed Bitcoin transactions as complete. Specifically, for native SegWit inputs, Bitcoin Core can produce a finalized PSBT with a valid witness but an empty scriptSig. Electrum's 'is this transaction complete?' check previously required a non-empty scriptSig for such inputs, so it wrongly treated these valid, signed transactions as incomplete. The fix adds a rule: if a native SegWit input has a non-empty witness, treat it as complete. This could have led users to try re-signing or re-broadcasting, or to confusion about whether a transaction was ready.

This commit fixes a bug where Electrum incorrectly treated finalized Bitcoin transactions as incomplete. Some wallet software (like Bitcoin Core and Sparrow) creates native SegWit transactions that omit an empty placeholder field Electrum expected. As a result, Electrum could wrongly refuse to broadcast or mishandle valid, already-signed transactions. The fix makes Electrum recognize these transactions as complete when the witness data is present.

This change prevents Electrum from re-signing Bitcoin transaction inputs that already contain a witness (the data proving the input was authorized). The patch fixes a bug where Electrum could incorrectly sign a non-SegWit input as if it were SegWit when a PSBT already included a witness for that input. This could lead to producing invalid or unintended signatures during transaction signing, especially when handling partially-signed transactions from external signers.

This commit only adds a long code comment explaining a design choice in Electrum's PSBT-over-Nostr plugin. It does not change any program behavior. The comment documents that the plugin derives each cosigner's Nostr secret key from their Bitcoin extended public key (xpub), which means every cosigner can also compute every other cosigner's secret key. The developers explicitly call this an accepted tradeoff because the only shared cryptographic material among cosigners is the xpubs, and the Nostr keys are only used to exchange proposed transaction drafts (PSBTs). No vulnerability is introduced or fixed by this change.

This is a one-line bugfix in Electrum's transaction handling. Previously, the code accidentally swallowed (hid) almost all exceptions when fetching extra transaction data from the network, only re-raising errors that were both network-related and not set to be ignored. After the fix, any unexpected error is re-raised so it can be handled or reported properly. The change improves reliability and error visibility, but the diff alone does not show an active security vulnerability being exploited.

This commit fixes several bugs in Electrum's handling of BOLT11 Lightning invoices. The most user-visible fixes are: stricter validation of invoice amounts (rejecting zero, negative, sub-millisatoshi, and leading-zero amounts), correct padding of the timestamp field so small dates don't get corrupted, preserving the 'n' (public key) tag when decoding so re-encoding doesn't silently drop it, and removing support for the non-standard 't' routing tag that could previously hide malformed data. There is also a fix to how description fields are truncated so they don't produce invalid UTF-8. These are correctness and robustness fixes rather than a single critical vulnerability, but they could have allowed malformed or ambiguous invoices to be accepted or re-encoded incorrectly.

Electrum's transaction builder had a bug where it would ignore certain consistency errors when fetching extra transaction data from the network. A malicious or misbehaving server could supply a wrong input amount, and Electrum would silently continue and sign the transaction with that wrong amount. The resulting transaction would be invalid and not accepted by the Bitcoin network, so no funds could be lost, but it could cause confusion, failed payments, or be used to probe wallet behavior.

This is a small code cleanup change. A function that reads routing hints from Lightning invoices no longer takes a tag argument because only one type of routing hint ('r') is now supported. All callers are updated accordingly. There is no security issue visible in the change.

This commit tightens how Electrum parses Bitcoin payment requests (BOLT11 lightning invoices and BIP21 URIs). It turns previously uncaught internal errors into proper validation failures, rejects malformed invoice fields that used to be silently skipped, and adds a wallet database upgrade that deletes stored invoices which no longer pass the stricter checks so old wallets can still open. The main user-visible risk is that a malicious or malformed invoice/URI could previously crash the parser or be accepted when it should have been rejected.

This commit tightens how Electrum parses BOLT11 Lightning invoices. It now rejects duplicate 'n' (node pubkey) tags instead of silently keeping only the first one, and it rejects invoice timestamps that are negative or too far in the future. These are defensive correctness fixes that reduce the chance a malformed or malicious invoice could confuse the wallet, but they are follow-up cleanups rather than a fix for a known active attack.

This commit fixes a shutdown bug in Electrum's hardware wallet support. Previously, if disconnecting from a hardware wallet failed, the cleanup thread could keep running, which could crash the application when closing. The fix stops the thread before attempting disconnect, and makes the disconnect step tolerate errors instead of crashing.

This commit is a routine dependency update for the Electrum Bitcoin wallet. It bumps versions of Python, OpenSSL, secp256k1, and various Python packages used in builds and runtime. The commit itself does not fix any known security bug in Electrum's own code, nor does the project describe it as a security update. Dependency updates can indirectly improve security by including upstream bug fixes, but without specific vulnerability information we cannot say this patch is itself a security fix.

This commit only adds new Bitcoin block header checkpoints to Electrum's built-in chain data files. Checkpoints are hardcoded reference points that help the wallet verify it is following the real blockchain and not a fake one. Updating them is a routine maintenance change; it does not fix a software bug and does not introduce new code behavior. It slightly strengthens protection against certain long-range attacks by extending the known-good chain history.

This commit simply refreshes Electrum's built-in list of Bitcoin blockchain checkpoints. Checkpoints are known-good block hashes that help the wallet verify it is following the real chain. The update adds newer checkpoints for mainnet, signet, testnet, and testnet4. There is no code change and no security vulnerability introduced or fixed here.

This commit fixes cases where Electrum's wallet cache could hold onto outdated information about coins and transactions after blockchain reorganizations or mempool changes. For example, if a transaction was previously thought to be mined but later returned to the mempool, the wallet might still treat it as confirmed and display an incorrect 'short ID' for it. The patch adds cache invalidation calls and makes the code consistently check whether a transaction is actually mined before showing a compact short ID. It is a correctness/bug-fix change rather than a direct remote-exploitable vulnerability, but stale cached state could mislead users or downstream logic about confirmation status.

This commit is a simple code cleanup: it replaces two repeated lines that set a transaction input's block height and position with a single helper method called set_mined_info. There is no change in behavior, no bug fix, and no security relevance visible in the diff.

This is a small internal code cleanup in the Electrum Bitcoin wallet. It moves the logic that builds a compact transaction identifier (like '123x4') into one shared helper method, and removes a duplicate helper class. There is no user-facing behavior change and no security fix.

This commit changes how the Electrum AppImage build container first obtains trusted web certificates. Because the build's pinned Debian package sources use HTTPS, the container needs certificates before it can talk to them. The old method stopped working on Debian 11, so the patch temporarily switches the package source to plain HTTP just long enough to install the certificate bundle, then switches back. The packages are still verified by Debian's own signatures, so this is a build-fix rather than a security vulnerability, though it does introduce a brief HTTP download step inside the isolated build environment.

This commit adds user-facing warning popups that appear when Electrum interacts with two older hardware wallets: the Digital Bitbox (BitBox01) and the Archos Safe-T mini. The message tells users these devices are being deprecated, are no longer supported by their manufacturers, and that users should move their coins to a modern device. It is a notification-only change, not a security fix or vulnerability.

This commit fixes a simple user-interface crash in Electrum's desktop (Qt) wallet. When a user double-clicked a saved invoice that pays to a raw Bitcoin script (rather than a normal address), the invoice details dialog threw an error and failed to open. It is a UI-only bug, not a way to steal funds or bypass security.

This commit fixes missing cache invalidation in Electrum's wallet history code. When a transaction's status changed—such as when a confirmed transaction returned to the mempool after a blockchain reorganization—the wallet's internal caches were not always cleared. This could leave the wallet showing stale or inconsistent information, such as an outdated balance, an outdated transaction height, or a now-invalid 'short ID' used to identify coins. The fix adds explicit cache clearing at several state-transition points and includes tests demonstrating the problem.

This commit fixes a bookkeeping bug in the Electrum Bitcoin wallet. When a transaction's status changes due to a blockchain reorganization (for example, a confirmed transaction temporarily returns to the unconfirmed mempool), the wallet was updating a coin's 'block height' but forgetting to update its 'position within the block' (txpos). The two values were getting out of sync, which could make the wallet display or identify coins incorrectly. The fix keeps both values together and adds a safety check so the short display ID is only used when both height and position are valid.

This commit fixes how Electrum handles Lightning trampoline forwarding and zero-conf channels. Previously, a forwarding node could be tricked into forwarding a partial/incomplete payment set, or could open risky zero-conf channels while also acting as a payment forwarder. The patch makes forwarding wait until the full expected amount arrives, blocks zero-conf channels for forwarding wallets, and tightens feature signaling so wallets don't advertise zero-conf support to untrusted peers when they shouldn't.