EL
← All projectsElectrum

Electrum

Long-running lightweight Bitcoin wallet for desktop and mobile platforms.

BitcoinSoftware walletsNormal
Repository coverage

927 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

65security candidates205second-pass queue302AI analyses
57commits · 30 days
111commits · 60 days
457commits · 180 days
926commits · 365 days
Backfill bands
Aug 5 → Feb 6470 seen11 candidatesComplete
Feb 6 → Jun 6346 seen10 candidatesComplete
Jun 6 → Jul 653 seen2 candidatesComplete
Jul 6 → Aug 554 seen3 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

65/100 average clarity
192Strong · 80–100
410Adequate · 60–79
286Thin · 40–59
39Opaque · 0–39
2security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
ThomasV72219156
SomberNight35126124063
f321x37121114070
Sander van Grieken981030057
user322062
Roman Zeyde512053
Sasha Zykov413076
Aaron Fiore411068
Ferdinando Ametrano111096
Felix201075
Oren201043
Ilya Artemov200050
Analysis record

Published AI watches

Last scanned 59 minutes ago

Informational 18 AI analysisMessage 73 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

Merge pull request #10791 from SomberNight/202608_wallet_sign_message2

This change moves the trimming of leading/trailing spaces in message-signing fields from the user-interface code into the shared wallet code. For the graphical interfaces (Qt and QML), spaces are still stripped automatically for convenienc…

Behavior change in message signing/verification input handlingCLI now preserves whitespace, which could affect signature validity for messages that intentionally contain leading or trailing whitespaceNo memory-safety, cryptographic, or authentication flaw visible in the diff
b1aa52d7by ghost43+27−185 files
No security note in commit
Informational 19 AI analysisMessage 96 · Strong
EL ElectrumElectrum BitcoinSoftware wallets

wallet: sign_message: strip whitespaces in GUIs, do not strip in CLI

This commit tidies up how Electrum handles extra spaces around Bitcoin addresses, messages, and signatures when signing or verifying messages. Previously, different parts of the program (desktop GUI, mobile-style GUI, command line) behaved…

Behavior normalization across GUI and CLI interfacesNo cryptographic primitive changedNo privilege boundary crossed
4c3064f5by SomberNight+27−185 files
No security note in commit
Informational 22 AI analysisMessage 50 · Thin
EL ElectrumElectrum BitcoinSoftware wallets

wallet: decrypt_message: nicer error msg if pubkey is unrelated

This commit improves the error handling in Electrum's message decryption feature. Previously, if a user tried to decrypt a message using a public key that did not belong to their wallet, the code could proceed and likely fail with a confus…

Input validation added for public key before cryptographic operationUser-facing exception replaces potential internal failureDefensive check prevents use of unrelated key material
92e938f4by SomberNight+5−01 file
No security note in commit
Informational 16 AI analysisMessage 83 · Strong
EL ElectrumElectrum BitcoinSoftware wallets

qt: main_window: use TaskThread for each of sign/verify/encrypt/decrypt

This commit moves four message-crypto operations (sign, verify, encrypt, decrypt) in Electrum's Qt wallet window onto a background worker thread so they all behave the same way. It also lets the background thread surface user-facing errors…

Moved blocking wallet crypto calls off the GUI thread, reducing UI freeze / DoS surfaceRemoved local exception swallowing for encrypt_message; errors now propagate through the window's on_error handlerAdded defensive RuntimeError guard for deleted Qt widget in async callback
4a9a199fby SomberNight+28−151 file
No security note in commit
Low 29 AI analysisMessage 35 · Opaque
EL ElectrumElectrum BitcoinSoftware wallets

wallet: sign_message: force kwargs

This commit changes how Electrum's message-signing function is called so that callers must explicitly name each argument (address, message, password) rather than passing them by position. The main practical effect is to prevent accidental …

API hardening: keyword-only arguments prevent positional argument swapNo explicit security bug fix or vulnerability disclosure in commit message or diffNo changes to cryptographic logic, password handling, or message parsing
e1eb2a34by SomberNight+9−44 files
No security note in commit
Low 39 AI analysisMessage 45 · Thin
EL ElectrumElectrum BitcoinSoftware wallets

wallet: sign_message: consolidate checks from UIs

This commit moves input-validation checks for signing, verifying, encrypting, and decrypting messages out of the user-interface code and into the shared wallet logic. It also adds type checks so that non-text inputs are rejected earlier. T…

