Electrum

This commit only adds a new automated test to Electrum's Lightning networking code. The test checks that the software correctly refuses payments for expired invoices. It does not change any production code, so it cannot by itself introduce or fix a security issue in running software.

This commit only adds a new automated test to Electrum's Lightning code. The test checks that a payment is rejected when the sender uses a shorter safety window (called 'final cltv delta') than the receiver's invoice requested. There is no change to production code, so by itself this commit does not fix or introduce a security issue. It may be related to a prior or future fix, but this commit alone is just a test.

This is a large internal refactor of Electrum's Lightning code that handles incoming multi-part payments (MPP). The change restructures how individual HTLCs are collected into sets and how those sets are validated, forwarded, or settled. The commit message frames it as improving robustness and maintainability, not as a security fix. The diff shows new consistency checks for trampoline onions, stricter state transitions for payment sets, and a wallet database upgrade to migrate old state. There is no vendor statement that this fixes a known vulnerability, and no CVE or researcher attribution is present in the supplied materials.

This is a small cleanup change in Electrum's submarine swap (atomic swap) code. It replaces hardcoded transaction height numbers with named constants and slightly adjusts when a claim transaction can be broadcast. The change allows a claim transaction to be considered 'already broadcast' even if its parent transaction is still unconfirmed. This is a follow-up to a previous change and appears aimed at preventing duplicate broadcasts or premature broadcasting, not at introducing a vulnerability.

This commit fixes a bug in Electrum's Lightning Network code where multi-trampoline payments could incorrectly fail. In normal payments, the amount specified inside the onion must match the HTLC amount. But for trampoline routing, an inner trampoline onion can legitimately request a larger amount than the current HTLC because the payment is split across multiple trampoline forwarders. The old code enforced the strict match check even for these inner trampoline onions, causing valid payments to be rejected with a 'final incorrect HTLC amount' error. The fix moves the check into a method that only applies to final (non-trampoline-forwarding) HTLCs and skips it for inner trampoline onions.

This is a tiny code cleanup in Electrum's QML (mobile-style) user interface. A function that formats tiny Bitcoin amounts used to silently return '---' if it received an unexpected input type. The change removes that fallback and instead adds an assertion that will crash the program if the wrong type is ever passed. This is a defensive coding change, not a security fix, and it does not introduce a vulnerability.

This commit fixes a timing bug in Electrum's Lightning payments. If a user started multiple Lightning payments at the same time, the wallet could plan routes using outdated channel balances, promising more money than was actually available. When the payments were then sent, one would fail with a 'not enough balance' error. The fix adds a lock so that balance checks and route creation happen one payment at a time, preventing the stale-balance problem.

This commit fixes a bug where users who typed a proxy setting on the command line could believe their traffic was being routed through that proxy, but Electrum was not actually enabling proxy mode. The fix makes specifying a proxy automatically turn proxy mode on. If left unfixed, a user might leak network traffic outside their intended proxy, which matters for privacy but is not a direct remote exploit.

This commit changes the mobile/QML user interface of the Electrum Bitcoin wallet so that Lightning invoice amounts are shown and entered with millisecond precision (one-thousandth of a satoshi) instead of whole satoshis. It is a precision/usability improvement for the QML GUI, not a fix for a vulnerability. There is no indication in the commit that this resolves a security issue.

This commit tightens a Bitcoin amount input validation regex used in Electrum's QML (mobile/desktop) GUI. The old regex lacked start (^) and end ($) anchors, meaning it could match invalid strings that merely contained a valid-looking number somewhere inside. The fix anchors the pattern and makes the decimal fraction optional. A new variant for milli-satoshi precision is also added, along with unit tests. The practical security impact is limited because the regex is only one layer of validation and likely used for UI feedback rather than final payment authorization.

This commit fixes a precision bug in Electrum's mobile/QML interface when handling very small Lightning payments. Previously, amounts were rounded to whole satoshis too early, which could cause the app to reject valid Lightning invoices that require millisecond-precision amounts, or to miscalculate whether the user has enough balance. The change also cleans up duplicate balance-check code and adds unit tests.

