Electrum

This is a one-line code cleanup that changes how a constant number is written. The value 147712 is rewritten as 0x24100, which is the exact same number in hexadecimal notation. A comment is also slightly reordered. There is no functional change and no security relevance.

This is a small user-experience fix for Electrum's Ledger hardware wallet plugin. When the Ledger device disconnects or its Bitcoin app is closed during use, the software previously generated an internal crash report. Now it shows a friendly on-screen message instead. There is no indication this change fixes a security vulnerability or introduces one.

This commit fixes a bug where Electrum could not clean up incoming Lightning channels that never received their on-chain funding transaction. Previously, an internal safety check (assert) blocked deletion, causing repeated crashes in the background watcher. The patch adds proper timeout logic so these stale, unfunded channels can be removed safely. It is a reliability/DoS fix rather than a direct theft-of-funds vulnerability.

This is a minor user-interface fix. When a user starts a Lightning LNURL-withdrawal in the Electrum desktop app and then clicks Cancel, the app now quietly handles that cancellation instead of possibly showing an unhandled error. It does not create a security vulnerability; it improves the user experience by suppressing a harmless exception.

This is a tiny compatibility fix for the Electrum Bitcoin wallet's handling of LNURL-withdraw (a way to withdraw bitcoins from a service). Some LNURL servers send a 'null' value for the minimum withdrawal amount instead of the number 0. Previously, Electrum would crash when converting 'null' to an integer. The change treats 'null' as 0 so the wallet can continue. It is not a security fix and does not introduce an obvious vulnerability.

This commit only adds a new automated test to Electrum's Lightning networking code. It checks that a multi-part payment (MPP) is rejected when the recipient's invoice did not advertise support for MPP. There is no change to production code, no bug fix, and no security patch in the diff itself.

This commit fixes a bug in Electrum's Lightning payment receiving code. Previously, a merchant could create an invoice that said 'do not pay me using multiple payment parts (MPP)', but Electrum would still accept such multi-part payments anyway. The patch makes Electrum reject those unwanted multi-part payments. This matters because accepting MPP when it was not requested could let a payer split a payment in ways the receiver did not expect, potentially causing accounting confusion, channel fee issues, or problems with just-in-time (JIT) channel opening, which only supports single-part payments.

This commit changes how Electrum stores and uses Lightning invoice features. It records which features (like multi-part payments, or MPP) were advertised in an invoice, so the wallet can later check whether the sender followed those rules. The change also fixes a minor bug where the wallet read from the wrong config object. There is no direct evidence in the commit that this fixes an active exploit, but it is a defensive hardening change that prevents a sender from ignoring the receiver's invoice rules.

This commit changes how Electrum's Lightning wallet internally tracks incoming multi-part payments. Instead of using the short channel ID (which can be missing or ambiguous), it now uses the permanent channel ID. The change includes a database upgrade to convert old stored data. The commit message frames this as a robustness improvement, not a security fix, but the scenario it addresses—multiple channels lacking short IDs—could theoretically lead to mis-routing or incorrect handling of pending payments.

This commit adds a safety check to a Lightning Network function so it refuses to accept an empty or wrong-type channel identifier. The change is defensive: it turns a silent 'no match found' return value into an immediate crash if a caller accidentally passes an invalid identifier. There is no direct evidence in the commit that this fixes an active security vulnerability or real-world exploit.

This commit only adds explanatory comments (a docstring) to a data class used in Electrum's Lightning payment handling. It does not change any code behavior, fix any bug, or alter any security mechanism. There is no security issue here.

This is a one-line fix in Electrum's Lightning Network code. It adjusts when Electrum considers the first part of a trampoline payment 'complete' by subtracting JIT (just-in-time) channel opening fees from the amount being forwarded. Without the fix, a trampoline payment stage could be incorrectly marked complete too early, potentially causing accounting or routing issues. The commit message frames it as a bug fix, not a security issue, and no security impact is directly stated.

This commit fixes a bug in Electrum's Lightning payment handling for 'just-in-time' (JIT) channels. When a payment arrives through a JIT channel, the channel opener charges an opening fee. Previously, the code did not properly subtract this fee when checking whether the full payment amount had been received. This could cause multi-part payments to time out or fail even though the sender had sent enough money, because the receiver's accounting compared the raw amount received against the invoice total without accounting for the fee already taken by the JIT channel. The patch renames the fee field for clarity and deducts the JIT opening fee from the total before deciding whether the payment is complete.