Input validation moved from UI controllers into core wallet logicType checks added at the CLI command entry points for message-crypto operationsUserFacingException used consistently for address, wallet, script-type, and key-format errors
48893760by SomberNight+89−396 files
No security note in commit
Low 27 AI analysisMessage 50 · Thin
EL ElectrumElectrum BitcoinSoftware wallets

wallet: decrypt_message: consolidate checks from UIs

This commit moves input-validation and wallet-type checks for message decryption out of the user-interface and command-line layers and into the core wallet code. It also removes a faster, separate decryption path for imported wallets so al…

Input validation consolidated into a single core methodWatching-only wallet check moved from UI to wallet layerMultisig wallet unsupported-operation check moved from UI to wallet layer
9a0cc0d6by SomberNight+25−173 files
No security note in commit
Informational 15 AI analysisMessage 50 · Thin
EL ElectrumElectrum BitcoinSoftware wallets

wallet: refactor: add encrypt_message method, consolidated from UIs

This commit is a simple code cleanup: it moves the message-encryption logic from two separate places (the command-line tool and the Qt graphical interface) into a single shared method on the wallet class. The actual encryption behavior is …

No change to cryptographic primitives or parametersNo change to trust boundaries or input sourcesPure refactor consolidating duplicate code
5e9c8df0by SomberNight+26−183 files
No security note in commit
Informational 13 AI analysisMessage 50 · Thin
EL ElectrumElectrum BitcoinSoftware wallets

wallet: refactor: add verify_message method, consolidated from UIs

This commit is a routine code cleanup: it moves message-signature verification out of three user-interface files into a single shared helper method in the wallet module. There is no security-relevant behavior change visible in the diff. Th…

No security-relevant functional changeRefactoring only: code deduplicationException handling broadened safely (ValueError covers binascii.Error and unicode errors)
ff5bbb04by SomberNight+26−304 files
No security note in commit
Informational 15 AI analysisMessage 60 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

qt: main_window: add type hints to sign/verify, encrypt/decrypt

This commit only adds Python type hints and renames some function parameters for clarity in the Electrum desktop wallet's sign/verify and encrypt/decrypt message dialogs. It does not change what the code actually does, how it processes use…

0906fc20by SomberNight+45−181 file
No security note in commit
Informational 18 AI analysisMessage 50 · Thin
EL ElectrumElectrum BitcoinSoftware wallets

coldcard: fix get_soft_device_id() discarding its return value

This is a tiny one-line bug fix in Electrum's Coldcard hardware wallet plugin. A helper method that is supposed to fetch a software-based device identifier was calling the parent implementation but accidentally throwing away the result ins…

Missing return value causes method to always return NoneAffects hardware wallet device identification onlyNo change to signing, encryption, or authentication code
d7500508by Felipe Micaroni Lalli+1−11 file
No security note in commit
Informational 19 AI analysisMessage 96 · Strong
EL ElectrumElectrum BitcoinSoftware wallets

qml: strip whitespace from message before signing, as in qt gui

This commit fixes a minor consistency bug in Electrum's newer QML (mobile-style) user interface. When signing a message, the app now removes accidental spaces at the start or end of the message and address, just like the older desktop Qt i…

Behavioral inconsistency between GUI implementations could cause user confusion or failed verificationNo cryptographic weakness introduced; change is input normalizationNo memory-unsafe code, no privilege changes, no network changes
72507328by Ferdinando Ametrano+3−01 file
No security note in commit
Low 48 AI analysisMessage 85 · Strong
EL ElectrumElectrum BitcoinSoftware wallets

config: don't save "hidden wallet" paths in CURRENT_WALLET cv

This commit fixes a privacy leak in the Electrum wallet app. Previously, if a user opened a 'hidden wallet' (one whose filename starts with a dot, like a secret file), Electrum would remember it as the last-used wallet and could reopen it …

Privacy leak: hidden wallet filename persisted in config and could be auto-reopenedInformation disclosure: hidden wallet path exposed in recently-opened listBehavioral fix: setter silently drops sensitive value rather than persisting it
c43cf8e4by SomberNight+14−23 files
No security note in commit
Low 28 AI analysisMessage 73 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

lnrouter: liquidity hints: add extra penalty if amt near cannot_send

