Electrum

This commit tightens the conditions under which Electrum automatically sends Bitcoin transaction change into a Lightning Network swap. Previously, the wallet only checked whether the Lightning node could receive the amount. Now it also verifies the swap provider actually has enough liquidity and that the amount meets minimum and maximum swap limits. Without this check, a user could create a transaction whose change is routed into a swap that cannot currently be fulfilled, potentially leaving funds stuck, failing the payment path, or producing a poor user experience. The change is defensive rather than a fix for an active exploit.

This commit is a code cleanup in Electrum's Qt transaction editor. It moves the 'submarine swap' connection setup code so it can be reused by a future 'send change to Lightning' feature, and switches GUI updates from direct cross-thread calls to Qt signals/slots. There is no indication this fixes an exploitable security bug; it appears to be a maintainability and thread-safety improvement.

This commit simply moves a block of user-facing help text about 'Submarine Payments' from one file to another shared location. It does not change what the text says, how payments work, or any security behavior. There is no security issue here.

This commit only improves user-facing messages in Electrum's Qt transaction confirmation dialog. It explains when the 'send change to Lightning' feature will or won't be used, including reasons such as Lightning not being enabled, channel limits, or swap provider minimum/maximum amounts. There is no security-relevant code change.

This commit changes an internal lock in Electrum's callback system from a regular lock to a re-entrant lock (RLock) and adds a comment explaining that the lock must be re-entrant because object cleanup (garbage collection) can now trigger code that tries to acquire the same lock again. A regular lock would cause a 'deadlock'—the program freezing while waiting for itself. The commit message frames this as a follow-up fix for a previous deadlock fix. It is a reliability/availability issue rather than a direct theft-of-funds bug, but deadlocks in wallet software can make the application unresponsive.

This commit fixes a memory leak in Electrum's event-callback system. Wallet and Lightning objects registered event callbacks during creation but often never unregistered them, so they stayed in memory forever. The fix stores callbacks as weak references and automatically unregisters them when an object is destroyed, allowing Python's garbage collector to reclaim the memory.

This commit fixes a bug where Electrum's background plugin thread could freeze while waiting for a hardware wallet to be unlocked. The fix moves the timeout check onto a separate executor thread so the main background thread stays responsive. A side effect is that the GUI no longer freezes when loading plugins while a hardware wallet is waiting for user input. There is no direct evidence this is a security vulnerability, but thread-blocking bugs can sometimes be abused to create denial-of-service conditions.

This commit is a minor user-interface tweak for the Electrum mobile app. It shortens the label for a 'max brightness when showing QR codes' setting and disables that setting on non-Android systems because the feature only works on Android. There is no security issue here.

This commit fixes a security gap in Electrum's mobile-style QML user interface. Previously, signing a message with one of your wallet's private keys did not ask for the user's payment authentication (PIN/password/biometric). Now it does. Message signing is used to prove you own a Bitcoin address, and an attacker with brief access to an unlocked device could previously forge your signature without re-authenticating.

This commit fixes a privacy gap in Electrum's mobile-style QML user interface. Previously, when you opened the details for a Bitcoin address and viewed its private key, the app window was not marked as 'secure,' meaning another app or the operating system could take a screenshot or screen recording of the private key. The change tells the app controller to protect the window from screenshots whenever a private key is being shown. This reduces the risk that malware or a compromised helper app could steal the key by capturing the screen.

This commit is a small user-interface cleanup, not a security fix. It simply grays out and ignores a 'screenshot protection' setting on non-Android platforms because that feature only exists on Android. There is no vulnerability being patched.

This commit is a simple user-interface reorganization in Electrum's mobile/QML preferences screen. It groups existing security-related toggles (biometric authentication, payment authentication, screenshot protection) under a new 'Security' heading and renames one toggle from 'Always allow screenshots' to 'Protect secrets from screenshots' while keeping the same underlying setting. No security vulnerability is introduced or fixed.

This commit fixes a cleanup bug in Electrum wallet shutdown. Previously, the Lightning Network worker (lnworker) was only stopped when the wallet was online. If the wallet was offline, the Lightning worker might not shut down cleanly, potentially leaving background tasks running or resources not released. The change ensures the Lightning worker is always stopped during wallet shutdown, regardless of whether a network connection exists.

This commit changes an internal event-notification system in Electrum so that registering the same callback multiple times is now harmless (idempotent) instead of creating duplicates. It also adds a docstring warning that failing to unregister callbacks can leak memory. There is no direct evidence of an exploitable security vulnerability in the diff itself; it reads as a robustness improvement.

This commit only adds new automated tests for existing internal utility classes (CallbackManager and EventListener). It does not change any production code, so it cannot introduce a security vulnerability or fix one.

This is a small internal code cleanup in Electrum's memory-leak debugging utility. It moves an existing object-counting routine into a helper function and changes it to store weak references instead of strong references. There is no user-facing bug fix or security change.

This is a small bug fix in an internal debugging helper used to investigate memory leaks. It now gracefully returns nothing when the requested object type cannot be found, instead of crashing. There is no security relevance.

This commit fixes a confusing user-interface behavior in Electrum's mobile/QML app. Previously, when a user typed the wrong password, the password dialog simply closed without explanation, which could make them think an action had happened. Now the dialog stays open and shows an 'Invalid Password' message. It is a straightforward usability improvement, not a security vulnerability fix.

This is a tiny code-quality change: when Electrum's helper function detects a broken symbolic link (a 'dangling symlink') while creating a directory, it now raises a more specific Python error type (FileNotFoundError) instead of a generic Exception. The behavior is the same; only the error class is more precise. It is not a security fix and does not change how an attacker could exploit the software.

This commit fixes a bug in Electrum's mobile/QML wallet interface where changing a wallet password could leave some loaded wallets in a 'locked' state. The fix restores the app's internal rule that all loaded wallets must stay unlocked. A locked wallet could temporarily block the user from spending or viewing balances until re-unlocked, but this appears to be a reliability/UX bug rather than a direct theft vulnerability.

This commit tightens up how Electrum wallets handle being 'unlocked' with a password. It makes the unlock() function itself treat an empty string the same as no password, ensures the function that returns the in-memory password validates it first, and adds a helper to check whether the wallet is currently unlocked. These are defensive sanity checks rather than fixes for a known active attack.

This commit fixes a user-interface bug in Electrum's QML (mobile-style) GUI that prevented users from opening wallets that have no password. Previously, the GUI would always ask for a password and reject an empty answer, making passwordless wallets impossible to open in many cases. The fix correctly distinguishes between 'no password provided' and 'an explicitly empty password was provided,' allowing passwordless wallets to open. This is a usability/functional bug, not a direct security vulnerability, though it could indirectly affect users who rely on passwordless wallets.

This commit only changes log messages so that wallet files are named in Lightning Network peer diagnostics. It makes debugging easier when multiple wallets are open, but it does not alter security behavior, fix a bug, or introduce any user-facing risk.

This commit only adds a documentation note to the Android build README explaining that the `adb install` command can target a specific Android user profile with `--user {userId}`, otherwise it installs for all profiles. There is no code change and no security fix or vulnerability introduced.

This commit removes the old 6-digit PIN authentication from Electrum's Android/QML interface and replaces it with a single 'Payment authentication' setting. When enabled, the app now uses the phone's built-in biometric or system PIN/password prompt; when disabled, it just asks the user to confirm. The change also tightens Android biometric security by requiring Android 11+ and allowing only strong biometrics or device credentials. It is a feature redesign rather than a clear-cut vulnerability fix, but it likely addresses weaknesses in the previous custom PIN implementation.