millisat precision by accumulator · Pull Request #10586 · spesmilo/electrum

accumulator · 2026-04-17T14:48:46Z

support millisat precision throughout the codebase.

kwarged backend wallet funcs so it is clear whether sats or millisats as ints are passed
lnurl now native millisats
Decimal is used on the GUI side where it's easier to assume sats are the base unit
- avoids having to check sat and msat fields/parameters
- can check easily if amount has millisat precision where not allowed
- extra millisat precision is carried transparently for eventual passing to backend
QML QEAmount is now synced between sats and millisats, simplifying assumptions and reducing if-else checks

f321x · 2026-06-04T12:52:19Z

I looked through the PR, but the issues above were all found by Claude. For those i verified (point 1 - 6) i wrote the comments above. I didn't verify the remaining points but considering the first were all real it makes sense to look at the remaining ones as well (8. -12.).

This is the output:

## 🔴 High — confirmed crashes / broken core flows

1. `create_request` dropped its amountless-coercion — amountless requests break three ways

Root cause at electrum/wallet.py:3023: the old amount_sat = amount_sat or 0 +
amount_msat = None if not amount_sat else … is gone, so an empty amount no longer maps
to "amountless".

(a) crash — QML amountless Lightning request. electrum/gui/qml/qewallet.py:706
passes amount_msat=amount.msatsInt (= 0 for an empty QEAmount). create_request
keeps amount_msat=0, so lnworker.create_payment_info raises
ValueError("amount_msat must not be 0…") at electrum/lnworker.py:2714. createRequest
only catches InvoiceError (qewallet.py:709) → unhandled exception. This is the standard
"donation / request-without-amount" flow and it's reachable — with inbound liquidity,
lightningCanReceive.gt(empty) is true, so the Lightning button is enabled. Master
produced an amountless invoice here.
(b) broken — Qt on-chain amountless request. receive_tab.py empty field →
get_amount() returns None → create_request(amount_sat=None, address=addr) →
wallet.py:3057 PartialTxOutput.from_address_and_value(addr, None) →
ValueError: bad txout value: None (reproduced). Caught by the generic except Exception
and shown as "Error adding payment request"; the request is never created (worked on
master). Same crash, uncaught, via the add_request RPC with no amount
(satoshis(None)=None, commands.py:1383).
(c) wrong — QML on-chain amountless request. qewallet.py:708 passes amount_sat=0
→ amount_msat=0 → Request.get_amount_sat() returns 0 (not None) → a fixed
0-amount request instead of "any amount".

Fix: re-introduce the coercion in create_request (treat 0/None as amountless:
amount_msat=None, on-chain output value 0).

2. `FeerateEdit.setAmount(None)` crashes