This commit tweaks how Electrum's Lightning Network payment routing avoids channels where a previous payment attempt already failed. Previously, the router would treat a channel almost at its known failure limit almost the same as a channe…

Routing/liquidity-hint logic changed to penalize amounts close to a known cannot_send thresholdAdds defensive assertions on num_inflight_htlcs type and rangeSelf-described by author as a 'completely naive bandaid' / heuristic improvement
ee75ea31by SomberNight+12−21 file
No security note in commit
Moderate 52 AI analysisMessage 93 · Strong
EL ElectrumElectrum BitcoinSoftware wallets

lnwallet: don't blacklist htlc failures without channel update

This change fixes how Electrum's Lightning wallet reacts when a payment route fails but the failing node no longer provides a channel update message, as now allowed by the Lightning protocol spec. Previously, Electrum would permanently bla…

Denial-of-service via over-blacklisting: prior behavior could cause legitimate channels to be blacklisted, degrading payment success and potentially isolating the wallet from usable routes.Spec compliance fix: aligns Electrum with updated Lightning BOLT protocol behavior.No cryptographic bypass or funds theft signal: the change is about routing policy, not key leakage or transaction authorization.
a865e336by f321x+48−142 files
No security note in commit
Informational 15 AI analysisMessage 35 · Opaque
EL ElectrumElectrum BitcoinSoftware wallets

hww/qt: followup 898a4c270

This commit simply renames an internal variable from `dialog_label` to `_dialog_label` to mark it as private. It is a minor code cleanup with no visible behavior change and no security relevance.

f3af41deby f321x+4−41 file
No security note in commit
Low 25 AI analysisMessage 68 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

trezor: drop session after closing it

This commit fixes a bug in Electrum's support for Trezor hardware wallets. After a Trezor session times out or is closed, Electrum now forgets the old session ID. Previously it kept the stale session ID, so the next attempt to sign a trans…

Fixes a stale-session reference that caused InvalidSessionError on re-authenticationEnsures PIN re-prompt after session timeout/closureFailure mode was denial-of-service (transaction signing crash), not unauthorized signing
071b1e24by f321x+8−51 file
No security note in commit
Informational 12 AI analysisMessage 83 · Strong
EL ElectrumElectrum BitcoinSoftware wallets

test_lnwallet: add unittest for unchanged channel update from failed htlc

This commit only adds a new unit test to Electrum's Lightning wallet test suite. It checks that when a payment fails due to a temporary lack of liquidity (TEMPORARY_CHANNEL_FAILURE) and the accompanying channel policy update is identical t…

Lightning payment routing failure handling behavior is being testedTEMPORARY_CHANNEL_FAILURE no longer (or is confirmed not to) blacklist channels when the channel update is unchangedLiquidity hints are used as an alternative to blacklisting for retry amounts
1f5b9adbby f321x+61−21 file
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

lnwallet: rename flag in handle_error_code_from_failed_htlc

This commit only renames a local variable from 'update' to 'handled' in a Lightning Network payment-failure handler. It does not change any program logic, behavior, or security properties. The change is purely cosmetic/clarifying.

8e3aed1fby f321x+8−81 file
No security note in commit
Low 45 AI analysisMessage 73 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

lnwallet: don't blacklist chan on unchanged channel update

This commit fixes a bug in Electrum's Lightning payment routing. Previously, if a payment failed because a channel didn't have enough money (a temporary liquidity issue), Electrum would incorrectly 'blacklist' that channel for an hour, eve…

Denial-of-service-like self-harm: unnecessary channel blacklisting degrades user's own payment routing capabilityLightning Network routing logic changeBehavioral fix for TEMPORARY_CHANNEL_FAILURE handling
6a97e74cby f321x+6−11 file
No security note in commit
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Lower-prioritybuild: win: change from win-iconv to GNU libiconvby SomberNight · 31ed05c0 · Feb 28, 2026 · 4 filesMessage 88 · StrongTriage 0Details
Commit message · SomberNight

build: win: change from win-iconv to GNU libiconv

- (zbar requires [0] iconv)
- issues [1][3] compiling win-iconv:
- pre-existing issue: lots of "-Wincompatible-pointer-types" warnings when compiling zbar with win-iconv
- new debian means newer GCC
- new GCC changed that [2] warning type to "error"
- GNU libiconv works as an alternative
- drawback: win-iconv is more minimal, it uses the win32 API to do most of the work
- still, is a 25+ year old GNU project with one release every ~2 years, so IMO fine

