Repository navigation
millisat precision - #10586
millisat precision#10586accumulator wants to merge 36 commits into
Conversation
ce4fb8e to
eda429f
Compare
62db370 to
d8dfce5
Compare
d8dfce5 to
102df84
Compare
102df84 to
f7d2a9e
Compare
|
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 flows1.
|
754820c to
19432c7
Compare
Thanks for reviewing. I missed these Claude findings due to the green checkmark, and cirrus-ci is by now unavailable.. |
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. |
SomberNight
left a comment
SomberNight
left a comment
There was a problem hiding this comment.
I just looked at the first commit.
Please don't think just because the genai finds no concerns, there are no bugs.
Hmm, don't mind if I do :) |
19432c7 to
40a169a
Compare
…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. The `min()` and `max()` operators are implemented as in-place assignments (`setToMin()` and `setToMax()`) instead of functions returning a new QEAmount instance. QEAmount is implemented in python, so an instance returned to QML needs a strong reference on the python side to stay alive: without one the instance is deleted as soon as the slot returns and QML is left dereferencing it, and keeping one on the receiver accumulates an instance per call for the lifetime of that receiver. Assigning into an amount the caller already owns avoids both.
…precision on send_tab if recipient is onchain
…s empty string to BtcField
…of string, then don't use private properties in WalletMainView just for createRequest(), pass everything directly
- remove warning on amount_msat is None - remove checks against isEmpty which are unneeded and assume amount is positive
- lte()/gte() same behavior as lt()/gt() for None operand - __eq__ None operand is zero amount
The QML side already always received 0 as the amount if QEAmount.(m)sat is None, so to remove all confusion we coerce None to 0. If in the future we need undefined/NaN, we should add e.g. isUndefined and make it explicit
… formatSats{,ForEditing}
don't raise on unexpected types or None, but defer to config.format_amount(), which will return
'unknown' if amount is None (the only scenario that does not match the type-checks in the
format* methods).
Other types are gated by QML due to the pyqtSlot types declaration
…g_tx_dialog, main_window and send_tab also fixes LNURLw issue with millisat formatting and accepting <1sat lower bound
…but not above that. the previous regex just looked at number of digits, which allowed up to 100M BTC, but 100M BTC would overflow the commonly used qint64 type.
…ffective_invoice.
- invoice details - request details - channel details - lightning payment details
…rting from fiat amounts.
fiat amounts are not limited in number of digits (we expect them to eventually go to
zero), so when conversion goes over the total BTC supply limit, we simply clamp to the limit.
this avoids the overflow problem
```
TypeError: unable to convert a Python 'int' object to a C++ 'qint64' instance
```
and also the quantization limit with `Decimal`'s `DefaultContext`
```
>>> a = Decimal('154341084149652972384')
>>> a.quantize(Decimal(10) ** (-8))
Traceback (most recent call last):
File "<python-input-4>", line 1, in <module>
a.quantize(Decimal(10) ** (-8))
~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
decimal.InvalidOperation: [<class 'decimal.InvalidOperation'>]
```
…gnals to be bound on the QEAmount itself.
…freezeReusedAddressUtxosChanged
9297301 to
68a0287
Compare
support millisat precision throughout the codebase.
ints are passedDecimalis used on the GUI side where it's easier to assume sats are the base unitsatandmsatfields/parametersQEAmountis now synced between sats and millisats, simplifying assumptions and reducing if-else checksshould fix #6253, #10412