Electrum

This commit adds a basic sanity check to Electrum's code that reads the built-in list of default servers (servers.json). Previously, if a user edited that JSON file incorrectly, the bad data would travel deeper into the program and cause a confusing crash later. Now the code checks early that each server entry is a dictionary and that all values inside it are strings, failing fast with a clearer error message. It is a hardening/quality improvement, not a fix for an externally exploitable vulnerability.

This commit adds data definitions for BOLT12 (a newer Lightning Network protocol for offers and invoices) to Electrum's wire format specification file. It is purely a schema addition with no executable code changes, no bug fixes, and no security behavior changes.

This commit only adds a new test file and a unit test for BOLT 12 merkle root calculation. It does not change any production code, so it cannot introduce a security vulnerability or fix one. It is purely a test-suite addition.

This commit fixes a bug in Electrum's Lightning Network message parser. When reading nested structured data, the parser could keep consuming more bytes than intended because it didn't stop after reaching the expected number of items. The fix makes it stop at the right count and raises an error if too few items are found. This is a correctness fix that likely prevents malformed or crafted Lightning messages from being misinterpreted.

This commit adds a safety check in Electrum's Lightning message parser to reject invalid cryptographic 'points' (public-key-like values) instead of silently accepting them. Previously, malformed points could pass through parsing and potentially cause problems later. The change is defensive and aligns with official BOLT12 test vectors that expect invalid points to be rejected.

This commit adds new Lightning Network message handling code to Electrum. It introduces a new BIP-340 Schnorr signature field type, computes Merkle roots over TLV (type-length-value) records, signs and verifies those roots, and adds implicit UTF-8 encoding/decoding for text fields. The changes are a feature addition to support BOLT12-style offers/invoices rather than a fix for a known vulnerability. There is no direct evidence in the commit or supplied references that this patch itself creates or fixes a security bug, but any new cryptographic signing code carries implementation risk.

This commit is a straightforward internal code refactor. It moves the user-interface code that handles 'submarine swaps' (a way to exchange on-chain Bitcoin for Lightning funds, or vice versa) out of the Qt desktop dialog and into a shared module so it can later be reused by the QML mobile-style interface. It also adds explicit initialize/destroy lifecycle methods to the swap server connection class. There is no indication this change fixes a security bug or introduces a new vulnerability.

This commit simply moves an existing helper function from the Qt user-interface layer into the core swap-management module. The code's behavior is unchanged; it is a routine internal refactoring with no visible security implications.

This commit is a small internal code cleanup in Electrum's submarine swap feature. It moves a 'future' object (a handle for an in-progress network connection attempt) from the transaction dialog class into the swap transport class itself. There is no user-facing behavior change and no indication of a security fix.

This commit is a straightforward code cleanup: it moves the logic that decides what message to show users about 'sending change to Lightning' from the Qt GUI dialog into a shared backend module. The visible behavior is essentially unchanged, and there is no indication of a security fix or vulnerability.

This commit is a performance optimization, not a security fix. It adds an in-memory cache of which outgoing invoices are already paid, so Electrum can skip expensive re-scanning of previous transaction outputs when many invoices share the same Bitcoin address. The goal is to stop the user interface from freezing for seconds or minutes when broadcasting a transaction. There is no indication this change fixes a vulnerability or changes security-critical behavior beyond making status lookups faster.

This commit removes one unnecessary screen refresh in Electrum's Qt send tab after a payment is broadcast. It is a performance cleanup, not a security fix. The removed line caused the entire invoice list to rebuild, which could freeze the user interface on wallets with many invoices. Other existing update paths already refresh the affected rows, so the removed call was redundant.

This commit is a simple code cleanup: it moves two definitions (a storage encryption version enum and a read/write error exception) from one file to another and updates the import statements in the files that use them. There is no functional change, no bug fix, and no security relevance.

This commit is a simple internal code cleanup. It adds a new helper method called get_path() to the wallet storage class and updates various parts of the program to use that method instead of reading the storage path directly. There is no security fix or vulnerability here.

A developer left a FIXME note in Electrum's Lightning code warning that a feature called 'zeroconf' channels marks a payment channel as funded before actually checking that the funding transaction exists or contains the required multisig output. The commit does not fix the issue; it only documents the concern. The note explicitly says this is unsafe and must be reworked before mainnet use, suggesting the current code could let a malicious or buggy peer make Electrum believe money was locked in a channel when it really wasn't.

