Electrum

This commit adds a new automated security-review step to Electrum's continuous integration (CI) pipeline. It does not change any wallet, networking, or cryptographic code. Instead, it introduces a script that sends pull-request diffs to Anthropic's Claude Code AI for a security scan and can post results back to GitHub. There is no vulnerability being fixed or introduced here; it is purely a tooling change.

This commit fixes a bug in Electrum's Lightning trampoline routing where a payer could accidentally include themselves as a hop on the payment route. When a user had a direct channel with the recipient, their own public key could appear in the invoice's trampoline list, and the routing code would then try to route the payment through themselves. This caused legitimate payments to fail. The fix simply removes the user's own public key from the list of candidate trampoline hops before building the route.

This commit changes a single line in Electrum's crypto library. Previously, if required encryption packages were missing, the library would abruptly terminate the entire program with sys.exit. Now it raises a standard ImportError instead, which is the normal Python way to report a missing dependency. This is a code-quality and robustness improvement, not a fix for an active security vulnerability. The main practical benefit is that other programs importing Electrum's crypto module will get a catchable exception rather than having their process killed.

This commit fixes a simple crash bug in Electrum's settings window. When the user toggled a Lightning network option while running offline (no network connection), the program tried to use a non-existent network object and crashed with an error. The fix adds a safety check to skip network calls when there is no network connection.

This is a small compatibility fix for the NWC (Nostr Wallet Connect) plugin in Electrum. It changes how incoming client requests are read so that if a request does not include a 'params' section, the server treats it as an empty params dictionary instead of crashing. The change makes Electrum work with more third-party NWC clients, but it does not appear to introduce a security vulnerability on its own.

This is a tiny code cleanup that removes an unused 'self' parameter from a static method. It does not change what the code does or fix any security problem. It is a follow-up to a previous commit.

This commit is a small code-quality patch that fixes type hints and one error message in Electrum's plugin loader. It does not appear to fix a security vulnerability. The most notable change is that a missing plugin icon now raises a clearer exception instead of returning None, which is a behavior change but not a security-relevant one.

This commit tightens Electrum's plugin authorization checks. Previously, some plugin-loading paths could execute parts of a plugin even if the user had not authorized it. The change adds early 'return' or 'assert' checks so unauthorized plugins are skipped before their code is loaded or run. This reduces the chance that a malicious or unwanted plugin could activate without explicit permission.

This commit fixes a user-interface flickering bug in Electrum's 'Receive' tab. When the wallet synced new blockchain headers, the zeroconf (zero-confirmation) warning overlay would briefly disappear and reappear, and after a user clicked 'Accept' the warning could come back again. The patch remembers whether the user already accepted the warning for the current payment request and reorders widget updates to stop the flicker. There is no security vulnerability here.

This commit changes how Electrum advertises a Lightning feature called 'zeroconf' (zero-confirmation channels). Previously, a user's wallet could tell any Lightning peer that it supports zeroconf channels, even untrusted ones. That could mislead a non-trusted Lightning Service Provider (LSP) into trying to open a special channel that the wallet would then reject, causing confusion, failed channel opens, and possibly minor privacy or denial-of-service issues. The fix makes the wallet only advertise zeroconf support to a specifically trusted LSP, or when the wallet itself acts as an LSP with no trusted peer configured.

This commit changes how Electrum calculates fees for 'just-in-time' (JIT) Lightning channels. Previously the channel size and opening fee were hardcoded; now they are configurable settings. More importantly, the code now adds the actual Bitcoin mining fee for the funding transaction on top of the service fee, so the Lightning Service Provider (LSP) does not accidentally open channels at a loss when on-chain fees are high. It also rejects payments that would be too small after deducting those fees. This is a business-logic/economic fix rather than a remote code-execution vulnerability.

This commit only adds new automated tests for an existing Lightning Network feature called 'just-in-time channel opening.' It does not change the actual wallet or payment-handling code that users run. There is no security fix or vulnerability introduced here.

This commit hardens Electrum's 'just-in-time' Lightning channel opening. It makes the service provider automatically clean up half-open channels if the payment fails, and retry broadcasting the funding transaction more reliably. The main risk being fixed is that a provider could get stuck with an unfunded channel or lose track of whether the funding transaction was actually sent, which could lead to lost funds or service disruption.

