LoyceV's 0.1 sat/vbyte Electrum Server Adventure

[LoyceV]

Downtime

While updating the certificate, I realized I'm still running Fulcrum-1.12.0 while Fulcrum-2.1.1 is available, so it's time to upgrade. That means backup up the database^*, and converting it to a new format. I'll post here when it's running again.

^*Due to time and disk space restrictions, I'm doing this without backup. If it fails, I'll have to recreate Fulcrum's database from scratch. Living on the edge

Done! electrum.loyce.club:50002 is back online!

[LoyceV]

Downtime ahead:

Maintenance Window

Date: 28-08-2026
Start Time: 7:00 AM EST
End Time: 5:00 PM EST
Expected Downtime: Approximately 6 hours

[TheButterZone]

Nevermind, it was probably the Tor Browser proxy

Before the downtime with your server, this has been happening a bunch, not sure if it'll be fixed when it's back up?

Code:

15071.63 | E | asyncio | Task exception was never retrieved
future: <Task finished name='Task-2271' coro=<Interface.get_estimatefee() done, defined at /Users/Username/electrum/electrum/interface.py:1135> exception=RequestTimedOut("request timed out: ('blockchain.estimatefee', [5]) (id: 206)")>
Traceback (most recent call last):
  File "/Users/Username/electrum/electrum/interface.py", line 169, in send_request
    response = await util.wait_for2(
               ^^^^^^^^^^^^^^^^^^^^^
        super().send_request(*args, **kwargs),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        timeout)
        ^^^^^^^^
  File "/Users/Username/electrum/electrum/util.py", line 1404, in wait_for2
    return await asyncio.wait_for(fut, timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.14/lib/python3.14/asyncio/tasks.py", line 488, in wait_for
    return await fut
           ^^^^^^^^^
  File "/Users/Username/Library/Python/3.14/lib/python/site-packages/aiorpcx/session.py", line 540, in send_request
    return await self._send_concurrent(message, future, 1)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/Username/Library/Python/3.14/lib/python/site-packages/aiorpcx/session.py", line 511, in _send_concurrent
    async with timeout_after(self.sent_request_timeout):
               ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/Username/Library/Python/3.14/lib/python/site-packages/aiorpcx/curio.py", line 389, in __aexit__
    raise TaskTimeout(self._secs) from None
aiorpcx.curio.TaskTimeout: task timed out after 45s

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/Username/electrum/electrum/interface.py", line 1144, in get_estimatefee
    res = await self.session.send_request('blockchain.estimatefee', [num_blocks])
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/Username/electrum/electrum/interface.py", line 174, in send_request
    raise RequestTimedOut(f'request timed out: {args} (id: {msg_id})') from e
electrum.interface.RequestTimedOut: Network request timed out.

So I asked Gemini Pro...

Is it worth telling the server owner?

Yes, a brief heads-up is worth sending.

Code:

blockchain.estimatefee

queries depend on the server querying its underlying

Code:

bitcoind

node via

Code:

estimatesmartfee

. When that times out after 45 seconds while basic header and balance queries work fine, it usually indicates a server-side node issue:

* Node Restart: If the

Code:

bitcoind

instance behind the server was recently restarted, its fee estimation algorithm loses mempool history and stalls or drops requests until enough blocks pass.
* RPC Thread Exhaustion: The Electrum server (Fulcrum or ElectrumX) might be hitting internal timeout or queue limits when forwarding fee calls to

Code:

bitcoind

under heavy traffic.


Would a newer Electrum version fix this?

The traceback wall would disappear, but the 45-second network timeout would still happen until the server resolves the underlying delay.

Here is why:

* In Electrum 4.5.8: Interface background tasks trigger

Code:

get_estimatefee

without explicit top-level exception suppression in the event loop. When a network request times out,

Code:

aiorpcx

raises a

Code:

TaskTimeout

that floats up as an unretrieved

Code:

asyncio

task exception, dumping the full stack trace to

Code:

stdout

.
* In Newer Electrum Versions: Task management and error logging were refactored. RPC network timeouts are caught gracefully within the session layer, converting the crash wall into a clean, single-line debug log entry while falling back to local static fee estimates.

Applying your

Code:

try...except

patch gives your 4.5.8 installation the exact same resilience that newer Electrum versions have, cleanly swallowing server-side RPC timeouts without interrupting your terminal.

[LoyceV]

Downtime ahead:

Maintenance Window

Date: 28-08-2026
Start Time: 7:00 AM EST
End Time: 5:00 PM EST
Expected Downtime: Approximately 6 hours

The Maintenance Window ended 8.5 hours ago, but the server is still offline. I've opened a ticket, no idea what happened.

Update: it's back!

[Real-Duke]

Update: it's back!

Just tested -> works again!

[LoyceV]

It's not that bad: the new server is a lot faster.

Well.... guess what.... since they moved servers, I'm back to the slower server again In 3 months, it's time to either extend or find a better option. I'm hoping for a good Black Friday deal, but the current server market isn't very promising.

[LoyceV]

There's a problem: Bitcoin Core's data directory is on SAN storage on my server, and that seems to be offline. So even though my Electrum server is still running, it's currently lagging 33 blocks.
I've opened a ticket with my host.
Solved

[TheButterZone]

Not that anyone cares, but I managed to get Electrum 4.8.2 running its TUI on the same computer the devs destroyed GUI compatibility for (PyQt6 binary wheel dependency on non-backward-compatible system frameworks and dynamic library symbols).

Sample config terminal command:

Code:

python3 -c '
import json, os
path = os.path.expanduser("~/.electrum_482/config")
with open(path, "r") as f:
    data = json.load(f)
data["auto_connect"] = False
data["decimal_point"] = 8
data.setdefault("fee_policy", {})["default"] = "static:0.1"
data["proxy"] = "socks5:127.0.0.1:9150"
data["server"] = "electrum.loyce.club:50002:s"
with open(path, "w") as f:
    json.dump(data, f, indent=4)
'

Then as I run in venv,

Code:

cd Electrum-4.8.2 && source venv/bin/activate && ./run_electrum -D ~/.electrum_482 -g text -w '~/.electrum_482/wallets/wallletname'

(write a zsh to cd, activate the venv, and execute, if desired)



As far as importing up to 4.5.8 version wallets (or higher IDK, I skipped from there to 4.8.2), forward-compatibility was destroyed (exception WalletRequiresUpgrade), so I also ran in venv & wiped the terminal afterward:

Code:

./run_electrum -D ~/.electrum_482 restore --password "quotesonlyrequiredifspacesbetween" "xpuborzpubhereorseedwordwithquotesrequiredbecauseseedwordshavespacesbetween" --offline

Goodbye to address labeling unless I run 4.5.8 GUI instead (separated wallet files).

I also added an alerter locally, awaiting PR acceptance: https://github.com/spesmilo/electrum/pull/11019/changes

[nc50lc]

As far as importing up to 4.5.8 version wallets (or higher IDK, I skipped from there to 4.8.2), forward-compatibility was destroyed (exception WalletRequiresUpgrade), so I also ran in venv & wiped the terminal afterward:

Hmm, it should be forward compatible and should automatically upgrade the wallet on load.
Even older seed_versions are covered by electrum's wallet_db.py file and the error isn't related to unsupported versions.

Perhaps it has to do with other unfulfilled requirements due to the old OS.

Goodbye to address labeling unless I run 4.5.8 GUI instead (separated wallet files).

Try setlabel command.
e.g:

Code:

electrum setlabel "address or txid" "label"

If you can find a way to enable "label sync" plugin in that Text UI, you can use labels_pull and labels_push commands to sync it with you original wallet's labels.

[TheButterZone]

If you can find a way to enable "label sync" plugin in that Text UI, you can use labels_pull and labels_push commands to sync it with you original wallet's labels.

I couldn't, there's no setting for label sync inside the TUI, and I can't find it in text.py either. Even after enabling 4.5.8's LabelSync & doing a force upload of that wallet, then opening the label-less wallet remade for 4.8.2 TUI, with same LoyceV server set between the two of them, TUI didn't auto-sync either.

What I ended up having to do is this, after a ton of crap iterations from Gemini (using the exported walletname_electrum_labels.json from 4.5.8 GUI):

Code:

import json
import os
import sys
import getpass

# Add your Electrum source path so Python can find the package
sys.path.insert(0, os.path.expanduser("~/Electrum-4.8.2"))

from electrum.storage import WalletStorage
from electrum.wallet_db import WalletDB

wallet_path = os.path.expanduser("~/.electrum_482/wallets/walletname")
labels_path = "~/walletname_electrum_labels.json"

# Load storage and decrypt if encrypted
storage = WalletStorage(wallet_path)
if storage.is_encrypted():
    password = getpass.getpass('Wallet Password: ')
    storage.decrypt(password)

# Initialize WalletDB with decrypted storage data
db = WalletDB(storage.read())

# Load exported labels JSON
with open(labels_path, "r") as f:
    labels = json.load(f)

# Update the database labels dictionary
wallet_labels = db.get('labels', {})
for key, label in labels.items():
    wallet_labels[key] = label
db.put('labels', wallet_labels)

# Write the updated database dump back to storage (re-encrypting if necessary)
storage.write(db.dump())

print(f"Successfully imported and saved {len(labels)} labels.")

Then

Code:

~/Electrum-4.8.2/venv/bin/python3 ~/import_labels.py

and that successfully imported & saved, all labels visible in TUI now.

Maybe I could have gotten Gemini to add label sync to the config terminal command after dozens more iterations+reverse engineering, but it seems to be getting dumber & dumber these days, and it didn't come up with that despite staying within the same ongoing chat from its previous development.

[nc50lc]

Maybe I could have gotten Gemini to add label sync to the config terminal command after dozens more iterations+reverse engineering, but it seems to be getting dumber & dumber these days, and it didn't come up with that despite staying within the same ongoing chat from its previous development.

I've tested it and "plugin" isn't one of its available config variables.
One "dirty" edit on your config file to add the below should do the trick but it must be inserted without breaking the json encoding.
these lines:

Code:

    "plugins": {
        "labels": {
            "enabled": true
        }
    },

To be sure, you can use your other Electrum install (with GUI) for reference, enable and disable the plugin to see what's being changed.

[TheButterZone]

Maybe I could have gotten Gemini to add label sync to the config terminal command after dozens more iterations+reverse engineering, but it seems to be getting dumber & dumber these days, and it didn't come up with that despite staying within the same ongoing chat from its previous development.

I've tested it and "plugin" isn't one of its available config variables.
One "dirty" edit on your config file to add the below should do the trick but it must be inserted without breaking the json encoding.
these lines:

Code:

    "plugins": {
        "labels": {
            "enabled": true
        }
    },

To be sure, you can use your other Electrum install (with GUI) for reference, enable and disable the plugin to see what's being changed.

I added a label in 4.5.8 GUI to an address that didn't have a label yet, force-uploaded, used this on the TUI

Code:

python3 -c '
import json, os
path = os.path.expanduser("~/.electrum_482/config")
with open(path, "r") as f:
    data = json.load(f)
data["auto_connect"] = False
data["decimal_point"] = 8
data.setdefault("fee_policy", {})["default"] = "static:0.1"
data["proxy"] = "socks5:127.0.0.1:9150"
data["server"] = "electrum.loyce.club:50002:s"
data.setdefault("plugins", {}).setdefault("labels", {})["enabled"] = True
with open(path, "w") as f:
    json.dump(data, f, indent=4)
'

& relaunched TUI multiple times, no sync on that address.

I checked with nano, it's in there & should have been properly indented, braced, quoted, everything:

Code:

    "config_version": 3,
    "decimal_point": 8,
    "fee_policy": {
        "default": "static:0.1"
    },
    "plugins": {
        "labels": {
            "enabled": true
        }
    },
    "proxy": "socks5:127.0.0.1:9150",

ETA: LabelSync did work exclusively within 4.5.8 when I made a watch-only wallet to mirror its seeded one, it synced the label on that address & all the rest.

[Cricktor]

I fail to see how this Electrum TUI thing is on-topic here. I mean, it's kinda interesting, but should go into a separate topic, no?

IIRC, you also posted about your TUI "experiment" in DireWolf's Electrum server topic, too. So, I'm a bit divided and ask, why here and there? Both places seem a bit misplaced for your Electrum TUI stuff.

[TheButterZone]

I fail to see how this Electrum TUI thing is on-topic here. I mean, it's kinda interesting, but should go into a separate topic, no?

IIRC, you also posted about your TUI "experiment" in DireWolf's Electrum server topic, too. So, I'm a bit divided and ask, why here and there? Both places seem a bit misplaced for your Electrum TUI stuff.

It's an ongoing storyline here how I was unable to upgrade to the latest GUI versions (plus the screenshot shows I'm connected to OP's own server), and also...

Cool hallucination bro.

DireWolfM14's Electrum server topic where I haven't posted, only merited: DireWolfM14's Electrum SPV Server

The only serious other places I replied about this, were in a topic about upgrading to a latest Electrum version (which I was finally able to do thanks to discovering the TUI): Update to 4.8.1 NOW! & another topic heavily related to versions & another topic heavily related to versions. None of which, a topic of DireWolfM14's.

And tangentially, how I used testnet4 for the first time to test the TUI alert, in a topic about testnet4: Whats the current state of testnet3 vs testnet4?