Electrum

This commit is a small follow-up to a previous change in Electrum's Lightning watchtower code. It changes how the wallet decides whether to keep monitoring certain transactions, allowing the code to say 'keep watching but don't sweep yet' instead of always requiring an immediate sweep action. The commit itself does not appear to fix a clear exploit; it is more likely a correctness or robustness improvement to avoid premature decisions.

This change tightens the user interface for Electrum's two-factor authentication (2FA) wallets. When a 2FA wallet user previews a new transaction, the buttons that let them sign or broadcast it are now hidden. The commit message says this makes it 'slightly less trivial to cheat with the fees.' In plain terms, it closes a small UI path that could let a user manipulate transaction fees in a way the trustedcoin two-factor service is meant to prevent.

This commit removes five lines of unused test-only code from a mock network class used in Electrum's Lightning peer unit tests. It is a routine cleanup with no effect on production software or user security.

This commit only adds a helpful note to the README explaining that the test suite can be run faster in parallel using a pytest plugin called pytest-xdist. It does not change any program code, fix any bug, or alter any security-related behavior.

This commit fixes a logic bug in Electrum's Lightning channel-sweeping code. Previously, if a payment hash was in a special 'do not settle yet' list used during JIT (just-in-time) channel opens, the wallet would simply ignore the related HTLC output instead of continuing to watch it. That could let an attacker or a forced channel close steal funds because the wallet might stop monitoring before it was safe to claim the money. The fix makes the watcher keep watching those outputs until either the condition clears or the HTLC's deadline expires.

This commit only wraps existing English user-interface text strings in Electrum's internationalization (i18n) function so they can be translated into other languages. It does not change program logic, security checks, wallet behavior, or transaction handling. There is no security relevance.

This commit simply removes an automated test that had become redundant because a newer test covers the same behavior more thoroughly. It does not change any production code, user-facing behavior, or security mechanism.

This commit only adds a new automated test to Electrum's Lightning networking code. It checks that a node configured not to settle certain HTLCs (payment promises) actually refrains from releasing the payment preimage, both as the final receiver and as a forwarding node. There is no change to production code, no bug fix, and no security patch in the diff itself.

This change fixes a bug in Electrum's Lightning Network code. Previously, when the wallet decided to reject (fail) an incoming multi-part payment, it would remove the payment hash from two internal safety lists. Those lists are meant to prevent the wallet from prematurely settling or letting the payment expire while it is still waiting for all parts. Removing the hash during a failure could cause a later part of the same payment to be settled or expired incorrectly, potentially leading to loss of funds or routing problems. The patch simply stops removing the hash when failing.

This commit fixes a bug in Electrum's Lightning Network payment forwarding. Normally, Electrum can mark certain payment hashes as 'do not settle' (dont_settle_htlcs), meaning it should not reveal the secret preimage that unlocks a payment. However, the old code would reveal that secret anyway when the payment was being forwarded through the node, not just when the node was the final recipient. The fix checks the 'do not settle' list before releasing the preimage, even during forwarding.

This commit fixes a bug in Electrum's Lightning invoice handling where an invoice with no expiry date could be stored with an expiry of 0 seconds. In Electrum, 0 seconds means 'no expiry' in some places, but the Lightning code expects a special 'never expire' value (100 years) instead. The bug caused an internal assertion to fail, which could crash the wallet or make incoming Lightning payments fail unexpectedly. The fix replaces 0 with the proper 'never expire' value when creating payment information.

This commit is a tiny user-interface tweak: it makes a Lightning Network status button slightly wider so that its percentage text (shown while syncing network gossip) is not cut off and displayed as '...'. There is no security issue here.

This commit adds a small Android-only workaround so that a cryptography library (pycryptodomex) can load correctly inside the Electrum mobile app. It replaces the way Python finds its own C API with an explicit path to the Python shared library. There is no direct security vulnerability here; it is a compatibility patch for a packaging/toolchain issue. However, it is a 'hack' that touches low-level Python internals, so it could in theory affect app stability or future updates.

