Electrum

This commit tightens how Electrum's Lightning code handles channel setup messages. Previously, the code tolerated missing optional fields (channel_type) in some situations; now it requires them to be present and rejects the connection if they are missing. This is a defensive hardening change that reduces the chance of a peer tricking the wallet into opening a channel with unexpected or unsafe settings.

This commit is a small internal cleanup in Electrum's Lightning networking code. It introduces a single `self.config` shortcut so the code always reads settings from the same place instead of sometimes using `self.network.config` and sometimes `self.lnworker.config`. There is no user-facing change and no security fix.

This commit is a simple renaming of a Lightning Network feature flag to match a recent change in the official protocol specifications (BOLTS). It replaces the old name 'OPTION_ANCHORS_ZERO_FEE_HTLC' with the shorter name 'OPTION_ANCHORS' everywhere it appears. The numeric bit positions and behavior are unchanged, so this is a non-functional code cleanup with no security relevance.

This commit is a performance optimization for the mobile-style QML history list in the Electrum Bitcoin wallet. It stops the fiat (local currency) value labels from being recalculated while the user is drag-scrolling, and refreshes them only when the scroll finishes. There is no security-relevant change.

This commit is a minor memory-use optimization for the Electrum mobile/QML user interface. It tells Qt to keep only the needed icon size in memory instead of loading the full 256x256 image. There is no security issue here.

This commit is a user-interface performance tweak for Electrum's mobile-style QML history screen. It makes scrolling through transaction history smoother by reusing list row objects instead of constantly creating and destroying them, and by disabling a visual press effect that was causing flicker. There is no security-relevant change here.

This commit adds a new read-only command that lets users list payment details (HTLCs) for one of their own Lightning channels. It does not change how money moves, does not add new network exposure, and does not appear to introduce a security vulnerability.

This is a small bug-fix patch for Electrum's mobile-style QML user interface. It prevents a crash when a payment-request status update arrives after the wallet object has already been cleared. The change simply checks that the wallet reference still exists before comparing it. There is no direct evidence in the commit that this is a security vulnerability, and the most likely effect is a harmless UI crash rather than a security exploit.

This commit only updates the project's SECURITY.md file to add a new preferred way for researchers to privately report security vulnerabilities through GitHub's built-in reporting feature. It does not change any application code, fix a bug, or address an active security issue. It is a documentation/process change only.

This commit only adds a documentation comment to the export_lightning_preimage command explaining that exporting a Lightning payment preimage does not require the wallet password. It changes no code behavior, no access controls, and no security logic. There is no vulnerability in this patch.

This commit only moves and adapts a unit test for Electrum's Lightning trampoline routing feature. It changes where a test case lives and how many payment attempts are expected, but it does not fix any user-facing bug or change any production security behavior. There is no indication this is a security patch.

This commit changes how Electrum routes Lightning trampoline payments. When a trampoline forwarder cannot find a path, it can now return a list of alternative trampolines it knows, along with their fees, inside the payment failure message. The sender then uses that list to build a better route. The change also removes the old fixed two-trampoline-hop option and adjusts when fee/expiry errors are raised during forwarding. It is a protocol/routing improvement, not a clearly disclosed security fix.

This commit changes how Electrum's Lightning wallet builds payment routes when using trampoline routing. It adds a shortcut: if the payment recipient is directly connected to the wallet via a channel, Electrum can create a direct route without needing the full network channel database. The change also moves the fee-budget check out of the general route builder so it applies to both direct and non-direct routes. There is no explicit security bug in the diff, but the change touches payment routing logic and fee checks, which are security-sensitive.

This commit is a simple code cleanup that renames leftover references from 'LnAddr' to 'BOLT11Addr' and 'lndecode' to 'decode_bolt11_invoice' in comments and docstrings. It makes no functional changes to the code and has no security relevance.

This is a one-character typo fix in a user-interface file for Electrum's QML (mobile-style) GUI. The button that starts a Lightning swap was checking the wrong property name, which likely meant the button stayed disabled even when a Lightning receive balance existed. There is no security issue here—just a UI bug that may have prevented users from clicking a swap button.

This commit removes unused Python imports from two files: a Qt channel details dialog and a watchtower server plugin. It is a routine code cleanup with no functional changes and no security relevance.

This commit is a large but purely cosmetic rename in the Electrum Bitcoin wallet. It renames the internal module `lnaddr.py` to `bolt11.py` and renames classes/functions from names like `LnAddr` and `lndecode` to `BOLT11Addr` and `decode_bolt11_invoice`. The goal is to avoid confusion with the newer BOLT 12 Lightning invoice format. The actual code logic is unchanged, apart from removing the obsolete `object` base class from one class. There is no security fix or vulnerability introduced here.

This commit tightens a check in Electrum's crash reporter so it refuses to send crash reports to Electrum's servers when the software is an altcoin fork. Previously, forks that kept Bitcoin's genesis block but changed the project's source-code URL could still spam Electrum with crash reports. The change adds a URL check to catch more forks. It is a defensive hardening patch, not a fix for a vulnerability in Electrum itself.

This commit is a purely cosmetic user-interface tweak. It moves a padding setting from one specific dialog into a shared text-area component so all text areas look consistent. There is no security relevance.

This is a minor user-interface fix for Electrum's mobile/QML app. It makes placeholder hint text disappear once the user starts typing in a multi-line text box, so the hint doesn't visually overlap with what the user wrote. There is no security issue here.

This commit updates the recommended PyQt6 version for Electrum's newer QML-based graphical interface. It loosens the version pin from below 6.6 to approximately 6.10, and removes notes saying 6.4 worked best because 6.5 was needed for a missing module. On its own, this is a routine dependency bump, not a clear security fix. However, pinning to an older PyQt6 branch can carry unpatched Qt/PyQt bugs, so moving to a newer supported line is generally healthier for security.

This commit only renames an internal variable from `coeff` to `amt_in_coeff` and adds a clarifying comment. The mathematical behavior is unchanged, and there is no security fix or functional change.

This commit only adds new unit tests for an existing fee-budget allocation function used in Lightning trampoline routing. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly.

This commit fixes how Electrum calculates fees for trampoline Lightning payments when some route edges have known fees and others are unknown placeholders. Previously, the code ignored known fees and split the entire budget evenly among placeholder edges, which could either overpay or exceed the intended fee budget. The new code solves a small linear equation so the final total fee stays within budget. This is a correctness and fee-budget safety improvement, not a direct theft-of-funds bug, but getting it wrong could cause payments to fail or users to pay more than expected.