Electrum

This is a one-line bug fix in Electrum's Lightning Network payment handling. The code was comparing a whole status object to a resolution value, which would always be false. The fix compares just the resolution status correctly. This likely changes when a specific payment timeout error is returned versus a generic payment-details error. It appears to be a correctness fix for Lightning multi-part payment handling, with possible security implications around error handling but no clear exploit shown.

This commit is a cleanup change: it creates a single helper module for random-number generation and replaces scattered calls to os.urandom, secrets.token_bytes, and an old randrange helper with the new helpers. The new helpers still use the same Python standard-library secure random sources (os.urandom and secrets.randbelow), so the change does not introduce a security weakness. It is preparation work for a future improvement, not a fix for an active vulnerability.

This commit fixes a bug in Electrum's Lightning channel backups for 'anchor' channels. Previously, the backup did not store enough secret key information, so users with non-deterministic Lightning wallets who restored from a backup could not recover funds if the remote party force-closed the channel. The fix adds a new backup version (v3) that includes the needed private key and warns users with older backups to export fresh ones. It is a recovery/bug-fix patch, not an exploitable vulnerability in live software.

This commit changes how Electrum's Lightning wallet advertises and accepts 'zeroconf' channels when payment forwarding is enabled. Zeroconf channels are opened instantly without waiting for on-chain confirmations, which is useful for receiving payments quickly but risky if the wallet also forwards payments for others. The patch prevents forwarding wallets from acting as zeroconf clients and from accepting zeroconf channels, likely to stop a situation where a forwarding node could be tricked into losing money on an unconfirmed channel.

This patch fixes a bug in Electrum's Lightning channel handling where a malicious or misbehaving server could trick the wallet into deleting a funded channel by claiming the funding transaction was no longer confirmed. The fix makes the wallet remember that a funding transaction was once mined and refuse to downgrade that status to 'unconfirmed,' preventing accidental loss of access to funds stored in the channel.

This is a minor code cleanup in Electrum's Lightning Network peer handling. It simplifies how an inner trampoline onion packet is processed, replacing an if-statement with a conditional expression. There is no visible security change: the same operations happen in the same order and with the same conditions as before.

This commit only updates Python type hints to explicitly mark parameters and variables that can be None. It does not change any program logic, runtime behavior, or security checks. It is a code-quality and documentation improvement with no security impact.

This commit fixes a bug in the Electrum Bitcoin wallet where, if the user had disabled change addresses, funds from 'sweep' transactions (such as recovering Lightning channel funds or claiming submarine swaps) could accidentally be sent back to an address controlled by someone else instead of to the user's own wallet. The fix forces the creation of a wallet-owned change address whenever a sweep is involved, even when change addresses are normally disabled.

This change fixes a bug in Electrum's mobile/QML wallet interface where paid Lightning invoices were being deleted from the wallet's records. The fix moves the 'don't delete paid invoices' protection into the core wallet code so it applies consistently, and it also prevents deletion of invoices that are still 'in flight' (payment pending). Keeping paid invoice records is important because they are needed to show transaction history and to prove a payment was made. Deleting them could cause confusion, accounting problems, or loss of payment evidence.

This commit fixes a bug in the Electrum Bitcoin wallet where deleting a paid or in-flight Lightning invoice/request could incorrectly erase important payment records. The change now preserves those records when a payment has already completed or is still pending, preventing loss of payment history and avoiding a minor privacy leak if an in-flight payment later fails.

This change tightens up Electrum's crash reporter so it cannot be flooded with an unbounded number of exceptions. Before the patch, every unhandled exception was placed in an internal queue with no size limit, which could slowly consume memory if something kept crashing. The patch caps that queue at 100 entries and logs exceptions immediately instead of silently holding them. It is a hardening fix rather than a fix for an active attack.

This commit refactors how Electrum stores Lightning channel backups on disk. It converts backup records from a flexible JSON-style format into a stricter binary format, and adds a one-time database upgrade routine. The change is primarily a code-quality and data-format cleanup, not a fix for an active security flaw. However, any database migration that touches sensitive key material carries a small risk of corruption or mis-handling of secrets if the conversion has bugs.

