Electrum

This commit fixes a data-format bug in Electrum's Lightning onion-message handling. The number of hops in a 'blinded path' was being stored as a plain integer, but the protocol expects a single byte. The patch changes it to a bytes object. A second change only improves an error message when no reply path can be created. The fix is small and appears to prevent interoperability or parsing problems rather than a direct theft-of-funds vulnerability.

This commit only adds extra information to log messages when Electrum sends a Lightning payment. It does not change any payment logic, permissions, or security behavior. One log line now includes the payment hash, and another debug log records whether the payment uses a legacy trampoline relay. There is no security issue visible in the diff.

This commit fixes a bug in Electrum's command-line 'payto' command where a transaction fee rate typed in as text (a string) was being incorrectly handled. The old code tried to multiply the text string by 1000, which in Python repeats the string instead of doing math, producing a wildly wrong fee policy. The fix converts the string to a number (Decimal) first, then multiplies. This could cause users who set a custom fee rate via the CLI to get an absurdly large or malformed fee value, potentially overpaying fees or having transaction creation fail.

This commit adds a safety check in Electrum's Lightning code to block a 'trampoline inside trampoline' payment routing scenario. The developer states they don't want to reason about what could go wrong without this guard. The current code already uses fixed-size onions that would likely prevent the nested case, but a future protocol change may allow variable-size trampoline onions, so this assert is added defensively.

This commit fixes a memory leak in Electrum's keystore code. Previously, a caching decorator on key-derivation methods kept a permanent reference to each keystore object, preventing them from being cleaned up by normal garbage collection. The change moves the cache to live inside each keystore object, so when a keystore is no longer needed, its cache is discarded too. This is a reliability/performance bug fix rather than an active security vulnerability, though unbounded memory growth can degrade or destabilize long-running processes.

This commit simply updates the versions of two code-linting tools used in Electrum's automated testing pipeline and adjusts which style/error checks are enabled or ignored. It does not change any wallet, networking, or cryptographic code that end users rely on. There is no indication this introduces or fixes a security vulnerability.

This commit is a small code cleanup in Electrum's Lightning Network message handling. It replaces explicit uses of Python's read-only dictionary wrapper (MappingProxyType) with the more general Mapping type hint in function signatures and dataclass fields, while still using MappingProxyType internally as the default factory. The change does not alter runtime behavior or fix any security issue.

This commit only adds a new automated test to Electrum's test suite. It creates a sample Bitcoin transaction that mixes older-style (non-SegWit) and newer-style (SegWit) inputs, then verifies that the wallet can sign it correctly offline. There is no change to the actual wallet or server code, and nothing is being fixed or patched.

This commit is a purely cosmetic change to the mobile/QML version of Electrum. It adjusts the color-coding of a mempool fee histogram so that very low fee rates (below 1 satoshi per virtual byte) are shown as darker shades rather than all looking the same. There is no security relevance.

This is a small code cleanup in Electrum's mobile/QML invoice screen. It stores the invoice status in a local variable so the code doesn't repeatedly ask for the same value. There is no visible security fix; it appears to be a minor maintainability or race-condition-hardening change.

This commit simply adds a README file explaining what the scripts folder contains. It is documentation only and does not change any code, security behavior, or functionality.

This is a one-line bug fix in Electrum's Lightning Network routing code. A method that tracks how many pending payments (HTLCs) are flowing in the backward direction was accidentally using the forward-direction counter. This could cause the backward counter to become inaccurate, potentially leading to poor routing decisions, stuck payments, or denial-of-service-like effects for Lightning payments. It is a logic bug rather than a cryptographic flaw, and no direct theft of funds is evident from the diff alone.

This commit is a defensive code-hardening change, not a fix for an active security flaw. It makes two internal data structures used in Lightning Network onion routing immutable (unchangeable after creation) so they can be safely cached and shared without accidental or malicious modification. There is no direct evidence in the commit that this change fixes a known exploitable vulnerability.

This commit fixes two bugs in Electrum's experimental Lightning 'onion message' forwarding feature. First, it correctly handles larger onion message packet sizes, which previously could have caused processing errors. Second, it ensures 'dummy hops' (decoy routing steps used for privacy) are processed even when the separate 'forward payments' experimental option is turned off. Before the fix, turning off payment forwarding could accidentally break onion message routing through dummy hops.

This commit fixes a small but real bug in Electrum's handling of private Lightning-style 'onion' messages. When a message uses a hidden route with only one intermediate hop, the software could receive that hop as a single object instead of a list, causing later code to crash or behave unexpectedly. The patch forces it to always be treated as a list. The most likely effect without the patch is a local error or failed message delivery, but in the worst case it could be abused to make the wallet mishandle a message.

This is a one-line change in a test file, renaming a dictionary key from 'blinding' to 'path_key' to match what the production code now expects. It does not change any production code and has no direct security impact on users.

This commit is a straightforward renaming of internal variable and wire-format field names to match a recent update in the Lightning BOLT04 specification. Terms like 'blinding' are replaced with 'path_key', and 'next_blinding_override' becomes 'next_path_key_override'. No logic, cryptography, or behavior changes are visible in the diff.

This commit is a straightforward internal code cleanup in Electrum's Lightning payment logic. It splits a large method into a smaller helper method and changes how a successful payment exits the loop, without altering what the program actually does. There is no indication this fixes a security bug or introduces a vulnerability.

This commit only adds new automated tests to Electrum's test suite. It does not change any production code, so it cannot by itself introduce a security vulnerability or fix one. The tests appear to verify that a specific data-handling edge case behaves correctly: when a parent object is removed from the wallet database, modifying a child object that was previously under it should not generate extra database change records. The commit message links this to issue #10000, but no details of that issue are provided.

This commit is a code cleanup that moves data-conversion logic out of a low-level dictionary class and into a dedicated database module. It also changes one place where metadata is stored so it is first converted to plain JSON. The changes appear to be architectural refactoring rather than a fix for an active security bug, but the patch is partial and the commit message does not explain the full motivation.

This commit rewrites how Electrum's JSON database tracks nested data. Instead of each object remembering its full 'address' (path) inside the database, it now remembers only its own key and a pointer to its parent. When a branch of data is removed, the parent pointer is cleared so the object knows it is no longer part of the database. The change is described as fixing issue #10000 and passing the json_db tests. It is a defensive refactor that reduces the risk of stale objects writing updates for paths that no longer exist.

This commit adds validation to Electrum's server communication layer. It now rejects invalid block heights (below -1) and, for newer server protocol versions, requires that unconfirmed ('mempool') transactions be returned in a specific predictable order. The goal is to expose servers that don't follow the protocol correctly, which helps Electrum detect misbehaving or malicious servers rather than silently accepting inconsistent data.

This commit changes three internal warning messages so they are printed to the error stream instead of the normal output stream. The goal is to keep Electrum's command-line JSON output clean and valid when these warnings appear. It is a minor reliability/usability fix, not a security patch.

This is a small internal code cleanup. A function that registers command names is changed so callers explicitly provide the name, rather than the function deriving it from the function's own name. The commit message says this lets plugins reuse existing command names without triggering a false 'name collision' error. There is no security fix here—just a refactor to avoid an overly strict uniqueness check.

This commit is a minor user-interface tweak for the Electrum desktop wallet's 'Send' tab. It changes the label text from 'Pay to' to 'Pay to many' when the user enables the bulk-payment option, and adjusts the label's vertical alignment. There is no security relevance.