Electrum

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.

This commit fixes a bug in Electrum's 'sweep' feature, which lets users move funds from a private key into their wallet. Previously, if the private key's address type was unsupported (like some multi-signature or older script types), the app would crash with a confusing internal error instead of showing a friendly message. The patch catches that case and shows a proper user-facing error. It also adds a small guard in the mobile/QML interface to avoid trying to build a sweep transaction before the inputs are ready.

This commit only adds Python type hints to function parameters and return values. It does not change any actual program logic, data handling, or security behavior. There is no security issue here.

This is a small user-interface bug fix. If a user deletes a payment invoice using the command-line while the graphical wallet window still shows it, clicking to view the deleted invoice previously caused the program to crash with an error. The fix simply checks whether the invoice still exists before trying to display it, and refreshes the list if it does not. There is no security vulnerability here.

This commit tightens a check in Electrum's submarine-swap code that pulls a secret 'preimage' from a Bitcoin transaction's witness data. Previously, the code only checked whether the witness existed; now it also requires at least two witness elements before reading the second one. This prevents an index-out-of-bounds read and makes the extraction more robust, especially for unsigned or unusually constructed transactions. It is a defensive hardening fix rather than a clear-cut exploitable vulnerability.

This commit fixes a bug in Electrum where an old-style wallet with a password would incorrectly accept a blank/empty password (None) as valid. The fix makes sure that if a wallet has a password, calling check_password(None) raises an InvalidPassword error instead of succeeding. This is a security-hardening fix for a regression introduced by an earlier change.

This commit fixes a bug in Electrum's wallet setup wizard that affected multisig wallets. When a user tried to enable (reactivate) a cosigner's key in a multisig wallet, the wizard did not correctly recognize the wallet as multisig, which could cause the operation to fail or behave incorrectly. The fix moves the multisig setup logic into the wizard's start routine so it always runs, and adds a regression test. There is no direct evidence this bug could be exploited by an attacker; it appears to be a functional regression that could confuse users or prevent normal wallet management.

This commit is a straightforward internal code cleanup in Electrum's setup wizard. It merges two ways of passing starting information into the wizard so that callers now supply a single 'WizardViewState' object instead of separate 'start_viewstate' and 'initial_data' arguments. There is no user-facing change and no security relevance visible in the diff.

This is a small code cleanup change. It makes the `start()` method of several wizard classes accept its `initial_data` argument only as a named (keyword) argument, not as a positional argument. This prevents accidental misuse and makes it easier for developers to see where initial data is actually coming from. There is no security vulnerability being fixed here.

This is a one-line bug fix in Electrum's fee warning logic. The app compares the user's chosen transaction fee rate against the network's minimum relay fee. Previously, because of how Python handles decimal versus floating-point numbers, very low fee rates (below 1 satoshi per virtual byte) could be compared incorrectly, potentially causing the warning not to appear when it should. The fix forces the relay fee to be treated as a precise Decimal so the comparison works correctly. The practical effect is mainly to ensure users get warned about fees that are too low to be relayed.

This commit adds a safety check and a test for Electrum wallet setup. It ensures that if a user tries to add a seed phrase that does not match an existing watch-only wallet's public key (xpub), the wallet raises a clear error instead of silently replacing the keystore. This prevents accidental or malicious mismatches between a seed and the wallet's expected public key.

This commit fixes a bug in the Electrum wallet where disabling a keystore (a container for private key material) accidentally wiped out important key metadata called 'key origin info.' This metadata tells the wallet where a key came from in a derivation path. Losing it could cause problems when the wallet later tries to sign transactions or interact with hardware wallets, because the wallet might not be able to reconstruct the correct key path. The fix changes the internal field name used when converting a keystore to a watch-only version, and adds tests to make sure the metadata survives.

This commit only updates test data in Electrum's test suite. It replaces fake/placeholder BIP39 seed phrases with the well-known standard test seed 'abandon abandon ... about' and updates the corresponding expected public keys and Bitcoin addresses. There is no change to production wallet code, no bug fix, and no security-relevant behavior change.

This commit removes the ability to enable or disable individual keystores in Electrum's two-factor authentication (2FA) wallets. The feature was already broken for these wallets, and the change hides the buttons in the user interface and makes the underlying methods raise errors if called. It is a hardening/cleanup change rather than a fix for an active security vulnerability.

This commit fixes a visual bug in Electrum's mobile-style QML interface where very low Bitcoin transaction fees (below 1 satoshi per virtual byte) could cause the fee histogram bar colors to loop around the color wheel and display misleading colors. It also rounds fee values to two decimal places for cleaner display. There is no indication this affects funds, transactions, or wallet security.

This commit is a minor user-interface tweak in Electrum's contact list. It changes which column expands to fill available window width: previously the contact name column stretched, now the address column stretches. There is no security relevance.