This is a routine internal code cleanup in Electrum's settings module. It replaces an old shortcut property (`self.decimal_point`) and its getter method with direct use of a configuration variable (`self.BTC_AMOUNTS_DECIMAL_POINT`). The behavior is unchanged; there is no security issue visible in the commit.

This commit is a simple code cleanup: it moves a small helper function that creates a colored icon from a public key from one file to a shared utility file. There is no change in behavior, no bug fix, and no security relevance.

This commit adds a new optional feature in Electrum's desktop (Qt) GUI called 'Submarine Payments'. It lets users pay a regular on-chain Bitcoin address directly from their Lightning balance by doing a reverse submarine swap through a third-party swap provider. The change is a feature addition, not a fix for a known vulnerability. It exposes existing swap logic in the transaction editor and adds UI controls, configuration, and cleanup handling. There is no direct evidence in the commit or supplied references that this resolves a security bug or introduces a new attack.

This commit adds a feature to Electrum that lets users route reverse submarine swaps to an external Bitcoin address, effectively turning a Lightning payment into an on-chain payment to someone else. The change renames a database field, adds wallet-upgrade logic, and introduces a new code path that builds and broadcasts a claim transaction. There is no direct evidence in the commit of a security vulnerability, but the new code handles private keys, transaction signing, and broadcasting, so it is a sensitive area worth reviewing carefully.

This commit is a small internal code cleanup in Electrum's Lightning network code. It moves an existing conversion of raw integer failure codes into a named helper method, without changing behavior. There is no user-facing or security-relevant change.

This commit fixes a bug where the code tried to modify a data object that had been made read-only (immutable). The fix creates a new copy of the object with the needed changes instead of changing the original. This is a defensive repair to prevent runtime errors, not a clear-cut security patch, though immutability violations can sometimes hide or cause subtle bugs in payment routing.

This commit is a straightforward internal code refactor. It moves a helper function that encrypts routing data from one file to another, renames it, and generalizes it so it can handle two slightly different data formats. There is no indication it fixes a security bug or introduces a vulnerability.

This commit is a straightforward internal cleanup in Electrum's Lightning Network code. It adds helper properties to make reading onion packet fields more consistent and slightly reorders how payment data is assembled. There is no indication it fixes a security bug or introduces a vulnerability.

This commit is a pure code restructure: it extracts the inner body of Electrum's Lightning HTLC switching loop into a new private helper method named `_run_htlc_switch_iteration`. The commit message explicitly says 'no code modification, indent-only', and the diff matches that claim. There are no functional changes, no security fixes, and no new behavior introduced.

This commit simply deletes the 'payserver' plugin from the Electrum repository and moves it to a separate project. There is no security fix or vulnerability patch here—just code relocation.

This is a tiny follow-up patch to a test file only. It changes one expected value in a unit test from the integer 1 to the raw byte string b"\x01" so the test correctly matches what the actual code returns. It does not change any production code, network behavior, or wallet logic, and has no security relevance.

This commit fixes a data-format bug in Electrum's Lightning onion-message handling. The number of hops in a 'blinded path' was being stored as a plain integer, but the protocol expects a single byte. The patch changes it to a bytes object. A second change only improves an error message when no reply path can be created. The fix is small and appears to prevent interoperability or parsing problems rather than a direct theft-of-funds vulnerability.

This commit only adds extra information to log messages when Electrum sends a Lightning payment. It does not change any payment logic, permissions, or security behavior. One log line now includes the payment hash, and another debug log records whether the payment uses a legacy trampoline relay. There is no security issue visible in the diff.

This commit fixes a bug in Electrum's command-line 'payto' command where a transaction fee rate typed in as text (a string) was being incorrectly handled. The old code tried to multiply the text string by 1000, which in Python repeats the string instead of doing math, producing a wildly wrong fee policy. The fix converts the string to a number (Decimal) first, then multiplies. This could cause users who set a custom fee rate via the CLI to get an absurdly large or malformed fee value, potentially overpaying fees or having transaction creation fail.