[0]: https://github.com/mchehab/zbar/blob/a549566ea11eb03622bd4458a1728ffe3f589163/README-windows.md
[1]: https://github.com/SomberNight/electrum/commit/cb00cb60cf9a0cb059dcac5e7acfe5186620cabe
[2]: https://gcc.gnu.org/pipermail/gcc-cvs/2023-December/394351.html

[3]: see snippet when compiling libzbar:
```
decoder.c: In function ‘zbar_decoder_reset’:
decoder.c:116:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
116 | memset(dcode, 0, (long)&dcode->buf_alloc - (long)dcode);
| ^
decoder.c:116:48: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
116 | memset(dcode, 0, (long)&dcode->buf_alloc - (long)dcode);
| ^
CC processor/libzbar_la-win.lo
/bin/bash ../libtool --tag=RC \
--mode=compile x86_64-w64-mingw32-windres -DHAVE_CONFIG_H -I. -I../include \
-I../include -o libzbar-rc.lo libzbar.rc
CC processor/libzbar_la-lock.lo
CC decoder/libzbar_la-qr_finder.lo
CC qrcode/libzbar_la-qrdec.lo
In file included from ./processor.h:26,
from processor/lock.c:25:
../include/config.h:423:9: warning: "_WIN32_WINNT" redefined
423 | #define _WIN32_WINNT 0x0500
| ^~~~~~~~~~~~
In file included from /usr/share/mingw-w64/include/corecrt.h:10,
from /usr/share/mingw-w64/include/crtdefs.h:10,
from /usr/share/mingw-w64/include/assert.h:15,
from processor/lock.c:24:
/usr/share/mingw-w64/include/_mingw.h:232:9: note: this is the location of the previous definition
232 | #define _WIN32_WINNT 0xa00
| ^~~~~~~~~~~~
libtool: compile: x86_64-w64-mingw32-windres -DHAVE_CONFIG_H -I. -I../include -I../include libzbar.rc -o .libs/libzbar-rc.o
CC qrcode/libzbar_la-qrdectxt.lo
CC qrcode/libzbar_la-rs.lo
CC qrcode/libzbar_la-isaac.lo
CC qrcode/libzbar_la-bch15_5.lo
CC qrcode/libzbar_la-binarize.lo
CC qrcode/libzbar_la-util.lo
In file included from ./image.h:26,
from qrcode/binarize.c:10:
../include/config.h:423:9: warning: "_WIN32_WINNT" redefined
423 | #define _WIN32_WINNT 0x0500
| ^~~~~~~~~~~~
In file included from /usr/share/mingw-w64/include/corecrt.h:10,
from /usr/share/mingw-w64/include/crtdefs.h:10,
from /usr/share/mingw-w64/include/math.h:13,
from qrcode/binarize.c:7:
/usr/share/mingw-w64/include/_mingw.h:232:9: note: this is the location of the previous definition
232 | #define _WIN32_WINNT 0xa00
| ^~~~~~~~~~~~
CC video/libzbar_la-dshow.lo
CC window/libzbar_la-win.lo
In file included from ./window.h:26,
from window/win.c:26:
../include/config.h:423:9: warning: "_WIN32_WINNT" redefined
423 | #define _WIN32_WINNT 0x0500
| ^~~~~~~~~~~~
In file included from /usr/share/mingw-w64/include/corecrt.h:10,
from /usr/share/mingw-w64/include/crtdefs.h:10,
from /usr/share/mingw-w64/include/ctype.h:9,
from window/win.c:24:
/usr/share/mingw-w64/include/_mingw.h:232:9: note: this is the location of the previous definition
232 | #define _WIN32_WINNT 0xa00
| ^~~~~~~~~~~~
In file included from ./processor.h:26,
from processor/win.c:29:
../include/config.h:423:9: warning: "_WIN32_WINNT" redefined
423 | #define _WIN32_WINNT 0x0500
| ^~~~~~~~~~~~
In file included from /usr/share/mingw-w64/include/corecrt.h:10,
from /usr/share/mingw-w64/include/crtdefs.h:10,
from /usr/share/mingw-w64/include/assert.h:15,
from processor/win.c:24:
/usr/share/mingw-w64/include/_mingw.h:232:9: note: this is the location of the previous definition
232 | #define _WIN32_WINNT 0xa00
| ^~~~~~~~~~~~
processor/win.c: In function ‘_zbar_processor_open’:
processor/win.c:282:47: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
282 | proc->display = CreateWindowEx(EXT_STYLE, (LPCTSTR)(long)wca, "ZBar",
| ^
processor/win.c: In function ‘_zbar_processor_close’:
processor/win.c:297:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
297 | UnregisterClass((LPCTSTR)(long)proc->state->registeredClass, 0);
| ^
CC window/libzbar_la-dib.lo
qrcode/qrdectxt.c: In function ‘qr_code_data_list_extract_text’:
qrcode/qrdectxt.c:302:62: error: passing argument 2 of ‘iconv’ from incompatible pointer type [-Wincompatible-pointer-types]
302 | iconv(utf8_cd, &in, &inleft, &out,
| ^~~
| |
| char **
In file included from qrcode/qrdectxt.c:12:
/usr/x86_64-w64-mingw32/include/iconv.h:43:56: note: expected ‘const char **’ but argument is of type ‘char **’
43 | size_t iconv(iconv_t cd, WINICONV_CONST char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft);
qrcode/qrdectxt.c:352:71: error: passing argument 2 of ‘iconv’ from incompatible pointer type [-Wincompatible-pointer-types]
352 | err = iconv(enc_list[ei], &in,
| ^~~
| |
| char **
/usr/x86_64-w64-mingw32/include/iconv.h:43:56: note: expected ‘const char **’ but argument is of type ‘char **’
43 | size_t iconv(iconv_t cd, WINICONV_CONST char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft);
qrcode/qrdectxt.c:374:53: error: passing argument 2 of ‘iconv’ from incompatible pointer type [-Wincompatible-pointer-types]
374 | iconv(eci_cd, &in, &inleft, &out,
| ^~~
| |
| char **
/usr/x86_64-w64-mingw32/include/iconv.h:43:56: note: expected ‘const char **’ but argument is of type ‘char **’
43 | size_t iconv(iconv_t cd, WINICONV_CONST char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft);
make[2]: *** [Makefile:1089: qrcode/libzbar_la-qrdectxt.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/opt/wine64/drive_c/electrum/contrib/zbar/zbar'
make[1]: *** [Makefile:1895: all-recursive] Error 1
make[1]: Leaving directory '/opt/wine64/drive_c/electrum/contrib/zbar'
make: *** [Makefile:989: all] Error 2
🗯 ERROR: Could not build zbar
🗯 ERROR: Could not build zbar

```

