Electrum

This update tightens a privacy feature on Electrum's Android app that prevents the screen from being captured while sensitive Bitcoin private keys or seed phrases are visible. Before, the protection could be accidentally turned off when multiple wallet windows overlapped, potentially letting malware or a malicious screenshot grab secret key material. The fix makes sure protection stays active whenever any sensitive screen is actually visible.

This commit only adds a documentation warning to Electrum's Coldcard plugin README. It does not change any executable code, cryptographic logic, or wallet behavior. The warning tells users that Coldcard/Coinkite disclosed a firmware bug in certain Coldcard devices that could make on-device seeds easier to guess, and advises updating firmware and moving funds. Because Electrum itself is not being patched for a vulnerability, this commit is not a security fix for Electrum.

This commit tightens screen-shot protection for private Bitcoin wallet keys (WIF keys and seed phrases) in Electrum's Android/QML user interface. It also fixes a bug where one screen (AddressDetails) was leaving the 'secure window' flag permanently on, which could leave the app in a protected state at the wrong time. The change makes sure the secure flag follows whether the dialog is actually visible, and adds the same protection to two more dialogs that handle private keys.

This commit fixes a bug in Electrum's Lightning Network code. Previously, if a malicious or malfunctioning peer sent a channel re-establishment message with extremely large commitment numbers (over 2^48), the local program would hit an internal assertion failure and simply disconnect. Now, it treats this as misbehavior and force-closes the channel instead, which is the safer response. The commit also adds tests to confirm this behavior.

This change moves the trimming of leading/trailing spaces in message-signing fields from the user-interface code into the shared wallet code. For the graphical interfaces (Qt and QML), spaces are still stripped automatically for convenience. For the command-line interface, a new option disables that stripping so that exact user input is preserved. It is a usability/behavior consistency fix, not a fix for an active security vulnerability.

This commit tidies up how Electrum handles extra spaces around Bitcoin addresses, messages, and signatures when signing or verifying messages. Previously, different parts of the program (desktop GUI, mobile-style GUI, command line) behaved inconsistently—some trimmed spaces automatically, others did not. The change moves the trimming into the shared wallet code and makes it the default for GUIs, while the command-line tool now explicitly keeps spaces untouched. It is a user-experience and consistency fix, not a patch for an active security vulnerability.

This commit improves the error handling in Electrum's message decryption feature. Previously, if a user tried to decrypt a message using a public key that did not belong to their wallet, the code could proceed and likely fail with a confusing internal error. Now it explicitly checks whether the public key is wallet-related and shows a clear, user-friendly error message ('Pubkey unrelated to wallet.'). This is a defensive hardening change, not a fix for an active security vulnerability.

This commit moves four message-crypto operations (sign, verify, encrypt, decrypt) in Electrum's Qt wallet window onto a background worker thread so they all behave the same way. It also lets the background thread surface user-facing errors through the existing error handler. The change is a UI refactor, not a fix for a known exploit, but it removes a direct synchronous call that previously swallowed exceptions and could briefly freeze the GUI.

This commit changes how Electrum's message-signing function is called so that callers must explicitly name each argument (address, message, password) rather than passing them by position. The main practical effect is to prevent accidental mix-ups of argument order, which could lead to signing the wrong message or using the wrong credentials. There is no direct evidence in the commit that this fixes an active security bug or reported vulnerability.

This commit moves input-validation checks for signing, verifying, encrypting, and decrypting messages out of the user-interface code and into the shared wallet logic. It also adds type checks so that non-text inputs are rejected earlier. The change is a defensive hardening/refactoring patch: it reduces the chance that different Electrum interfaces (command line, desktop Qt, mobile QML) handle errors inconsistently or skip checks, and it makes the code easier to maintain safely. There is no direct evidence in the commit of an active vulnerability being fixed, but consolidating security checks is a security-relevant improvement.

This commit moves input-validation and wallet-type checks for message decryption out of the user-interface and command-line layers and into the core wallet code. It also removes a faster, separate decryption path for imported wallets so all wallet types now go through the same central check. The change is a defensive consolidation: it makes it harder for future user interfaces or scripts to accidentally skip the watching-only, multisig, type, and hex-pubkey checks. There is no direct evidence in the diff of an exploitable bug being fixed, but the consolidation reduces the chance that a missing check in one UI could lead to a confusing error or unexpected behavior.

This commit is a simple code cleanup: it moves the message-encryption logic from two separate places (the command-line tool and the Qt graphical interface) into a single shared method on the wallet class. The actual encryption behavior is unchanged, and no security vulnerability is introduced or fixed.