This change fixes a bug in Electrum's Lightning 'just-in-time' (JIT) channel feature. Previously, every JIT channel opened with the same Lightning service provider (LSP) was being assigned the same internal identifier derived from the LSP's public key. That made it impossible to tell multiple JIT channels apart, which could confuse routing and prevent a user from having more than one usable JIT channel with the same LSP. The patch stops setting that duplicate identifier and instead relies on a remote alias already received when the channel becomes ready. A test is added to verify that two JIT channels can be opened successfully.

This commit fixes a configuration check in Electrum's Lightning Network code. Previously, when forwarding payments through a trampoline node, the software ignored a setting meant to control whether it opens special 'zeroconf' channels. The patch makes the code check that setting consistently and renames it from 'accept' to 'open' to better reflect that it controls opening channels in both directions. This is a defensive fix to prevent unintended channel opens.

This commit fixes a bug in Electrum's Lightning code that handled 'zeroconf' channels—channels that are usable before their funding transaction is confirmed on the Bitcoin blockchain. The old code would crash because it tried to call a method that no longer exists, and it could also remove a channel too early or leave a user exposed to a scamming payment provider. The fix makes the code more careful: it waits until the wallet is fully synced, freezes the channel so it isn't advertised for receiving more payments, and only removes the channel after a longer timeout. It also adds a unit test to cover this code path.

This commit adds a safety check for Electrum's Lightning 'just-in-time channel opening' feature. When someone opens a payment channel to you on the fly, the remote party can propose an extra opening fee. Previously the code accepted any fee with only a 'todo' comment. Now it rejects the channel if that fee exceeds 10% of the channel's funding amount. Without this check, a malicious or misconfigured Lightning Service Provider (LSP) could potentially charge an unreasonably high opening fee.

This commit only adds a new automated test for Electrum's Lightning wallet. It checks that when creating a Lightning invoice, the wallet correctly decides whether to advertise 'trampoline routing' support and which routing hints to include based on the types of channels the user has open. It does not change any production wallet code, so it cannot directly introduce or fix a security vulnerability on its own.

This commit changes how Electrum decides whether to advertise 'trampoline routing' support on Lightning invoices and stops automatically freezing non-trampoline channels for receiving when trampoline mode is on. Previously, enabling trampoline could silently block payments through non-trampoline channels; now the wallet only advertises trampoline if every usable channel supports it, and users can receive through non-trampoline channels again. The change is more of a bug fix / behavior correction than a critical security patch, but it could affect payment routing and user expectations.

This commit changes how Electrum generates Lightning Network invoices. Previously, routing hints could include regular (non-trampoline) channels even when the invoice advertised support for trampoline routing. Now, if the invoice says it supports trampoline routing, only trampoline-capable channels are included as hints. This makes the invoice's advertised features consistent with the actual routing hints, which can prevent payment failures or routing confusion for wallets that rely on those hints.

This commit hardens how the Electrum desktop wallet handles Bitcoin payment URIs received through its internal RPC interface. Before the change, an attacker who could already talk to Electrum's local RPC server might be able to silently change the recipient and amount on the user's Send tab while the user was in the middle of creating a different payment. The patch now shows a notification, clears the existing payment fields, and then fills in the new URI, making the change visible and preventing leftover values (such as an amount from a previous payment) from being reused unexpectedly.

This commit reduces the attack surface of Electrum's built-in remote-control server when running in normal GUI mode. Previously, the RPC server exposed many wallet-related commands; now, in GUI mode on mainnet, it only exposes two safe commands ('ping' and 'gui'). The change is a hardening measure, not a fix for a known active exploit. It explicitly leaves the full RPC server enabled for daemon mode and for testnet GUI mode (for development).

This is a tiny code cleanup in Electrum's background daemon. A line that only makes sense for TCP network sockets was moved so it no longer runs for Unix domain sockets or Windows named pipes. Before the fix, starting the command server over a non-TCP socket could crash with an error. There is no sign this was exploitable as a security vulnerability.

This commit removes a hard crash (assertion) in Electrum's wallet code when a user loads a partially-signed Bitcoin transaction (PSBT) whose calculated fee is negative. Instead of crashing, Electrum now logs a warning and continues. A negative fee can happen if transaction inputs and outputs are crafted or edited in unusual ways. The change prevents a denial-of-service-like crash when opening such a transaction, but it does not by itself fix whatever produced the negative fee.

This commit simply moves a user-interface slider for setting the maximum Lightning Network routing fee from the Settings window into the payment confirmation dialog. It is a usability improvement, not a security fix. There is no change to how payments are authorized, no new code path that could steal funds, and no vulnerability being patched.