Electrum

This commit only adds helpful hover text (tooltips) to the 'New Channel' button in Electrum's user interface. It explains why the button is disabled when Lightning isn't available and what the button does when it is enabled. There is no security change.

This commit changes only a Python type hint in the Lightning Network peer code. It replaces 'Awaitable' with 'Coroutine' in a function signature annotation to better match what asyncio.create_task expects. Type hints do not affect runtime behavior, so this cannot by itself introduce or fix a security vulnerability. It is a code-quality/correctness improvement for static analysis tools and developers.

This commit fixes a bug in Electrum's Lightning payment handling. When a background callback task finished, the code tried to read a payment record that might already have been deleted, causing a KeyError. The fix removes that unsafe lookup and instead sends any callback failure to the crash reporter. It is a robustness fix rather than a security vulnerability; the error was noisy and could hide real callback failures, but there is no evidence it could be exploited to steal funds or bypass protections.

This commit only removes unused test helper code from two test files. It does not change any production wallet or network code, so it cannot affect real users' funds or security.

This commit fixes a small bug where Electrum servers that include 'bitcoin:' in front of their donation address were being rejected as invalid. The change strips that prefix before checking the address. It is a minor usability fix for donations, not a serious security issue, though it does slightly tighten input validation by ensuring the server response is a string.

This is a small bug-fix patch. When a user deletes a wallet, Electrum now clears its 'remembered last wallet' setting so the app doesn't try to reopen the deleted wallet on next launch and show an error message. It is a user-experience fix, not a security vulnerability.

This is a one-line bug fix in Electrum's mobile/QML wallet interface. When a user deleted a wallet from the list, the wrong row index was passed to Qt's list-removal machinery, so the wallet stayed in the list and the displayed list became corrupted. The fix uses the correct index. There is no direct security impact: it is a UI consistency bug, not a vulnerability that lets an attacker steal funds or run code.

This commit changes the mobile/QML version of Electrum so that, when the app starts and the user's entered password does not unlock the most recently used wallet, the app will automatically try to open any other wallet on the device that can be unlocked with that same password. The goal is to help users who have multiple wallets with different passwords. However, it means a password intended for one wallet may silently open a different wallet, potentially showing balances, transaction history, and addresses the user did not expect. It also adds a stored config flag that remembers whether all wallets previously used the same password.

This commit fixes a resource leak in Electrum's mobile-style QML user interface. If a user closed the wallet unlock dialog without actually unlocking a wallet, a hidden 'LoadingWalletDialog' would keep running in the background. Its internal signal connections would pile up and never be cleaned up, which could gradually slow down or destabilize the app. The fix explicitly destroys the dialog when it was never shown, so its cleanup code runs.

This commit is a user-interface cleanup for Electrum's mobile/QML app. It changes the app so that when no wallet is open, the user sees a wallet list screen instead of a 'no wallet loaded' placeholder inside the main wallet view. It also moves handling of incoming payment links (URI intents) from the wallet view to the top-level app so the link is not lost if a wallet isn't open yet. There is no security fix here.

This commit updates Electrum's Lightning code to follow a newer version of the Lightning Network specification (BOLTs). It makes the 'channel type' feature mandatory instead of optional when opening or accepting Lightning channels. The change removes old conditional code paths and simplifies the logic. There is no direct evidence in the commit that this fixes an active security vulnerability; it appears to be a protocol-compliance and code-simplification change.

This commit removes leftover code for an obsolete and never-supported Lightning Network feature called 'anchor outputs.' It is a cleanup change with no apparent security relevance.

This is a small user-interface fix in the Electrum Bitcoin wallet. Previously, the list of 'disconnected servers' shown in the network settings only displayed secure ':s' servers and hid plain-text ':t' servers and .onion servers, even if the user had bookmarked them. The change makes bookmarked plain-text and .onion servers visible again so users can see and manage servers they deliberately saved. It does not change how the wallet actually connects to servers or any security-critical networking logic.

