Electrum

This commit is a small internal cleanup in Electrum's transaction batching code. It changes how sweep inputs are tracked—from using string-based keys to using proper transaction-outpoint objects and lists. The change appears to prevent a potential mismatch or bug where the wrong input could be removed from a batch, but it is not a clear, exploitable security vulnerability on its own. It is more likely a correctness/robustness fix.

This is a tiny one-line fix in Electrum's Lightning code. A helper function that looks up groups of related payments now returns an empty list instead of 'None' when nothing is found. This mainly prevents other code that expects a list from mishandling the result, which could reduce bugs or minor errors but is not a clear security vulnerability on its own.

This commit fixes a formatting bug in Electrum's command-line output where very small bitcoin amounts were displayed in scientific notation (like '1E-8' instead of '0.00000001'). This is a usability and correctness fix that makes wallet balances and transaction values display consistently. It is not a direct security vulnerability, but scientific notation in financial outputs could theoretically confuse users or downstream scripts that parse amounts.

This commit is a minor code-quality change. It adds a clarifying comment to a payment-batching helper, makes a type annotation more specific, and adds a hash method to a transaction output class so outputs can be used in sets or as dictionary keys. There is no security fix or behavior change visible in the diff.

This commit changes how Electrum's submarine swap server reports errors back to clients over Nostr. Previously, the server sent the first 100 characters of the actual exception message, which could leak internal details such as file paths, variable names, or other server-side information. Now it only sends the exception type (for example, 'ValueError') with a generic 'Internal Server Error' label. This is a hardening fix that reduces information disclosure but does not by itself stop an attacker from exploiting the underlying bug that caused the exception.

This commit adds a speed bump to Electrum's submarine swap server. Previously, every incoming Nostr swap request was handled immediately in the message-reading loop, which could let an attacker flood the server with requests and potentially exhaust resources or cause errors. Now requests are placed in a small queue (max 5) and processed only once every 5 seconds, with extra requests dropped. This is a defensive rate-limiting patch, but the commit message does not call it a security fix and no external advisory is provided.

This commit only updates a test script for Electrum's regression testing. It changes how a test command calls the reverse-swap feature by adding an explicit provider mining fee argument taken from a prior dry-run. There is no change to production wallet code, no user-facing behavior change, and no security fix or vulnerability evident.

This commit only adds a new automated test for an existing command in Electrum. It does not change any production code, fix a bug, or alter behavior visible to users. There is no security relevance.

This commit adds a new Electrum command that lets users discover submarine swap providers over the Nostr peer-to-peer network. It also adds safety checks so users must configure a provider before performing swaps, and replaces an indefinite wait with a 15-second timeout. There is no obvious vulnerability in the diff itself; it is a feature addition with minor hardening.

This commit fixes a bug in Electrum's transaction batching code that could accidentally delete a transaction that had already been sent to the Bitcoin network. If the Electrum server was slow, unresponsive, or dishonest, the wallet could think a payment was never broadcast, remove it from local records, and then create and send a second payment for the same thing—effectively paying twice and losing funds. The fix stops the wallet from automatically removing 'local' transactions in two risky situations and instead tries to rebroadcast them safely.

This commit adds a disk-space cap for Electrum's debug log files. It changes how old logs are cleaned up on startup and switches the active log file to a rotating handler so individual files cannot grow without bound. There is no direct security vulnerability being fixed; it is a hardening/operational improvement to prevent logs from filling up the disk.

This commit fixes a small user-interface bug in Electrum's command-line reverse-swap command. It makes the provider_mining_fee argument optional during a 'dryrun' preview, and corrects a typo in an error message. There is no direct evidence this is a security vulnerability.

This commit tightens how Electrum handles reverse submarine swaps (a way to move funds from Lightning back to on-chain Bitcoin). Previously, the swap code relied on the current provider fee stored in memory, which could change between the moment the user saw a quote and the moment the swap was executed. The patch makes the GUI and command-line pass the exact mining fee the user was shown into the swap logic, and adds a sanity check that the provider cannot charge more than twice that shown fee. This reduces the risk of a malicious or misconfigured swap provider surprising the user with unexpectedly high fees right before the swap completes.

This commit adds a safety guard for Electrum's submarine swaps. Before finalizing a swap, the wallet now checks whether the fees/costs look wildly unreasonable (for example, losing more than 25% of the amount, or over 1 million satoshi in absolute terms). If the costs look insane, the wallet stops and shows the user an error instead of proceeding. The change is defensive and does not appear to fix a known exploited bug, but it reduces the risk of a malicious or misconfigured swap server causing the user to lose funds.

