Electrum

This change tightens validation of BIP32 master keys (the root keys used to derive all wallet addresses). Previously, Electrum would accept an extended public or private key that claimed to be a master key (depth 0) but had a non-zero child number or parent fingerprint. Such keys violate the BIP32 specification and could cause confusion or interoperability problems, but the patch is a defensive validation fix rather than a clear remote-exploitable vulnerability.

This update makes Electrum stricter when reading a BIP32 extended private key (the long encoded string that can generate all your wallet's addresses). BIP32 requires that the 33-byte private-key field start with a zero byte before the actual 32-byte secret. Electrum now rejects keys that violate this rule, which closes a gap where a malformed key could be accepted and later produce unexpected public keys or wallet behavior.

This commit tightens validation of Bitcoin wallet master keys. Under the BIP32 standard, a master key must have zero values for its 'child number' and 'parent fingerprint' fields. The change makes Electrum reject extended keys that violate this rule, preventing malformed or intentionally crafted master keys from being accepted. This is a defensive correctness fix rather than an active exploit patch.

Electrum added a check to reject malformed BIP32 extended private keys ('xprv...') where the private key data does not start with a required zero byte. Previously, such invalid keys may have been accepted. This is a defensive validation fix that prevents non-standard or corrupted keys from being processed, reducing the risk of key-handling bugs or unexpected behavior.

This commit fixes how Electrum's Trezor hardware wallet plugin handles passphrases. Previously, the code could prompt the user to enter their passphrase on the computer even when the Trezor device was configured to ask for the passphrase on the device itself. This could make users type their passphrase twice or, worse, enter a sensitive passphrase into the computer when they expected to enter it only on the device. The patch also makes the settings screen more robust when the device is locked. It is a usability and security-hardening fix rather than a remote-exploitable vulnerability.

This commit fixes a crash in Electrum's settings window for Trezor hardware wallets. After a user disabled the passphrase feature and disconnected the device, the settings dialog tried to read a value that had become 'None', causing a TypeError and crashing the dialog. The patch stores the device features before disconnecting and gracefully handles the 'None' case by showing 'Unknown' instead of crashing.

This commit fixes a bug in how Electrum talks to Trezor hardware wallets when a device setting forces passphrase entry on the Trezor itself instead of in Electrum. Previously, older Trezor devices could ask for the passphrase twice, and newer Safe 7 devices would fail to set up. The fix checks the device's setting and tells the Trezor library to handle the passphrase on the device when appropriate. It is a usability/compatibility fix, not a vulnerability patch.

This commit adds internal consistency checks to make sure a wallet, its lightning component, and the network layer all share the same configuration object. It is a defensive hardening change: it does not fix an active bug by itself, but makes future misconfigurations fail loudly during development/testing rather than silently causing odd behavior.

This commit adds internal consistency checks (assertions) to make sure that a wallet, its lightning worker, and the network connection all share the same configuration object. It is a hardening/test-quality change only; it does not fix any user-facing bug or vulnerability and does not change runtime behavior except to fail loudly during tests or development if the invariant is violated.

This change fixes a programming mistake in Electrum's mobile/QML user interface where the trustedcoin two-factor authentication (2FA) plugin stored wallet, transaction, and callback information as shared class-level data instead of per-use data. In practice, this could mean that if multiple wallets or transactions requested an OTP at the same time, the wrong wallet or transaction could be signed, or a stale callback could run. The patch scopes those values to each individual OTP request so they cannot collide or leak across requests.

This patch fixes a small bug in how Electrum checks proof-of-work (PoW) nonces from Nostr swap server announcements. Previously, a missing or negative nonce was treated as having zero PoW, which is correct for missing nonces but the code also allowed negative nonces to be passed into the hash calculation. The patch now explicitly rejects negative nonces and moves the PoW check inside the try block so any parsing error skips the announcement. In practical terms, a malicious or buggy swap server could have advertised a negative nonce; depending on the exact behavior of the hash function with negative numbers, this could have caused a crash, incorrect PoW evaluation, or unexpected filtering of swap servers.

This commit fixes a small bug in Electrum's submarine swap feature. When a swap server advertises itself using a Nostr event, the client checks a 'proof-of-work nonce' to verify the server did enough computational work. Before the patch, a negative nonce could slip through and be treated as valid, potentially letting a low-effort or malicious swap server bypass the anti-spam check. The fix treats negative nonces the same as a missing nonce (zero proof-of-work bits).

This change fixes a bug in Electrum wallet backups. Previously, when creating a backup of a wallet that had Lightning (Bitcoin's layer-2 network) enabled, the backup code was incorrectly wiping out the Lightning private key from the backup copy. A backup without this key cannot fully restore the wallet's Lightning funds and state. The fix simply stops removing that key, so backups remain complete and recoverable.

This commit fixes a bug in Electrum's wallet backup feature. Previously, when creating a backup, the software incorrectly wiped a private Lightning key ('lightning_privkey2') from non-deterministic Lightning wallets. That meant backups could be incomplete and users might not be able to recover their Lightning funds from the backup. The fix simply stops removing that key during backup.

This commit only updates a macOS build documentation file (README.md). It adds troubleshooting instructions for developers who are code-signing Electrum app bundles, including how to fix private-key access control and certificate trust settings. There is no code change, no wallet behavior change, and no security vulnerability being fixed.

This change tweaks a mobile-style setup wizard so that the optional passphrase text box is hidden when its checkbox is not selected, instead of merely grayed out. The commit message says this was done because users were confusing the passphrase field with the seed re-entry field. It is a usability fix, not a security bug fix.

This commit only edits the project's release notes to add a vague pre-notification that version 4.8.1 will contain undisclosed security fixes. It does not include any actual code changes, patches, or details about what the security issues are.

This commit is a routine version bump and release-notes update for Electrum 4.8.1. It does not change any executable code, only the version string and the changelog. The changelog itself lists many fixes from prior commits, but this specific commit only packages those notes for release.

This commit is purely a user-interface styling tweak for the one-time password (OTP) dialog in Electrum's QML (mobile-style) GUI. It sets the character used to calculate the input field width to '8', adds left/right padding to that width calculation, and changes how an error label is horizontally centered. There is no security-relevant change.

This commit only updates a documentation file (a README) to correct the range of Coldcard hardware wallet firmware versions affected by a previously disclosed security issue. It does not change any executable code, cryptographic logic, or wallet behavior in Electrum itself. The underlying security problem exists in Coldcard firmware, not in Electrum.

This patch fixes a crash in Electrum's submarine swap feature when using Nostr direct messages. If a Nostr server sent the same reply twice, the code tried to complete an already-completed 'future' object, which raises an exception in Python's asyncio. The fix ignores duplicate or unknown replies instead of crashing. A malicious or misbehaving swap server could potentially trigger this to disrupt a user's swap transport/connection.

This commit removes an unused software dependency called protobuf. The dependency was originally added years ago to support a Bitcoin payment protocol feature (BIP 70) that has since been removed from Electrum. Keeping protobuf in the requirements list was causing installation failures on newer systems because an old version of protobuf cannot build with current Python packaging tools. There is no security vulnerability here—this is a cleanup fix for a broken build/install process.

This change makes Electrum's wallet handle unusual or unrecognized Bitcoin signature hash types without crashing. Previously, if a transaction input used a sighash value not in the hardcoded list, the code would throw a KeyError exception. The patch now maps unknown sighash values to a warning labeled 'INSANE_SIGHASH'. This is a defensive hardening fix: it prevents an unexpected transaction from causing an unhandled error and instead reports it as a dangerous condition.

This commit is a minor logging cleanup in the mobile/QML authentication helper. It changes the wording and placement of debug/error log messages so they reveal the function name only after safely retrieving it, and avoids logging a raw tuple that could contain sensitive arguments. There is no security fix, behavior change, or vulnerability patch here.

This commit fixes a performance weakness in Electrum's handling of large Bitcoin transactions encoded in 'base43'. The base43 encoding and decoding functions run in quadratic time, meaning the work grows much faster than the input size. An attacker could send or feed Electrum a very large base43 transaction string and cause the program to freeze or become unresponsive for a noticeable period (a denial-of-service effect). The patch limits how large a base43 string Electrum will try to decode and also makes the encoder slightly faster. It does not fix the underlying quadratic algorithm.