This commit is a routine code cleanup: it moves message-signature verification out of three user-interface files into a single shared helper method in the wallet module. There is no security-relevant behavior change visible in the diff. The new helper behaves the same as the old inline code, and the remaining edits only tighten some unrelated error messages.

This commit only adds Python type hints and renames some function parameters for clarity in the Electrum desktop wallet's sign/verify and encrypt/decrypt message dialogs. It does not change what the code actually does, how it processes user input, or any security behavior. It is a routine code-quality improvement with no security relevance.

This is a tiny one-line bug fix in Electrum's Coldcard hardware wallet plugin. A helper method that is supposed to fetch a software-based device identifier was calling the parent implementation but accidentally throwing away the result instead of returning it. The fix simply adds 'return'. On its own this is a routine correctness bug with very limited security implications; it could cause Electrum to fail to recognize or distinguish a Coldcard device, but it does not let an attacker steal funds or bypass protections directly.

This commit fixes a minor consistency bug in Electrum's newer QML (mobile-style) user interface. When signing a message, the app now removes accidental spaces at the start or end of the message and address, just like the older desktop Qt interface already did. Without this fix, a message signed in the QML interface could fail verification because of stray whitespace. It is a usability/reliability fix, not a serious security vulnerability.

This commit fixes a privacy leak in the Electrum wallet app. Previously, if a user opened a 'hidden wallet' (one whose filename starts with a dot, like a secret file), Electrum would remember it as the last-used wallet and could reopen it automatically on Android startup. It would also appear in the recent wallets list. The change makes Electrum forget these hidden wallets so they don't resurface automatically or show up in recents, protecting the user's choice to keep them discreet.

This commit tweaks how Electrum's Lightning Network payment routing avoids channels where a previous payment attempt already failed. Previously, the router would treat a channel almost at its known failure limit almost the same as a channel far below it. The change adds an extra routing penalty when a payment amount gets within 80% of a previously seen 'cannot send' limit, steering future payments away from likely-stuck channels. It is a hardening/robustness improvement, not a fix for a clear exploitable vulnerability, and it also adds two safety checks (assertions) on internal counters.

This change fixes how Electrum's Lightning wallet reacts when a payment route fails but the failing node no longer provides a channel update message, as now allowed by the Lightning protocol spec. Previously, Electrum would permanently blacklist the channel, which could make payments fail unnecessarily and degrade routing reliability. Now it records a liquidity hint and retries with a smaller amount instead, but only for liquidity-related failures. For other failure types without an update, it still blacklists the channel.

This commit simply renames an internal variable from `dialog_label` to `_dialog_label` to mark it as private. It is a minor code cleanup with no visible behavior change and no security relevance.

This commit fixes a bug in Electrum's support for Trezor hardware wallets. After a Trezor session times out or is closed, Electrum now forgets the old session ID. Previously it kept the stale session ID, so the next attempt to sign a transaction would crash with an InvalidSessionError instead of asking the user for their PIN again. It is a usability/reliability fix, not a direct theft-of-funds vulnerability, because the failure mode was a crash rather than an unauthorized transaction.

This commit only adds a new unit test to Electrum's Lightning wallet test suite. It checks that when a payment fails due to a temporary lack of liquidity (TEMPORARY_CHANNEL_FAILURE) and the accompanying channel policy update is identical to what the wallet already knows, the channel is not blacklisted. Instead, only a 'liquidity hint' is recorded so smaller retry amounts can still use the channel. For other failure types, even an unchanged update still causes blacklisting. There is no production code change here.

This commit only renames a local variable from 'update' to 'handled' in a Lightning Network payment-failure handler. It does not change any program logic, behavior, or security properties. The change is purely cosmetic/clarifying.

This commit fixes a bug in Electrum's Lightning payment routing. Previously, if a payment failed because a channel didn't have enough money (a temporary liquidity issue), Electrum would incorrectly 'blacklist' that channel for an hour, even when it already knew the channel's rules. This made future payments through that channel impossible for an hour, even when smaller payments would have worked. The fix stops this unnecessary blacklisting and instead relies on recorded liquidity hints to retry with smaller amounts.

This commit adds a code comment warning that a performance-sensitive part of Electrum's Lightning payment routing reads shared data without a lock. It also makes a tiny code change to store a reference to an object before reading it, which slightly reduces the chance of a value changing between two consecutive reads. There is no actual fix for a race condition, and no evidence this is exploitable as a security vulnerability.