Stores the currently open (right-click) menu in MyTreeView
and adds a `close_menu()` method so inheritants can cleanly
close the menu again if the context it was opened upon has changed.
This is utilized by `AddressList` and `UTXOList` to close the menu
if a call to `update()` has chenged the address list in some way or
removed a utxo from the list to prevent the user from trying to use
a utxo that doesn't exist anymore.
Fixes#10464
NIP-47 now defines how client/server should communicate their supported
encryption schemes. For backwards compatibility its not strictly
neccessary to implement this but it seems cleaner to explicitly handle
it.
otherwise, when selecting only frozen coins, the set of usable coins is empty, and the menu options
will instead fall back to using ALL coins without informing the user.
- (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
```
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.
"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>
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.
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
```
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.
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.
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
Assert `WalletDBUpgrader.data` is a regular in-memory dict and not
some StoredDict, so if an exception would happen during a wallet
db upgrade the partial changes don't get commited to disk.
xgettext and related tools have a -s/--sort-output option, which results in the output being lexicographically sorted. The gettext maintainers recommend against using this option and even started deprecating it in some of their tools (xgettext included):
- with -s, source strings are lexicographically sorted in the .pot/.po files
- without -s, source string are output in the same order they are found in the code
- this way, translators have to do much fewer context switches when contributing translations
note that the qml part we have already *not* been sorting
ghost43