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.