This commit changes the Android build recipe for the Electrum Bitcoin wallet. It swaps one cryptographic library (cryptography) for another (pycryptodomex) because the old library could not be built with newer OpenSSL and the newer version is hard to compile. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a build-maintenance change.

This commit updates the version of OpenSSL used to build the Electrum Android app from an older 1.1.1 series to the newer 3.0.18 series. OpenSSL is the widely used encryption library that secures network connections. The older 1.1.1 branch reached its official end-of-life in September 2023, meaning it no longer receives security fixes. Moving to a supported 3.0.x release is a routine maintenance step that reduces long-term security risk, but the commit itself does not claim to fix any specific known vulnerability.

This commit simply updates a required library version from 0.0.11 to 0.1.0 in Electrum's dependency files. There is no code change shown, and no information is provided about why the library was updated or whether the new version fixes any security issue. On its own, this commit is just a routine build/dependency bump.

This commit fixes a bug in how Electrum reads transaction files. Previously, the program would strip whitespace from both text and raw binary transaction data. For binary data, this is dangerous because a byte that looks like a space or newline can legitimately appear in a transaction. The fix reads text files as text (and strips whitespace) and binary files as raw bytes (without altering them). This prevents certain unusual but valid transactions from being corrupted when loaded from a file.

This commit tightens how Electrum cleans up transaction data before parsing. Previously, when given raw transaction bytes, the code would strip out any byte that looked like whitespace (such as tab or newline bytes). That is risky because a real Bitcoin transaction can legitimately contain bytes like 0x0a (which looks like a newline). The fix only removes whitespace from text strings, and only trims leading/trailing whitespace from byte inputs. It also improves an error message so raw bytes are shown safely. This is a defensive hardening change that prevents possible transaction misparsing or crashes, but the commit itself does not claim a specific exploit.

This is a tiny code cleanup in Electrum's transaction handling. The change removes a check that accepted bytes for a hex-encoded PSBT, because Python's bytes.fromhex() only accepts strings anyway. The commit message explicitly says there is no functional change except that bad input now raises a slightly different error. There is no security issue here.

This commit only adds a new automated test for an existing function called decode_short_ids in Electrum's Lightning network code. It does not change any production code, fix a bug, or introduce new behavior. There is no security issue here.

This commit adds a length check to a function that decodes Lightning network channel identifiers from peer messages. Previously, if a peer sent a malformed list whose byte count was not a multiple of 8, the function would silently produce partial or misaligned identifiers. The change now rejects such inputs and may warn or disconnect the peer, following the Lightning protocol spec.

This commit removes the ability of Electrum's Lightning peer code to decompress routing data using zlib. The change follows an updated Lightning protocol rule (BOLT 7) that says uncompressed routing data must be used. Keeping zlib support could, in theory, allow a malicious peer to send a specially crafted compressed payload that causes crashes, excessive memory use, or other unexpected behavior. The patch is straightforward and defensive, but it is a partial removal: it only stops accepting compressed data and does not add broader input-size checks.

This commit changes how Electrum cleans up raw Bitcoin transaction text that users paste into the wallet. Previously it only trimmed whitespace from the beginning and end. Now it removes all whitespace characters (including newlines and spaces) anywhere inside the string. This is a usability fix for copy-pasting transactions from documents such as a timelock recovery PDF. It is not a security patch, but it slightly reduces the chance that a malformed or trick pasted transaction could behave unexpectedly.

This commit fixes a bug in Electrum's wallet setup wizard where unplugging a hardware wallet during the encryption step could crash the application by opening an error-report dialog. The fix catches the expected error gracefully, shows a friendly message, and lets the user retry instead of triggering the crash reporter.

This commit is a code-quality and performance fix in Electrum's Lightning Network code. It replaces calls to `lnworker.channels` and `lnpeer.channels`—which make full thread-safe copies of the channel dictionary—with direct lookups using existing helper methods or the internal `_channels` dictionary. The stated goal is to avoid unnecessary copying. There is no direct evidence in the commit that this fixes an exploitable security vulnerability, but it reduces the risk of race conditions or inconsistent state that could theoretically affect Lightning payment handling.