electrum/gui/qt/amountedit.py:180 — FeerateEdit now subclasses AmountEdit instead of
BTCAmountEdit, losing BTCAmountEdit.setAmount's if amount is None: setText(" ") guard
(amountedit.py:165). AmountEdit.setAmount(None) → to_decimal(None) → Decimal('None')
→ InvalidOperation. confirm_tx_dialog.py:355 and :436 call
self.feerate_e.setAmount(None) whenever there's no fee estimate / not enough funds — a
common path. (fee_e is fine; it's still a BTCAmountEdit.)

🟠 Medium — confirmed wrong output / wire format

3. Qt desktop lists & notification mis-render sub-sat amounts

invoice_list.py:119, request_list.py:149, main_window.py:1375 (the "Payment received"
notification) and :1690 (invoice dialog) now read get_amount_sat_msat_precision() (which
returns a Decimal for sub-sat amounts) but call format_amount(...) without
precision=3. Verified: format_amount(Decimal('1.5')) → rounds to 2 sat ('0.00002'),
and format_amount(Decimal('0.4')) → the malformed string '0.'. So the msat-precision
getter was wired up but the precision is dropped exactly where it should be shown (and
< 0.5 sat renders garbage). Pass precision=3 (as the QML side does).

4. LNURL-pay sends a non-integer `amount` on the wire

qeinvoice.py:609 computes amount = Decimal(msatsInt)/1000, then
payment_identifier.py:392 does amount_msat = amount_sat * 1000 → Decimal('2345.000'),
sent as params={'amount': …} (:403). aiohttp serializes that to ?amount=2345.000
(trailing zeros). Since BtcField here has msatPrecision: true, any sub-sat amount (or an
LNURL whose min_sendable_msat isn't a whole sat) triggers it, and strict servers doing
int(amount) reject it. Master sent integer msat. Fix: params={'amount': int(amount_msat)}.

5. `qefx.satoshiValue` stores a `Decimal` in `_amount_msat`

qefx.py:164 self._amount.satsInt = v.to_integral_value() (a Decimal); the satsInt
setter multiplies by 1000 and stores the Decimal, so _amount_msat is no longer an int
— violating the invariant the constructor asserts (assert isinstance(amount_msat, int)) and
the 'qint64' property type. Wrap in int(...).

🟡 Low / latent / robustness

QEAmount.max/min/lt/gt is_max semantics are wrong (qetypes.py:177):
gt()/lt() return False whenever either operand is is_max, so max(MAX, normal)
returns normal (loses MAX) and the result is order-dependent. Latent — no current caller
passes an is_max amount — but the helper is incorrect for future use.
_msat_to_sat truncates toward zero, not floor (qetypes.py:54,
int(Decimal(msat)/1000)): inconsistent with // 1000 used everywhere else in the
codebase; off-by-1-sat for negative sub-sat LN amounts (reachable via
qetransactionlistmodel.py where amount_msat < 0).
__eq__ against an int silently changed from sat to msat and the str branch was
removed (qetypes.py:192). No broken caller found (comparisons are all against 0), but
amount == <nonzero int> now means msat — a footgun worth a comment or an explicit
msat-named helper.
assert used to validate untrusted input: lnurl.py:188 validates a remote server's
min/max withdrawable with assert, and the QEAmount constructor asserts its args — both
stripped under python -O, letting malformed LNURL ranges / bad amounts through.
(Pre-existing pattern, but now on the canonical msat path.)
formatMilliSatsForEditing lacks the None guard its siblings formatSats /
formatMilliSats have (qeconfig.py:364).
positive uses >= 0 (was > 0) (qetypes.py:110): a zero-value entry is labeled
received/credit in LightningPaymentDetails.qml:55 / TxDetails.qml:110 (mostly hidden
by visibility guards).
min/max return shared references → effectiveMaxWithdrawable can alias the live
wallet QEAmount in LnurlWithdrawRequestDialog.qml; self-corrected by updateLimits()
but fragile. Minor: ChannelBar.qml switched to .satsInt, truncating msat in bar-width
math (cosmetic).

accumulator · 2026-06-05T10:20:58Z

I looked through the PR, but the issues above were all found by Claude. For those i verified (point 1 - 6) i wrote the comments above. I didn't verify the remaining points but considering the first were all real it makes sense to look at the remaining ones as well (8. -12.).

Thanks for reviewing. I missed these Claude findings due to the green checkmark, and cirrus-ci is by now unavailable..

f321x · 2026-06-05T10:26:15Z

I missed these Claude findings due to the green checkmark

The results i commented were from a local run, not sure what the CI said, but yeah it often finds some things even though the checkmark is green, so makes sense to look at the output anyway.
Btw, let me know if you want an API key as well.

SomberNight

I just looked at the first commit.
Please don't think just because the genai finds no concerns, there are no bugs.

accumulator · 2026-06-05T22:50:44Z

Btw, let me know if you want an API key as well.

Hmm, don't mind if I do :)

accumulator · 2026-06-11T15:09:19Z

rebased on master, commits reorganised for better reviewability

…imal point and extra_precision up to AmountEdit AmountEdit defaults to decimal_point = 0, declare FiatAmountEdit to encapsulate fx base unit and precision, extra_precision now a callable and retrieved dynamically. BTCAmountEdit extended with millisat_precision option kwarg to allow 3 digits extra precision.

…with parameter combinations to constructor. in QEConfig, add formatMilliSatsForEditing, update formatMilliSats passing Decimal to config.format_amount/_and_units

add amount_msat parameter and make mutually exclusive with amount_sat

qt: send_tab LN checks millisat precision

payment_identifier: mark pi invalid if multiline and any output uses msat precision qt: update send_tab for lnurl msat precision qml: update qeinvoice, qerequestdetails for lnurl msat precision

…oiceParser, QEFX, QEWallet

QEConfig.satsToUnits to QEConfig.amountToBaseunitStr with the latter now also taking a QEAmount instance

Using javascript or QML `int` type is a long-standing issue, as there is not enough range to express millisats or even sats. A short summary of the issues: - integers in javascript context have a max range of +/- 2^54-1, which allows 21M BTC expressed in sats, but not in msats. - QML `int` properties have a max range of +/- 2^31-1, which only allows 21 BTC expressed in sats, 21 mBTC expressed in msats - `int` parameters declared in the `pyqtProperty` and `pyqtSlot` decorators have a max range of 2^31-1, although this is somewhat alleviated in the QML->Python direction by using `q(u)int64`. Returning a `q(u)int64` does not work around the `int` limitation In most of the QML code, `QEAmount` is already used for storing and passing around BTC values. The only exception is where amounts are compared (e.g. invoice amount < available balance etc), so the `<`, `>`, `<=`, `>=` and `!=` operators, and where these operators are implied, like `Math.min()` and `Math.max()` This commit delegates these operators to python scope.

…precision on send_tab if recipient is onchain

f321x · 2026-06-26T08:08:53Z

This would also benefit from using the new amount_msat kwarg:

electrum/electrum/plugins/nwc/nwcserver.py

Lines 463 to 466 in 32f2c18

    
           # create payment request 
        
           key: str = self.wallet.create_request( 
        
               amount_sat=amount_msat // 1000, 
        
               message=description,

f321x · 2026-06-26T08:17:24Z

-    def satoshiValue(self, fiat, plain=True):
+    @pyqtSlot(str, result='QVariant')
+    def satoshiValue(self, fiat):
+        self._amount = QEAmount()


Why is _amount declared as instance attribute here, isn't it just used in the scope of this method?

f321x · 2026-06-26T09:22:46Z

        try:
            fd = Decimal(fiat)
        except Exception:
            return ''


Returning a str here violates the specified QVariant result type, e.g. when entering . as fiat amount:

11.04 | W | gui.qml.qeapp | "Could not convert argument 0 at" 11.04 | W | gui.qml.qeapp | "expression for onTextChanged@file:///var/home/user/code/code_vm/electrum/electrum/gui/qml/components/controls/FiatField.qml:22" 11.04 | W | gui.qml.qeapp | file:///var/home/user/code/code_vm/electrum/electrum/gui/qml/components/controls/FiatField.qml:22: TypeError: Passing incompatible arguments to C++ functions from JavaScript is not allowed.

f321x · 2026-06-26T09:39:04Z

    Label {
        visible: valid
-        text: amount.msatsInt != 0 ? Config.formatMilliSats(amount) : Config.formatSats(amount)
+        text: Config.formatMilliSats(amount)


This passes None to Config.formatMilliSats() and raises an Exception, e.g. when creating a lightning invoice:

3.70 | I | lnworker.LNWallet.[default_wallet] | creating bolt11 invoice with routing_hints: [('r', [('02c3be1bcedffe1675617fc7ae9e4c43ce0f54cc3e58c48ef51398dc87a78e0ce0', '10052759x15511793x59990', 1000, 1, 144)]), ('r', [('02c3be1bcedffe1675617fc7ae9e4c43ce0f54cc3e58c48ef51398dc87a78e0ce0', '8427041x8597475x4058', 1000, 1, 144)]), ('r', [('02465ed5be53d04fde66c9418ff14a5f2267723810176c9212b722e542dc1afb1b', '16000000x0x18483', 1000, 1, 80)])], sat: 1898 3.71 | E | gui.qml.qeapp.Exception_Hook | exception caught by crash reporter Traceback (most recent call last): File "/var/home/user/code/code_vm/electrum/electrum/gui/qml/qeconfig.py", line 400, in formatMilliSats raise Exception(f"Unknown amount type: {str(type(amount))}") Exception: Unknown amount type: <class 'NoneType'> 3.73 | D | gui.qml.qerequestdetails | key=f3cd542ad64f230e65dfe4e7312d3a00394a3ce651ed4a5ab1c8072535c10061

f321x · 2026-06-26T11:15:07Z

-        return "%d" % amount
+        x = to_decimal(amount)
+        scale_factor = pow(10, self.decimal_point())
+        nfmt = "{:." + str(self.decimal_point() + self.extra_precision()) + "f}"


When calling .setAmount() on a FeerateEdit with a 0 extra_precision currency like KRW this swallows trailing 0, though nothing seems to be affected by this:

>>> from electrum.gui.qt import amountedit >>> fiat = amountedit.FiatAmountEdit(fx=daemon.fx) # fx is KRW >>> fiat.setAmount(100000) >>> fiat.get_amount() 1

f321x · 2026-06-26T11:24:21Z

-    def __init__(self, *, amount_sat: int = 0, amount_msat: int = 0, is_max: bool = False, from_invoice=None, parent=None):
+    valueChanged = pyqtSignal()
+
+    def __init__(self, *, amount_sat: int = None, amount_msat: int = None, is_max: bool = False, from_invoice=None, parent=None):


The default argument change from 0 to None causes the log in satsInt() and msatsInt() to spam a bit when using default QEAmount(). Maybe the log could be removed as it is to be expected that the amount is None sometimes?

E.g. when opening a swap view:

24.86 | D | gui.qml.qeswaphelper | run_swap_manager 24.87 | I | submarine_swaps.NostrTransport | starting nostr transport with pubkey: 7992c2f29bf56da19b032e2aca6f785e8413058dd57f1c1482aa2486c4531299 24.87 | I | submarine_swaps.NostrTransport | nostr relays: ['wss://nostr.einundzwanzig.space', 'wss://relay.primal.net', 'wss://relay.damus.io', 'wss://eu.purplerelay.com', 'wss://ftp.halifax.rwth-aachen.de/nostr', 'wss://relay.getalby.com/v1', 'wss://nostr.mom', 'wss://brb.io', 'wss://nos.lol'] 24.87 | W | gui.qml.qetypes | amount_msat is undefined, returning 0 24.87 | W | gui.qml.qetypes | amount_msat is undefined, returning 0 24.87 | W | gui.qml.qetypes | amount_msat is undefined, returning 0 24.87 | W | gui.qml.qetypes | amount_msat is undefined, returning 0

f321x · 2026-06-26T13:06:36Z

                Layout.preferredWidth: 1
-                enabled: Daemon.currentWallet.isLightning && (Daemon.currentWallet.lightningCanReceive.satsInt
-                            > amountBtc.textAsSats.satsInt || Daemon.currentWallet.canGetZeroconfChannel)
+                enabled: Daemon.currentWallet.isLightning && (Daemon.currentWallet.lightningCanReceive.msatsInt


The Lightning button doesn't react to user input anymore, when entering an amount exceeding lightningCanReceive the button stays enabled.

f321x · 2026-06-26T13:19:10Z

            else:
                self.amount_e.setToolTip('')

        # resolve '!' in amount editor if it was set before PI


This behavior seems to have regressed, when entering ! first and then pasting an address the amount turns empty instead of resolving max.

accumulator force-pushed the millisat_precision branch from ce4fb8e to eda429f Compare April 17, 2026 15:21

SomberNight reviewed Apr 18, 2026

View reviewed changes

Comment thread electrum/gui/qml/components/LnurlWithdrawRequestDialog.qml Outdated

accumulator marked this pull request as draft April 20, 2026 07:23

accumulator force-pushed the millisat_precision branch 11 times, most recently from 62db370 to d8dfce5 Compare April 21, 2026 12:59

accumulator marked this pull request as ready for review April 21, 2026 13:14

accumulator force-pushed the millisat_precision branch from d8dfce5 to 102df84 Compare April 21, 2026 13:20

accumulator force-pushed the millisat_precision branch from 102df84 to f7d2a9e Compare April 29, 2026 12:36