This commit is a simple internal code cleanup. It moves duplicated logic for listing disconnected servers from two user-interface files into a single shared helper method in the core networking module. There is no change in behavior visible to users and no security fix or vulnerability introduced.

This commit changes the mobile-style QML wallet settings screen so that when a user tries to change their wallet password, the app encourages (and on Android enforces) using the same password already used by another wallet. It is a user-experience/policy change, not a security fix or vulnerability. There is no evidence of a security bug being patched.

This commit changes how the Electrum mobile/QML wallet listens for payment request status updates. It switches from a direct callback to one processed through the Qt event loop, so the backend can finish its own bookkeeping before the user interface reads the payment database. The stated goal is to fix a reported bug (#10116), likely a race condition where the UI shows stale or inconsistent payment state. There is no direct evidence in the commit that this is a security vulnerability, but race conditions between payment status and database queries can in principle lead to incorrect UI state or user decisions.

This commit changes the Electrum mobile/QML wallet interface so that users cannot create a new wallet until they have first unlocked an existing wallet. The goal is to prevent a frustrating situation where a user goes through the entire new-wallet setup (for example, writing down a recovery seed) and only afterward discovers they must enter an existing wallet password they have forgotten. The change also fixes a related state issue where the single-password setting was not being updated after a password change. There is no direct evidence in the commit that this fixes an active security vulnerability; it reads as a usability and defensive hardening improvement.

This commit fixes a crash or misbehavior in Electrum's Qt address list. The developer suspects that storing a Python tuple inside a Qt data container (QVariant) was causing problems, so they converted the address index tuple into a plain sortable string before storing it. There is no direct evidence in the commit that this is a security vulnerability; it appears to be a stability/bug-fix change.

This is a small bugfix in Electrum's background service (daemon). When a user switched to a wallet that was already open, the daemon forgot to update its record of which wallet is currently active. The patch makes it remember the active wallet in that case. There is no direct evidence this is a security vulnerability, but it could contribute to confused state or unexpected behavior in the wallet user interface.

This commit adds a new 'Manual' fee mode to Electrum's QML (mobile-style) GUI, letting users type in an exact fee or fee rate. It also tightens safety checks for fee-bumping actions (CPFP, RBF bump, and RBF cancel) by warning when the new fee is too low to be relayed by the network or, in the case of CPFP, lower than the parent transaction's fee rate. The changes are mostly defensive UI hardening rather than a fix for an active vulnerability.

This commit adds input validators to two manual fee input fields in Electrum's QML (mobile-style) user interface. One field now only accepts whole numbers, and the other only accepts numbers with at most one decimal place. This is a defensive hardening change that reduces the chance a user can type malformed or unexpected values into fee fields, which could previously lead to confusing errors or invalid transactions.

This commit tightens error handling in Electrum's mobile/QML wallet when creating a transaction to sweep funds. Previously, the code caught every possible exception and only logged the error, which could hide unexpected failures and leave the user with a generic or misleading warning. Now it only catches two specific, expected errors (no fee estimates and insufficient funds) and lets other errors surface normally. This is a defensive hardening change, not a fix for a known active exploit.

This commit is a purely cosmetic update to a help dialog in Electrum's mobile-style QML user interface. It adjusts spacing, alignment, background colors, and padding so the dialog looks better. There is no security relevance.

This commit fixes a regression in Electrum's QML (mobile/lightweight) user interface where creating a 'sweep' transaction accidentally ignored the user's chosen fee policy and passed no fee settings at all. The fix restores the intended behavior so the transaction respects whatever fee policy the user selected. The actual security impact is moderate and mostly user-facing: users might have gotten unexpectedly slow confirmations or unexpectedly high fees, rather than a direct theft-of-funds bug.

This commit is a hardening and usability change for Electrum's mobile/QML wallet creation wizard. When the app is configured to prefer a single password across wallets, it now forces the user to reuse an existing wallet password when creating a new wallet, instead of allowing a new password. It also renames an internal configuration flag and exposes helper functions to check how many wallets a password can unlock. There is no direct security vulnerability being patched; it is a defensive measure to reduce password fragmentation.