That specific server simply seems to be offline. It is normal that some servers are not reachable.
What does it say for other servers? For example, what gets logged if you manually try to connect to ?
Could you share the logs?

It is monkey-patching / overwriting the `Abstract_Wallet.relayfee` instance method of the wallet object.
https://github.com/spesmilo/electrum/blob/392400295e733e1dd3f0cb14189466e8a76890ef/electrum/wallet.py#L1782-L1783

A lambda is an unnamed function. `lambda: 0` is a function that takes no parameters and returns the integer 0.

`Abstract_Wallet.relayfee` is a function that takes a single parameter, `self`, the wallet object itself, and returns an integer, the minrelayfee in sat/kvbyte units.

When you run the command in the Console, `wallet` is evaluated as the currently open wallet, an instance of the `Abstract_Wallet` class. And we are trying to replace the `relayfee` instance method with something that "looks the same" (has the same API) as the original. It gets a bit involved but basically the `self` parameter we can just ignore in this case.

Perhaps it would be easier to understand if instead of
I said to use

Both work equally well, I just preferred to be brief. Also less error-prone when typing manually.

but with the second code snippet, you can clearly see that we are replacing a function that takes a single argument, a wallet, and returns an integer, with another function having the same characteristics.

So the point is that you cannot simply set `wallet.relayfee = 0`, that won't work, as `wallet.relayfee` is not supposed to be an integer but rather a function that returns an integer.

Do you have more details to reproduce the rounding error? What was the vbyte size of the transaction?
You set the feerate to 0.1 s/b, and what absolute fee did the GUI calculate?


It works. That's why the issue got closed, and I tested it before posting that here in any case.


If you have "output value rounding" enabled, that can increase the fee by up to 100 sats.
Also, dust-valued change outputs are not created but converted to fees.


What version of the client were you running? Let me repeat it again, it will not work on any released version. You need the linked PR - and - to be connected to a low-fee server. You need both.

OR you can just run that one-liner in the console: That in itself is sufficient.

In that case the old method should still work. You can set in the Qt console, and then the GUI lets you do whatever you want. Create even zero-fee txs.

Without the linked PR, the GUI won't even let you sign the tx. (perhaps that should be changed but that's how it works atm)
The server-reported minrelayfee is clamped, just like many other server-reported values, such as the dynamic fees, there are safety limits. It cannot go below 1 sat/vbyte. The PR is changing the value of the lower clamp.

You will need https://github.com/spesmilo/electrum/pull/10096 for the client to allow attempting the broadcast.

Indeed, this seems to be what's going on based on OP's description.

Electrum does not use the operating system's CA store anymore. The python certifi package is used, which bundles Mozilla's CA root store. certifi is a required dependency, and Electrum uses it as the CA store everywhere internally.

This has been the case since around version 3.3. Before that, for some network requests the certifi (/requests) store was used, for other Electrum implicitly used the OS store. Using the OS store used to cause weird issues on some systems.

https://github.com/spesmilo/electrum/blob/8eb3c43603ed1915fa3e0b8d17c9dbeb183270c5/electrum/util.py#L88
https://github.com/spesmilo/electrum/blob/8eb3c43603ed1915fa3e0b8d17c9dbeb183270c5/contrib/deterministic-build/requirements.txt#L15-L16

Every version of Electrum ships with some specific version of certifi, so over time that CA store might get out of date, for an older release.
(At least when running the binaries. However if you e.g. install from a Linux distro, they might update the version of python3-certifi that they package independently of Electrum.)

Note that the checksum in BIP39 seeds is weak. A 12 word BIP39 seed only has a 4 bit checksum. There is a 1/16 chance that a random selection of 12 words from the wordlist is a valid seed.

What error do you get? Check the debug log of the client.

Yes, coin selection is supported.
In the desktop Qt GUI, go to menubar>View>Addresses, and also menubar>View>Coins.
The Coins tab is better suited for this, where you can right-click an individual coin (utxo) and select "Add to coin control" (or "Remove from coin control").
There is similar functionality in the Addresses tab too.

Also, from the same right-click context menus, you can "Freeze"/"Unfreeze" addresses/coins, which is sort of the inverse operation (except freezing is persisted in the wallet file, so it will be remembered even if you close the application and reopen it later).

You don't need to close your channels when you update, especially in minor patch releases.
Even in major releases that was never the case. Well okay, IIRC 4.3 dropped support for old pre-static_remotekey channels, but that type was never in a released version (only on git master).

You can be sure that if you had to close channels as part of an upgrade, that would be in the release notes.

Maybe related:

https://github.com/spesmilo/electrum/issues/9218
>  Android app currently not available in Google Play in UK

Yes, indeed fuse2 is needed atm.
What do you mean by electron-sandboxing (4)? Electrum does not use electron. Do we really need that sysctl? I have never seen a problem with that before.

In theory yes, but in practice there are some assumptions for what the host OS has and libc is one of those.
In general with AppImages, the idea is that the developer is supposed to build them on a very old Linux distribution, and users are then able to run them on newer (but not older) distros.

The AppImages for 4.3.2-4.5.2 are built using debian 10, which ships glibc 2.28.
Debian 10 is already "oldoldstable" at this point, so OP should really upgrade their system.

zbar is used for webcams to scan a QR code and to decode it.
E.g. you have an invoice with a QR code shown on your phone screen and you hold it up to your laptop camera. The laptop would then need to have the zbar library.
If you don't need this feature, it is safe to ignore.

You can see in the network overview that the client managed to connect to 9 servers ("connected nodes"). The red orb means that it could not connect to the main server selected.
I can also see that "select server automatically" is unchecked, meaning the client won't try any other server as main server. I guess that server is offline though.
So you should either enable automatic selection, or manually select another server.

What is your use case for trying to RBF txs that do not signal RBF?

~All txs created by Electrum signal RBF. Is it to bump the fee of txs created by other wallets?

It's a plugin to run your own swap server, it is an alternative implementation to Boltz.

- You can point the client to any remote swap server by setting the "swapserver_url" config key (unrelated to plugin),
- and it is possible to run a swap server yourself locally using this new plugin (which itself is a server implementation in python).

We wrote the plugin for our own use, to replace Boltz, as they changed their license from AGPL to a non-free license around 2023-04.
Since around 2023-08 we are no longer using Boltz. That is, the official swap server is now an electrum daemon with this plugin enabled.

That sounds like base64 encoding, which suggests the seed is encrypted. Are you by any chance comparing a wallet file that has a password set with one that does not?

Do you mean in the Android app? TBH that functionality in kivy might have been accidental... What exactly is your use case?

note: OP also opened an https://github.com/spesmilo/electrum/issues/8419, where I replied in detail.
In short,
- when you open a channel, you cannot receive before sending some first
- and it is the channel-opener who pays for the on-chain fees of having the channel closed in the future, for which part of the opener's balance is set aside. When the on-chain fees are as high as recently (~500 sat/vb), the fee set aside can easily be approx 2 mBTC.
As OP opened a channel with a capacity of 2 mBTC (the minimum hardcoded value allowed by Electrum), he basically had no usable balance left.