Electrum

This commit only adds extra checks to existing automated tests and slightly expands test data. It does not change any production code, wallet logic, or network behavior. There is no security issue here.

This commit only adds Python type hints and runtime assertions to Electrum's JSON database helper code. The author explicitly states 'no functional changes intended'. There is no change to how the wallet stores, encrypts, or validates data, and no security vulnerability is introduced or fixed.

This commit loosens the rules for saving Lightning payment details when a user is retrying a failed or unpaid outgoing payment. It allows the wallet to overwrite the payment amount and status for a previously saved sent payment, specifically so users can retry paying an invoice that has no fixed amount (a '0 amount invoice') with a different amount. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a usability improvement for retrying payments.

This commit changes how Electrum stores Lightning payment records. Previously, outgoing and incoming payments sharing the same payment hash (for example, when rebalancing your own channels) could collide in the database and cause errors. The fix adds a direction flag to the database key so both sides can be stored separately. It is a bug-fix and robustness improvement, not an obvious security vulnerability, though the original collision could have caused crashes or inconsistent state in self-payment scenarios.

This commit simply adds the installed OpenSSL version string to Electrum's existing `version_info` diagnostic command. It is a minor information-gathering improvement with no apparent security relevance.

This commit is a simple code cleanup in Electrum's Lightning Network sweep logic. It moves a repeated block of code into a new helper function without changing what the code actually does. There is no security fix or behavior change visible in the diff.

This is a minor user-interface fix. After closing the Settings dialog, Electrum's main window now refreshes its tabs so that displayed information (for example, whether a Lightning payment can be sent) reflects any changed settings. There is no security issue here.

This commit fixes a bug in Electrum's Lightning wallet where the app guessed Lightning routing fees using hardcoded values. The old guess could be too low, causing 'Max' amount submarine swaps and similar payments to fail because the real fee later exceeded the reserved amount. The patch now uses the user's own configured maximum fee settings to make a more conservative estimate, so the wallet reserves enough for fees upfront.

This commit is a routine code cleanup in Electrum's Qt graphical user interface. It creates a reusable 'SwapProvidersButton' widget so that two different parts of the app (the swap dialog and submarine/on-chain payment flow) share the same code for showing and selecting swap providers. There is no security-relevant change visible in the diff.

This commit fixes a UI behavior bug in Electrum's swap dialog. Previously, when certain events happened (like fee updates), the dialog would recalculate both the 'send' and 'receive' fields, which could overwrite a value the user had just typed. Now it only updates the field that is supposed to automatically follow from the other, leaving the user's manual input alone. There is no direct evidence this is a security vulnerability.

This commit fixes a small user-interface bug in Electrum's Qt settings window. When users adjusted the Lightning Network fee slider by clicking on the slider track (rather than dragging the handle), the chosen fee wasn't saved because the app only saved it when the slider was released after dragging. The fix saves the fee whenever the slider value changes. It is a usability/configuration bug, not a security vulnerability.

This commit only adds a new automated test to Electrum's Lightning networking code. It simulates a multi-hop payment where the final receiver intentionally reports a malformed onion packet. There is no change to production code, no bug fix, and no security patch.

This commit tightens how Electrum's Lightning code reports a failed onion packet. Previously it used a generic 'BADONION' flag; now it uses the more specific 'INVALID_ONION_VERSION' code when telling the peer the onion could not be parsed. The change is mainly about following the Lightning specification more precisely and is unlikely to be a security fix for an exploitable bug.

This commit only adds a new automated test for an existing feature called 'dont_expire_htlcs' in Electrum's Lightning code. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. It is purely a test-file addition.

This commit only adds a new automated test to Electrum's Lightning code. It does not change any production code, so it cannot by itself introduce a security vulnerability or fix one. The test checks that a special internal flag called 'dont_settle_htlcs' correctly prevents Lightning payments from being finalized until the flag is removed, which is used for Just-In-Time channels.

This commit refactors how Electrum handles special Lightning payment hashes used for 'hold invoices' and 'just-in-time channel openings.' It splits one internal control list into two separate lists: one that prevents automatic settlement (releasing the secret that completes a payment) and one that prevents automatic expiry of pending payments. The change is described by the author as making the code easier to reason about and safer, but it also alters the timing rules for when pending payments can be cancelled. There is no direct evidence in the commit that this fixes a known exploitable bug, but the change touches security-sensitive payment logic.

This commit only adds and improves automated tests for Electrum's Lightning payment logic. It does not change any production wallet or network code, so it cannot introduce a security vulnerability in the software users run. The test changes make the test suite better at catching failures when multiple bundled payments are attempted.

This commit adds automatic crash reporting for a specific internal Lightning payment-routing function. When that function hits an unexpected error, the app now sends a redacted copy of the error to Electrum's crash reporter before re-raising it. It is a diagnostic/logging improvement, not a fix for a known security flaw, and it does not change how errors are handled.

This commit only adds a new automated test that measures how fast a specific internal Lightning Network routine runs. It does not change any production wallet code, user-facing behavior, or network protocol handling. There is no security fix or vulnerability introduced here.

This commit only adds a new automated test to Electrum's Lightning code. It does not change any production wallet or server code, so it cannot by itself introduce a security vulnerability or fix one in shipped software. The test verifies that 'hold invoices' used in features like submarine swaps are not prematurely expired while a callback is still active.

This commit only adds a new automated test to Electrum's Lightning networking code. It does not change any production behavior. The test verifies that a forwarding node (Bob) rejects a multi-part trampoline payment when the hidden 'trampoline onions' inside the payment parts disagree on the amount. This is a defensive correctness check, not a fix or vulnerability patch.

This commit only adds a new automated test to Electrum's Lightning networking code. It does not change any production code, fix a bug, or introduce a vulnerability. The test checks that in a specific multi-part trampoline payment scenario, an intermediate node (Bob) does not forward more money to the next hop than he received from the previous hop. It is a regression test to help catch a potential bug in the future, not a patch for an existing security issue.

This commit only adds a new automated test for the Electrum Lightning wallet. It checks that when a multi-part payment times out because not enough money arrived, the leftover payment records are cleaned up so the sender can try paying the same invoice again. There is no change to production code, so users are not directly affected by this commit.

This commit only adds a new automated test to Electrum's Lightning code. It does not change any production code, so it cannot by itself introduce or fix a security vulnerability in running software. The test checks a corner case in multi-part Lightning payments to make sure a bug (settling part of an incomplete payment) does not occur.

This commit only adds a new automated test to Electrum's Lightning code. It checks that the software rejects attempts to pay the same invoice twice. There is no change to the actual wallet or Lightning logic, so by itself this commit does not fix or introduce a security issue. It may be related to a prior bug fix, but the commit message and diff do not describe one.