This commit only adds a new automated test. It does not change any production wallet code, fix a bug, or alter how user funds are handled. The test verifies that Electrum can correctly upgrade an old test wallet database containing Lightning channel backups from database version 71 to version 72. It is a quality-assurance change, not a security patch.

This commit is a small code cleanup in Electrum's Bitcoin transaction handling. It merges two duplicate functions for writing variable-length integer sizes and adds explicit error checks for invalid values (negative numbers or numbers too large). The change makes the code more consistent and slightly safer, but it does not appear to fix any active security vulnerability or change behavior in normal use.

A one-line fix changes a function so it always returns a true/false value instead of returning the raw list of signatures. The commit message says this is harmless in how Electrum currently uses it. It is a code-correctness bug, not an obvious security vulnerability.

This commit only adjusts Python type hints and one test counter variable. It does not change any runtime behavior, so it cannot introduce or fix a security vulnerability on its own.

This commit is a defensive hardening fix for Electrum's Lightning channel watcher. It wraps each individual sweep operation in a try/except block so that if one output fails or crashes, the remaining outputs are still swept. Previously, an unhandled exception during one sweep could stop the entire process, potentially leaving funds unclaimed. The commit does not itself introduce a vulnerability; it reduces the risk of losing funds due to a crash or edge-case bug during channel closure recovery.

This commit only fixes type hints in the source code. It changes annotations such as `name: str = None` to `name: str | None = None` so that developer tools correctly understand that these variables may be empty. No actual program behavior, logic, or security checks are changed.

This commit fixes a class of crash bugs in Electrum's Qt/QML graphical user interface. When a user closes a dialog or window while a background task is still running, the background task can try to talk to a Qt object that has already been destroyed, causing a RuntimeError and possibly crashing the app. The patch adds a helper that safely ignores these 'already destroyed' errors instead of letting them propagate. It does not appear to be a security vulnerability that an attacker can exploit to steal funds or run malicious code; it is a stability/robustness fix.

This commit fixes a bug in the Electrum Bitcoin wallet that could crash or fail when trying to move funds from a watch-only wallet that only has imported addresses (no private keys). The fix makes the wallet more careful when it doesn't know the exact script type for an address, returning 'unknown' instead of crashing, and only setting a script descriptor when one actually exists. There is no direct evidence this was a security vulnerability exploitable by an attacker; it appears to be a reliability/functional bug fix.

This is a purely cosmetic change to a test file. It wraps two existing test blocks inside Python 'subTest' contexts so that if one part fails, the other still runs and the failure message is clearer. No production code was changed, and no security behavior is affected.

This commit refactors how Electrum's submarine-swap server pays Lightning invoices from clients. The main visible change is that the swap server no longer maintains its own retry queue for pending invoices; instead it delegates directly to the wallet's existing invoice-payment logic, which now rejects duplicate in-flight payment attempts. A new regression test confirms that a second payment attempt with the same payment hash is blocked while the first is still running. The commit also fixes a small bug where an HTTP endpoint called a coroutine without awaiting it. Overall the change looks like a hardening/cleanup rather than an obvious vulnerability fix, but it removes a custom retry mechanism and tightens duplicate-payment protection, which can have security relevance in Lightning.

This commit adds safety checks to Electrum's encryption helper functions and includes a self-test that runs when the program starts. The new checks make sure AES keys and initialization vectors (IVs) are the correct length before encrypting or decrypting, which helps catch programming mistakes early. The self-tests verify that hash and encryption functions produce known correct outputs, so Electrum will fail immediately if a cryptographic library is broken or misconfigured rather than silently producing bad results.

This commit adds self-tests to Electrum's cryptography code. When the program starts, it now runs a few known test vectors through hash and encryption functions and crashes immediately if the results are wrong. This is a defensive hardening change, not a fix for an active security flaw.

This commit adds a 5-second timeout and a small cache to a helper that runs the 'git describe' command when Electrum's crash reporter builds a diagnostic report. The change mainly prevents the crash reporter from hanging on slow filesystems. A code comment also flags that the helper searches the system path for a program named 'git', which could theoretically be abused if an attacker controls the program search path, but the commit does not claim this is an exploitable vulnerability.