88/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Lower-prioritybuild: win: bump wine (10->11)by SomberNight · 3674232d · Feb 27, 2026 · 1 fileMessage 57 · ThinTriage 0Details
Commit message · SomberNight

build: win: bump wine (10->11)

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Lower-prioritybuild: win: update debian base (12->13)by SomberNight · b939e877 · Feb 27, 2026 · 3 filesMessage 57 · ThinTriage 0Details
Commit message · SomberNight

build: win: update debian base (12->13)

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Lower-prioritytests: add unittest for TxBatch._to_sweep_after()by f321x · 04a034e6 · Feb 27, 2026 · 1 fileMessage 70 · AdequateTriage 0Details
Commit message · f321x

tests: add unittest for TxBatch._to_sweep_after()

Adds unittest for `TxBatch._to_sweep_after()` anchor claiming part.

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Lower-prioritytxbatcher: don't spend anchors if ctx fee is sufficientby f321x · c4dcd85a · Feb 27, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · f321x

txbatcher: don't spend anchors if ctx fee is sufficient

If the tx fee of the ctx is already higher than the required target it
is not useful to spend the anchor with a lower fee (the current target),
so instead it is skipped.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritybuild: appimage: fix build missing a system-wide pythonby SomberNight · a36c9a24 · Feb 26, 2026 · 1 fileMessage 100 · StrongTriage 0Details
Commit message · SomberNight

build: appimage: fix build missing a system-wide python

```
�� INFO: preparing electrum-locale.
[...]
running stats.py
/usr/bin/env: �python3�: No such file or directory
```

regression from https://github.com/spesmilo/electrum/commit/3afa2fcdf3cce609d8813bbdd7b5962214de5ec0

