Electrum

This commit only changes a test script. It adds a wait helper so a test that opens two Lightning channels in a row does not fail randomly on continuous integration. There is no change to Electrum's actual wallet or Lightning code, so users are not affected.

This commit is a small internal code cleanup in Electrum's Lightning wallet. It renames a method and changes it to accept feature flags as an input rather than generating them itself. The actual logic for deciding which feature flags are included in an invoice remains unchanged. There is no indication this fixes a security bug or introduces a vulnerability.

This is a small bookkeeping update in Electrum's Lightning Network code. It adds two already-supported Lightning features to a master list of 'implemented features' and adds a comment reminding future developers to keep that list in sync. There is no direct security fix, but keeping the feature lists consistent helps prevent future protocol confusion or misadvertised capabilities.

This commit adds a small helper method that converts Lightning Network feature flags into a compact byte format used in modern Lightning protocol messages. It is a routine, additive code change with no security relevance visible in the commit or supplied references.

This commit refines how Electrum checks Lightning network feature flags so that the rules for what one feature requires can differ depending on where it appears (e.g., an old BOLT11 invoice versus a newer BOLT12 invoice). The main user-visible change is that BOLT12 invoices can advertise multi-part payment support (BASIC_MPP) without also advertising payment_secret, which was previously required. This is a protocol-correctness change rather than a clear-cut security fix, but it removes a validation rule that could have caused BOLT12 invoices to be wrongly rejected.

This commit simply adds two new named constants for an existing Lightning network feature (route blinding/blinded paths) to Electrum's internal feature-flag list. It does not change any active code paths, parsing logic, or security behavior. It is a preparatory or compatibility-only change.

This commit is a straightforward code cleanup and preparation for future BOLT12 (a newer Lightning Network invoice standard) support. It renames the existing 'INVOICE' feature context to 'BOLT11_INVOICE' and adds new context labels for BOLT12-related features. There is no security fix or vulnerability present in the diff.

This commit updates Electrum's Trezor hardware wallet plugin to work with a newer version of the trezorlib library (0.20.1). It rewrites how Electrum opens sessions with Trezor devices, especially when passphrases are used. The change is a routine dependency upgrade, but it touches sensitive code that handles private keys and device unlocking. There is no direct evidence in the commit that this fixes a known security vulnerability, but any bug in session or passphrase handling could in principle affect wallet security.

This commit changes Electrum's internal build tooling. It introduces 'ghost packages'—empty placeholder packages used only during the build process to satisfy dependency resolvers—so that certain unwanted dependencies can be excluded from final deterministic builds. The change also makes a helper script read package metadata from the local build environment instead of downloading it from PyPI. There is no direct evidence in the commit that this fixes an active security vulnerability; it appears to be a build-hygiene improvement.

This commit fixes a build/packaging problem in Electrum's bundled desktop releases (AppImage, Windows, macOS). A newer version of the Trezor hardware-wallet library now needs its package metadata files to be present, otherwise it cannot report its version and Electum wrongly treats it as incompatible. The change simply includes those metadata files in the bundled app. It is a reliability fix, not a security vulnerability patch.

This commit simply moves the StoredDict, StoredObject, StoredList, and related helper code from one file (json_db.py) into a brand-new file (stored_dict.py). It then updates other files to import from the new location. The commit message and the diff itself show no changes to how the code works—only where it lives. There is no security fix or vulnerability introduced here.

This commit only changes the internal instructions used by Electrum's automated code-review system. It tells the AI reviewer to double-check that commits claiming to just move code around don't secretly change behavior. No actual wallet, network, or cryptographic code was modified, so users are not directly affected.

This commit changes Electrum's internal CI (continuous integration) script that runs an automated code review using Claude. It simply adds the git commit messages of a pull request into the prompt sent to Claude, so the AI has more context. It does not touch any wallet, networking, cryptography, or user-facing code, and there is no security issue in the change itself.

This commit changes a single user-interface label in Electrum's mobile/QML app from 'Remote Pubkey' to 'Recipient Pubkey' when displaying a Lightning invoice. It is purely a wording/translation clarity improvement and does not alter any code behavior, cryptography, network handling, or security logic.

This change fixes a test helper script so that if a Bitcoin command-line tool fails, the failure is properly noticed and the test stops. It only affects internal regression tests, not the Electrum wallet that users run. There is no direct security risk to end users.

This commit only adds a new automated test for a successful forward cryptocurrency swap and renames an existing reverse-swap test. It also adds a minor code comment noting an inconsistent field name. There are no user-facing changes and no security fixes or vulnerabilities are present in the diff.

This commit only adds a code comment (a 'FIXME') noting a race condition in Electrum's SOCKS proxy handling. The actual behavior is not changed. The race could mean that when Electrum is still checking whether a proxy is a Tor proxy, it might incorrectly reuse Tor circuits instead of waiting for the check to finish. This is a potential privacy/ anonymity concern for users routing traffic through Tor, but no exploit or direct fund theft is evident from the diff alone.

This change makes Electrum's Lightning peer re-send its channel fee and routing rules to a peer whenever the connection is re-established, not just when the channel first opens. This helps peers know the current rules so payments can be received reliably. It is a protocol robustness improvement, not a fix for an active exploit.

This commit fixes a bug where Electrum could write unencrypted private keys to disk while creating or restoring a wallet, even when the user asked for password protection. The change rearranges the wallet setup so that the keystore is encrypted before it is placed into the wallet database, and the database storage is encrypted before any writes happen. It also moves the address-import step to happen after the keystore is saved, reducing the chance of plaintext key material touching disk.

This commit fixes a programming bug where the order of logical checks was wrong, causing Electrum to ignore all recently-used Lightning peers when no Tor proxy was configured. The fix makes the code correctly check whether the active proxy is a Tor proxy before deciding whether to skip onion-address peers. This is a connectivity bug rather than a direct theft or remote-code vulnerability, but it could make users' Lightning connections behave unexpectedly or prefer less optimal peers.

This commit only updates a documentation file (Readme.md) for Android build instructions. It adds advice about clearing build caches when developers don't see their changes take effect or encounter confusing build failures. There is no code change and no security relevance.

This commit is a simple code cleanup: it extracts a small, repeated calculation into a shared helper function. The math used to derive the next blinding key is unchanged, and there is no indication of a security fix or behavior change.

This commit is a routine code cleanup in Electrum's mobile/QML user interface. It replaces two background threads with lightweight coroutines (async functions) for broadcasting Bitcoin transactions and paying Lightning invoices. There is no indication this change fixes or introduces a security vulnerability.

This commit fixes a minor user-interface timing bug in Electrum's mobile/QML invoice view. When paying a Lightning invoice, two internal notifications could arrive in different orders, causing the screen to briefly or incorrectly show 'This invoice was already paid' instead of 'Paid!'. The fix tracks whether the payment was started in the current session so the right message is always shown. There is no security issue here—only a confusing label.

This change adjusts how Electrum's Lightning peer shares routing information. Previously, the wallet only sent a 'channel update' (the data peers need to route payments through a channel) for public channels. Now it also sends that update for private channels when the user has enabled payment forwarding. This is a bug fix for routing functionality, not a security vulnerability, but it touches sensitive Lightning gossip logic.