This commit tightens how Electrum handles upfront 'prepayment' invoices for submarine swaps (a way to exchange on-chain and Lightning bitcoin). Previously the client calculated the prepayment using a local transaction-batcher fee estimate and had no check on what the swap server actually charged in its fee invoice. The patch switches the prepayment calculation to a known 'mining_fee' value and, crucially, rejects the swap if the server's fee invoice exceeds twice that announced mining fee. This closes a path where a malicious or buggy swap server could demand a larger prepayment than the user expected.

This commit adds a cap on how many incoming Lightning Network peers without channels can connect to an Electrum node at once. Before this change, an attacker could potentially open unlimited incoming peer connections, consuming memory, CPU, and network resources and possibly disrupting normal operation. The fix limits such peers to 100 and closes new connections once that limit is reached. It also fixes a related bug where an existing initialized peer connection was not being closed when a duplicate arrived.

This commit tightens how Electrum's Lightning peer handler accepts and queues certain ordered messages. It caps per-channel message queues at 10 entries, rejects ordered messages for unknown channels, and limits a temporary-channel tracking dictionary that previously grew without cleanup. These changes reduce the risk that a malicious or misbehaving peer could exhaust memory or fill queues to disrupt the node.

This commit adds a rate limit to how many unsolicited or rapid 'reply_channel_range' messages Electrum will accept from a Lightning peer. Previously, the queue that stores these replies was always created when the peer object was set up, so a remote peer could keep sending replies even when Electrum never asked for them, potentially filling memory or causing the program to fall behind. Now the queue is only created while Electrum is actively waiting for a reply, and if too many replies pile up the code slows the peer down. This looks like a hardening fix against a denial-of-service or memory-pressure issue, but the commit message does not call it a security fix.

This commit adds a speed limit and queue cap for Lightning network gossip messages received from peers. Before the change, a malicious or misconfigured peer could flood an Electrum node with unbounded gossip traffic, potentially consuming memory and CPU and slowing or crashing the program. The patch bounds the queue size, slows processing when the queue grows, and disconnects peers that overflow it. It also clarifies whether gossip was requested by us versus sent unsolicited by the peer.

This commit tightens how Electrum's submarine-swap client matches Nostr direct-message replies to the requests it sent out. Previously, the client keyed pending replies only by the original event ID. That could let a malicious or misconfigured relay/peer inject a reply from a different swap server and have it accepted. The patch now also checks the reply author's public key, so replies are only accepted from the server that was actually asked. It is a defensive hardening fix rather than a complete exploit chain.

This commit changes how Electrum's submarine swap feature tracks expected direct-message replies from Nostr relays. Previously, accessing any unknown reply ID would automatically create a placeholder 'Future' object. Now, only the client creates a Future for a specific request it sent, and only the client resolves replies, with checks that the reply ID is known. This prevents a potential issue where a malicious or buggy relay/server could create or manipulate placeholder reply entries by sending crafted messages.

This commit hardens how Electrum parses data received from external swap servers and Nostr direct messages. It adds type checks so that fields that should be dictionaries, integers, or valid Bitcoin addresses are rejected if malformed. Without these checks, a malicious or compromised swap server could send unexpected data types (for example, a string where a number is expected, or a non-address string as a lockup address) that might cause crashes, incorrect transaction construction, or potentially trick the wallet into sending funds to the wrong place. The commit does not fix a single known exploit; it is a broad defensive-hardening patch.

This commit improves how Electrum's submarine-swap feature handles network timeouts when sending direct messages over Nostr. Previously, a timeout while publishing a swap offer or sending an encrypted request could crash or hang the process. Now the code catches the timeout, logs a warning, optionally retries, and returns None if it still fails. Callers are updated to raise a proper SwapServerError instead of hanging. This is a robustness fix rather than a fix for a clear exploitable vulnerability.

This is a tiny code cleanup in Electrum's fee-estimation logic. It replaces a hard-coded number (100) with a named constant (FEERATE_PRECISION) when rounding Bitcoin transaction fee rates. The math stays the same because the constant value is 2, so 10**2 equals 100. There is no obvious security issue here; it is a maintainability/refactoring change.

This commit adds an early exit in Electrum's Lightning watchtower code so it stops trying to sweep a closed channel if the channel reports it no longer needs monitoring. Without this guard, the watcher could continue running sweep logic on a channel that has already been settled or is otherwise inactive, potentially causing unnecessary on-chain transactions, wasted fees, or confusion in recovery flows. The change is small and defensive.