This had shown up on the CI [0] but we did not notice - there is too many random failures, too much noise :(

[0]: https://github.com/spesmilo/electrum/runs/64623983097

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
AI review queuedupdate block header checkpointsby SomberNight · d72b7411 · Feb 26, 2026 · 4 filesMessage 35 · OpaqueInformational 15Details
Commit message · SomberNight

update block header checkpoints

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: opaque commit messagesecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit simply adds new Bitcoin block header checkpoints to Electrum's data files for mainnet, signet, testnet, and testnet4. Checkpoints are hardcoded reference points that help the wallet verify it is following the correct blockchain. There is no code change, no bug fix, and no security vulnerability visible in this diff.

AI review queuedfollow-up RELEASE-NOTESby SomberNight · 57bf8c89 · Feb 26, 2026 · 1 fileMessage 28 · OpaqueInformational 15Details
Commit message · SomberNight

follow-up RELEASE-NOTES

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit only edits the project's RELEASE-NOTES text file. It rephrases a sentence about how translators can apply to become proofreaders. There is no code change, no security fix, and no functional change to Electrum.

AI review queuedbump version to 4.7.1by f321x · eee2e858 · Feb 26, 2026 · 1 fileMessage 38 · OpaqueInformational 15Details
Commit message · f321x

bump version to 4.7.1

38/100 · OpaqueMessage clarity
✓ Subject identifies a change✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit only changes the software version number from 4.7.0 to 4.7.1 in a single file. It contains no security-related code changes and no functional changes at all.

Lower-priorityadd version 4.7.1 release notesby f321x · 8d95135a · Feb 26, 2026 · 1 fileMessage 60 · AdequateTriage 0Details
Commit message · f321x

add version 4.7.1 release notes

Co-authored-by: SomberNight <somber.night@protonmail.com>

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Lower-prioritylnwatcher: ~document behaviour re subbing to historical chans and swapsby SomberNight · d733350a · Feb 25, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · SomberNight

lnwatcher: ~document behaviour re subbing to historical chans and swaps

not so intuitive

ref https://github.com/spesmilo/electrum/pull/7852 ("Persist lnwatcher")

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Security candidatedeps: bump libsecp256k1 version (0.7.0->0.7.1) and electrum-eccby SomberNight · 9dc725fa · Feb 25, 2026 · 3 filesMessage 50 · ThinLow 41Details
Commit message · SomberNight

deps: bump libsecp256k1 version (0.7.0->0.7.1) and electrum-ecc

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Low 41/100

This commit updates the cryptographic library (libsecp256k1) used by Electrum from version 0.7.0 to 0.7.1, and also updates the related Python wrapper package (electrum-ecc) from 0.0.6 to 0.0.7. It only changes version numbers and corresponding checksums in build scripts and dependency lists. There is no direct evidence in the commit itself that this fixes a specific security vulnerability, but updating a core cryptographic dependency is a routine security-hygiene change. Without a vendor reference linking this bump to a known bug, we cannot say it definitely fixes a security issue.

AI review queuedsimplify prevby SomberNight · 10274c1c · Feb 24, 2026 · 1 fileMessage 18 · OpaqueLow 32Details
Commit message · SomberNight

simplify prev

18/100 · OpaqueMessage clarity
✓ Subject identifies a change! Too few words to establish purpose! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Low 32/100

This commit simplifies how Electrum stores secret Lightning payment preimages. It removes a code path that let callers leave a privacy flag unset (which previously kept the old value), and instead always defaults to not marking the preimage as public while still preventing a previously public preimage from becoming private. The change is a cleanup, but it slightly alters behavior: callers who used to rely on 'keep the old value' now get 'False' if no old value exists, and any old public mark is preserved. There is no clear security bug in the diff itself, but it touches sensitive secret-handling code.

AI review queuedlnsweep: safer maybe_reveal_preimage_for_htlc, add "is_preimage_public"by SomberNight · 0b2c7a8a · Feb 24, 2026 · 8 filesMessage 73 · AdequateModerate 58Details
Commit message · SomberNight

lnsweep: safer maybe_reveal_preimage_for_htlc, add "is_preimage_public"

"When should we reveal preimages onchain?"
This commit tries to simplify the thinking by making the observation:
- we can reveal preimages (actually in any context) if they are already public
- a preimage is public if any other lightning node knows it besides us
- if we learn the preimage from another LN node, it is public
- if we send update_fulfill_htlc, it becomes public
- if we see a preimage onchain, it is public

- in lnsweep._maybe_reveal_preimage_for_htlc:
- partial mpp check is not relevant if preimage is already public
- let's just always do KeepWatchingTXO, for sanity/safety

Co-authored-by: ThomasV <thomasv@electrum.org>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Moderate 58/100

This commit hardens how Electrum decides when to reveal secret payment proof values (called preimages) on the Bitcoin blockchain during Lightning channel force-closes. Previously, the wallet might have revealed a preimage too early if a multi-part payment was incomplete, which could let a sender pay less than the invoice asked for. The change tracks whether a preimage is already 'public' (known to other nodes or seen on-chain) and only reveals it on-chain when it is safe. It also makes sure Electrum keeps watching the relevant transaction output until the timeout, even if it cannot reveal the preimage yet.

AI review queuedtransaction: extend estimated_size() docstringby f321x · 3133148a · Feb 24, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · f321x

transaction: extend estimated_size() docstring

Extends the docstring of Transaction.estimated_size().

Co-Authored-By: SomberNight <somber.night@protonmail.com>

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only adds explanatory text to a code comment (docstring). It does not change any program logic, transaction calculations, or security behavior. There is no security issue here.

Security candidatetransaction: use dummy DER ECDSA sig from descriptor.pyby f321x · e9ac3e93 · Feb 24, 2026 · 1 fileMessage 65 · AdequateInformational 15Details
Commit message · f321x

transaction: use dummy DER ECDSA sig from descriptor.py

We have two different dummy der signatures of varying size,
this unifies them to use a single one from descriptor.py.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit is a minor code cleanup. It replaces a locally-defined placeholder fake cryptographic signature with a shared constant from another file. The placeholder is only used to estimate transaction size and is never broadcast or used in real transactions. There is no security issue here.

AI review queuedtest_wallet_vertical: test bump_fee raises for too low feeby f321x · f1e792cc · Feb 24, 2026 · 1 fileMessage 83 · StrongInformational 12Details
Commit message · f321x

test_wallet_vertical: test bump_fee raises for too low fee

Test that Abstract_Wallet.bump_fee() raises if the given feerate
of the replacement is equal to the feerate of the tx to bump as this
wouldn't be accepted to the mempool.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 12/100

This commit only adds a new automated test to Electrum. The test checks that the wallet's 'bump fee' feature correctly refuses to create a replacement Bitcoin transaction when the new fee rate is not high enough to be accepted by the network. It does not change any production wallet code, so it cannot by itself introduce a security vulnerability or fix one in shipped software. It may, however, be regression coverage for an earlier behavioral fix.

AI review queuedtest_wallet_vertical: add test for dscancel fee estimateby f321x · 6c143fa9 · Feb 24, 2026 · 1 fileMessage 83 · StrongInformational 12Details
Commit message · f321x

test_wallet_vertical: add test for dscancel fee estimate

Check that dscancel properly raises CannotDoubleSpendTx if the
feerate of the new tx is lower than the tx to be cancelled.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 12/100

This commit only adds a new automated test to Electrum. The test checks that the wallet correctly refuses to cancel a transaction if the replacement transaction does not pay a higher fee rate than the original. It does not change any production wallet code, so it cannot directly introduce or fix a security vulnerability in running software.

AI review queuedtest_wallet_vertical: add test for batch tx fee increaseby f321x · 6e1bf7c4 · Feb 24, 2026 · 1 fileMessage 95 · StrongInformational 12Details
Commit message · f321x

test_wallet_vertical: add test for batch tx fee increase

Adds unittest to check the fee increase when adding outputs to a base
tx. Supposed to prevent creating transactions that don't get accepted
like in this traceback:
```
broadcast_transaction error [DO NOT TRUST THIS MESSAGE]: "RPCError(1, 'the transaction was rejected by network rules.\\n\\ninsufficient fee, rejecting replacement ceeaef5ac7f82286e42ebd530e965fa4c7a6c11933d6b89d6d6f0ee2c69db839; new feerate 0.00001109 BTC/kvB <= old feerate 0.00001110 BTC/kvB
```

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 12/100

This commit only adds a new automated test to Electrum. It does not change any production wallet code. The test checks that when a user adds extra outputs to an existing RBF (replace-by-fee) transaction, the new transaction's fee is high enough to be accepted by Bitcoin network relay rules. The commit message mentions a past broadcast error where a replacement transaction was rejected because its fee rate was not higher than the original's. This is a regression test, not a fix.

Security candidatewallet: rbf: estimate base tx size before strippingby f321x · a9f20e4d · Feb 24, 2026 · 1 fileMessage 73 · AdequateLow 37Details
Commit message · f321x

wallet: rbf: estimate base tx size before stripping

Estimate the size of a base tx before stripping its signatures
so the lower bound feerate used to calculate the fee for the rbf
transaction doesn't underestimate the feerate of the base tx.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 37/100

This commit fixes a fee-calculation bug in Electrum's Replace-By-Fee (RBF) feature. Previously, the wallet estimated the size of the original transaction after removing its signatures. Because removing signatures makes the transaction look smaller than it really is, the wallet could set the new RBF transaction's fee too low, potentially causing the replacement transaction to be rejected by the Bitcoin network for not meeting the required fee rate. The fix estimates the original transaction size before stripping signatures, so the replacement fee is calculated more accurately.

Lower-priorityqt: console: allow changing font sizeby f321x · 2df68d92 · Feb 23, 2026 · 1 fileMessage 60 · AdequateTriage 0Details
Commit message · f321x

qt: console: allow changing font size

Allows changing the font size in the qt Console with
`Ctrl` + `+` and `Ctrl` + `-`.

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Security candidatelnpeer: don't save our own channel update as remote updby f321x · ddb01f53 · Feb 23, 2026 · 2 filesMessage 88 · StrongLow 34Details
Commit message · f321x

lnpeer: don't save our own channel update as remote upd

I noticed CLN is sending our own channel update to us on
reestablishment, we then assume it to be the remote nodes
update and try to verify the signature against their pubkey
which fails and throws `InvalidGossipMsg`.

This adds a check preventing us from trying to save our own
channel updates as remote update.

88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Low 34/100

This commit fixes a bug in Electrum's Lightning Network code where, after reconnecting to another node, Electrum could mistakenly treat its own channel settings message as coming from the remote peer. That caused a signature verification failure and an InvalidGossipMsg error, potentially disrupting the Lightning connection or channel state handling. The fix checks who originated the message and ignores it if it came from Electrum itself.

Lower-priorityupdate localeby SomberNight · 4d2ea4f2 · Feb 21, 2026 · 1 fileMessage 49 · ThinTriage 0Details
Commit message · SomberNight

update locale

This includes https://github.com/spesmilo/electrum-locale/pull/54,
which adds the new "X-Electrum-SourceStringCount" header into the .po/.mo files.

49/100 · ThinMessage clarity
✓ Subject identifies a change✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference! Too few words to establish purpose
Why it was queued
translation-only discount
Lower-prioritylocale: gui: show translation completion percentage in language namesby SomberNight · 3afa2fcd · Feb 21, 2026 · 6 filesMessage 73 · AdequateTriage 0Details
Commit message · SomberNight

locale: gui: show translation completion percentage in language names

In the GUIs, on the language-select screen, show e.g.
Czech (100%), Danish (13%), Dutch (54%)
instead of
Czech, Danish, Dutch

- we count the source strings when creating the .pot PO-template file
and add an "X-Electrum-SourceStringCount" header to it, in the push_locale.py script that uploads the .pot file to crowdin.
- later, when we run electrum-locale/update.py to download the translations in .po files, these files will also contain the same header.
- then when the build_locale.sh script compiles those .po files, we can read the header and use it to populate a new "stats.json" file
that we place in electrum/locale/locale/ and bundle in the all release binaries/distributables.
- stats.json also includes the number of translated strings for each lang
- at runtime we simply read stats.json and use the values to calculate the percentages
- a prior implementation did not pre-calc stats.json but did all calculations at runtime (by opening all .mo translations)
- however that was deemed to slow, hence the build-time pre-calc
- runtime calc took 40 ms on my laptop, so I guess it could easily take 10x that on an old phone
- just as we have always been very tolerant of any locale files or even the whole locale/ dir missing, we also tolerate stats.json missing

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priority(trivial) consistent whitespaces in .gitmodulesby SomberNight · 6de3fef7 · Feb 20, 2026 · 1 fileMessage 45 · ThinTriage 0Details
Commit message · SomberNight

(trivial) consistent whitespaces in .gitmodules

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body