This commit only changes how Electrum logs a message when the optional 'cryptography' Python package is missing. It does not change any actual security behavior: DNSSEC validation still fails and falls back to plain DNS, and OpenAlias still rejects unvalidated results. The change simply makes the missing-dependency warning more visible in logs.

This commit removes the ability to skip DNSSEC security checks for OpenAlias lookups in the Electrum Bitcoin wallet. OpenAlias turns human-readable names like 'donate@example.com' into Bitcoin addresses using DNS. Previously, users or commands could pass a 'nocheck' flag to accept unvalidated DNS results, which is dangerous because DNS responses can be spoofed or tampered with. The patch now enforces that DNSSEC validation must succeed before any OpenAlias result is used, and it strips out the old 'nocheck' options and unvalidated warnings. This is a hardening change that closes a known weak path where an attacker on the network could trick the wallet into sending money to the wrong address.

This commit adds a safety check in Electrum's Lightning 'onion message' forwarding code. Before passing an encrypted message to the next peer in the chain, Electrum now verifies that the peer actually advertises support for onion messages. Without this check, Electrum could forward messages to peers that do not understand them, which could leak information about the route, waste bandwidth, or cause protocol confusion. The change is small and defensive.

This is a one-line bug fix in Electrum's Lightning onion message forwarding code. The developer renamed a parameter from 'blinding' to 'path_key' when sending an onward onion message. The change aligns the code with a prior commit that renamed related concepts, and prevents the outgoing message from carrying the wrong/obsolete field name, which could cause forwarding to fail or behave incorrectly.

This is a small bug fix in Electrum's mobile-style QML user interface. A previous code change accidentally left OpenAlias payment addresses out of the list of recognized invoice types, so users trying to pay to an OpenAlias address (for example, a human-readable name like 'donate@example.com') would see an 'Unknown invoice' error instead of completing the payment. The patch simply adds OpenAlias back to the accepted list. It is a functionality regression fix, not a security vulnerability.

This commit fixes a Lightning Network compatibility bug in Electrum. Electrum nodes were refusing to exchange network routing gossip with Core Lightning (CLN) nodes because Electrum was not advertising a specific feature flag called OPTION_CHANNEL_TYPE_OPT in its baseline feature set. The fix moves that feature flag from the wallet-only features to the base features shared by all Lightning operations, including gossip. There is no direct security vulnerability here; it is an interoperability/availability fix.

This commit only adds a check in a test script to verify that a Lightning payment succeeds. It is a test-only change and does not modify any production wallet or Lightning code. The commit message says the test has been failing since an earlier commit, but it does not describe any security problem.

This is a small follow-up fix in Electrum's Lightning watchtower code. It ensures that when a channel closure no longer needs monitoring, the software stops watching the associated Bitcoin address. Without this cleanup, Electrum could keep polling or reacting to address updates indefinitely, wasting resources and potentially causing stale state or minor errors. The change itself is defensive housekeeping rather than a clear-cut vulnerability patch.

This is a minor change to a test script for the Electrum Bitcoin wallet. It stops a test wallet daemon before running a command and adds a flag to use a new session. There is no security issue here—it's purely a test reliability fix.

This commit adds comments and TODOs warning that the wallet code may be mixing up two different kinds of Bitcoin time locks: block heights and wall-clock timestamps. It also fixes some helper functions to explicitly return None instead of implicitly returning nothing. The commit itself says the issue 'seems harmless atm' but needs rethinking. There is no actual exploit shown, only a note that future checks are needed.

This commit fixes a bug in Electrum's Lightning watchtower code where an early exit was preventing the wallet from properly tracking certain closing transactions. The fix removes an unnecessary 'return early' check so that the wallet continues to process and account for these transactions. A new regression test checks that the closing transaction appears in the user's on-chain history even when it doesn't directly involve the user's wallet addresses. This is primarily an accounting/visibility bug, not a direct theft-of-funds vulnerability.

This is a small code cleanup in Electrum's Nostr Wallet Connect (NWC) plugin. The developer stopped modifying an incoming message object directly and instead passes the needed data as separate function parameters. The commit message says the goal is to make the underlying Event class immutable in the future. There is no direct security bug being fixed here, but the change removes a fragile pattern where error responses depended on whether the message had been previously altered.