This commit adds a check so that if a Lightning channel is funded by a coinbase transaction (newly created bitcoins from mining), Electrum waits for the standard 100-block maturity period before treating the funding as settled. Before this change, Electrum might have accepted an immature coinbase funding transaction too early, which could lead to an invalid channel state or forced channel closure if the coinbase output later becomes invalid or reorganized. The fix follows a recent update to the Lightning protocol specification.

This commit fixes a bug in Electrum's Lightning code where the program sometimes picked the wrong type of peer when building private 'blinded paths' for messages or payments. Before the fix, a path meant for an onion message could accidentally require a payment-related feature, and a path meant for a payment could accidentally require a message-related feature. The patch makes the feature check match the actual purpose, and raises clear errors when no suitable peer exists instead of silently returning an empty path. It is a correctness fix that reduces the chance of failed or misrouted private routes, but the commit itself does not describe it as a security fix and no exploit is demonstrated.

This commit fixes a design bug in Electrum's Lightning onion-message routing. Previously, the app used a fake payment amount (10,000 millisatoshis) when finding a route for an onion message, which could cause it to reject valid message paths because real channels have minimum/maximum amount limits. The change lets onion-message pathfinding ignore those amount limits, since no actual money is being moved. It is a correctness/availability fix for a messaging feature, not a fix for theft of funds or remote code execution.

This commit changes how Electrum routes private 'onion messages' through the Lightning Network. For users on 'trampoline' payment setups, it now sends messages via a randomly chosen trampoline peer and trusts that peer to forward the message to the final recipient. The change removes some safety checks that previously required an active channel or a known network path, and it uses Python's standard random module to pick the trampoline peer. This could make message delivery less reliable or more predictable, and it shifts trust onto trampoline nodes, but it does not appear to be a direct theft or remote-code-execution vulnerability.

This change makes Electrum's Lightning onion-message code more resilient: when the wallet wants to publish a blinded payment path through one of its channels but lacks the remote peer's latest channel policy, it now skips that channel instead of crashing. The most likely user-visible effect before the fix was an unhandled exception that could prevent creating or advertising blinded paths, possibly breaking offers/receive functionality. There is no direct evidence in the commit that this was exploitable by an attacker to steal funds.

This commit fixes a small timing buffer in Electrum's Lightning blinded-path payments. When Electrum advertised a hidden payment route, it told senders exactly how many extra blocks to reserve for safety. The problem is that new blocks can be mined while a payment is still traveling through the network. If the advertised safety margin was too tight, a payment could arrive with an expiry that is technically too close to the current block height, causing the payment to be rejected or stuck. The fix adds a 3-block buffer to the advertised safety margin so that normal mining delays don't cause failures.

This commit changes how Electrum tracks where certain data objects live in the wallet database. It switches from short names like 'invoices/*' to full paths like '/invoices/*', and updates the internal registry to handle these full paths. The stated goal is to prevent naming collisions and to enable future performance improvements. There is no direct evidence in the commit that this fixes an active security vulnerability, but path-collision bugs in serialization code can sometimes lead to wrong data being read or written, which could have security implications.

This commit is a simple code cleanup: it moves a block of code that builds payment information for blinded payment paths into its own helper function. There is no change in behavior visible to users or attackers. It is a refactoring, not a security fix.

This change makes an Electrum NWC (Nostr Wallet Connect) server re-announce its capabilities to Nostr relays once per day. Previously it only announced once at startup, and some relays were dropping these announcements after a few days, causing wallets like Alby to stop working until the server was restarted. There is no security vulnerability here; it is a reliability fix for a wallet-connect plugin.

This commit rewrites how background tasks are managed inside Electrum's Nostr Wallet Connect (NWC) plugin. Previously, the plugin and the NWC server shared one task group, which could accidentally cancel an in-flight Lightning payment when the server restarted its event handler. The change gives the NWC server its own temporary task group and shields active payment tasks from cancellation. It is best read as a reliability/robustness improvement that likely closes a small window where a payment could be interrupted, not as a fix for a clear-cut remote exploit.